Here are some object-oriented principles explanations, targeted to beginner developers who may not be used to object-oriented programming, and who do not have a lot of time to read more details…
High cohesion
A module is highly cohesive when it has only one precise goal.
Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability.
Low Coupling
Two modules are highly coupled when modifying something in one module implies having to make modifications on the other one as well. High coupling is to avoid, we must design our modules to make them independent from each other.
Coupling can also be called dependency.
Encapsulation
Any object must include every method operating on it.
Information hiding
This is directly related to encapsulation: protect the internal implementation of an object (which is subject to change as the design will evolve…) by accessing it through an interface.
“Don’t Repeat Yourself”
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
→ Avoid Copy-Paste of code.
SOLID principles
SRP – Single Responsibility Principle
“Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.”
→ 1 object has 1 “reason to change”. Avoid consequences if something changes in the object (low coupling).
OCP – Open/Closed Principle
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
→ Never break what has been done when adding a new feature to a piece of software. Make methods which could be implemented differently abstract (use interfaces).
LSP – Liskov Substitution Principle
“If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering correctness of that program.”
→ To facilitate this, use the base type instead of the subtype as much as possible.
ISP – Interface Segregation Principle
“No client should be forced to depend on methods it does not use.”
→ Split interfaces into smaller and more specific ones so that any clients of the interface will only know about the methods that pertain to them.
DIP – Dependency Inversion Principle
“A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.”
→ Use interfaces and abstractions (“Wrappers”), in order to facilitate reuse of low-level modules.
Sources: Wikipedia, developpez.com (fr)
Great link! Black Belt Review
Le gras, la bière. le GRAS. la BIERE!!