From STUPID To SOLID

STUPID

• Singleton

• Tight Coupling

• Untestability

• Premature Optimization 

• Indescriptive Naming

• Duplication

Singleton

• Most well-known design pattern
• Singleton syndrome
• Using global state is very difficult to test
• If the *best solution is a singleton, you're doing something wrong.

Tight Coupling

• Coupling is the degree which each module relies on each one of the other modules
• Does coupling exist in your programs?
• Do you instantiante objects on the constructor?
• Difficult to reuse & to test

Untestability

• Test should not be hard
• Symptom of tight coupling
• You should always write tests
• Make sure you always have a complete suite

Premature Optimization

• Changing architecture is more complex that rewriting loops
• Don't dare to optimize without any data
• You could introduce more bugs
• Leave it the experts
• To Experts: don't do it (yet)

Indescriptive Naming

• Name your classes, methods, variables, attributes properly!
• Don't abbreviate!
• Write code for humans
• "Programming languages are for humans"

Duplication

• Don't Repeat Yourself (Dry)
• Be lazy (the right way)
• Keep it simple, stupid (Kiss)
• If you're copying and pasting constantly you might be violating this principle

SOLID: The path of the righteous

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

• Principles, not laws

Single Responsibility Principle

• Just because you can doesn't mean you should
• Ask before you add something if  that should be there.
• Avoid God classes
• High cohesion

Open/Closed Principle

• X-Rays are not needed to put on a shirt.
• Show only what you need to show (And through getters and setters)
• Open for extension and close for modification.

Liskov Substitution Principle

• If it looks like a duck, quacks like a duck but it needs batteries, you probably have the wrong abstraction. 
• "Objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program."

Interface Segregation Principle

• Many client-specific interfaces are better than one general purpose  
• Low coupling + High cohesion
• Keep your components focused and try to minimize the dependence  between them

Dependency Inversion

• Abstraction should not depend upon details
• Details should not depend upon abstraction
• High level classes -> Abstraction Layer-> Low level classes

Conclusion

• Avoid Tight coupling
• Tight cohesion
• Use your brain
• Think about the future (all code is legacy code)