List of Some Design Concepts and Principles
TL;DR
This is my second post about design patterns and principles. Like I mentioned in my previous post, my aim here is not to go into detail but create a cheatsheet to quickly review before interviews to serve as a reminder.
KISS (Keep It Simple, Stupid)
Keep it simple, avoid complexities => clear to understand, easy to debug, easy to maintain
DRY (Don’t Repeat Yourself) — DIE (Duplication is Evil)
Avoid duplication — Consider modularizing functionality that you use more than once
- If you have a repeated piece of code, move inside a new function
- If you have a function that you’ve defined in several places, then move it into a common module.
- If the same applies to your module, consider turning it into a common library.
YAGNI (You Aren’t Gonna Need It)
Avoid over-engineering (code bloat), implement only necessary requirements.
Curly’s Law — Do One Thing
A entity (class, function, variable) should mean one thing, and one thing only.
Law of Demeter — Don’t talk to strangers
Avoid coupling.
A method of an object may only call methods of:
- The object itself.
- An argument of the method.
- Any object created within the method.
- Any direct properties/fields of the object.
Inversion of Control — Hollywood Principle, “Don’t call us, we’ll call you”
Can achieve by using:
- Factory Pattern
- Service Locator Pattern: Instead of instantiating dependent class itself, it gets an implementation from the service locator.
Some argue that it is an anti-pattern which obscures dependencies and makes software harder to test. - Dependency Injection:
To understand Dependency Injection, firstly I should give some details about IoC (Inversion of Control):
Inversion of Control — is to provide any kind of callback, instead of acting ourself directly. It enables the creation of dependent objects to be inverted. It helps designing testable, maintainable and extensible loosely coupled classes.
Using IoC, you are not new’ing up your objects. IoC containers (DI frameworks) will do that and manage the lifetime of them.
Dependency Injection — is a more specific version of IoC pattern, where implementations are passed into an object through constructors/setters/service lookups, which the object will ‘depend’ on in order to behave correctly. - Template Method Pattern
It is kind of IoC without using DI. - Strategy Pattern
Boy-Scout Rule
Refactoring (Uncle Bob) — always leave the code behind in a better state than you found it to avoid technical debt
Linus’s Law
Given enough eyeballs, all bugs are shallow. — recommends software reviewing process where multiple developers inspect the piece of code before it’s accepted and merged.
Brooks’s Law
Adding manpower to a late software project makes it later.
Happy Coding!
References:
https://blog.bitsrc.io/kiss-solid-yagni-and-other-fun-acronyms-b5d207530335
https://workat.tech/machine-coding/tutorial/software-design-principles-dry-yagni-eytrxfhz1fla
https://java-design-patterns.com/principles
https://en.wikipedia.org/wiki/Service_locator_pattern
https://stackify.com/service-locator-pattern/
https://stackoverflow.com/questions/6550700/inversion-of-control-vs-dependency-injection
https://stackoverflow.com/questions/3058/what-is-inversion-of-control
