Lod — Law of Demeter
Law Demeter
Talk only with your close friends.
Monthly Archives: February 2020
Encapsulate what changes
Encapsulate what may change
Hide changing code under abstraction.
Composition Over Inheritance
Composition Over Inheritance The principle says, that we should prefer composition (class A uses class B) than inheritance. When using inheritance, remember not to break the Liskov Substitution Principle. The principle does not say that we should completely reject inheritance. Example: We have a Worker and a Manager. Inheritance: Both classes have names and surname.… Read More »
SLAP — Single Level of Abstraction Principle
Each code line in the method should have the same level of abstraction. We should not mix high-level with low-level details in one method.
Dependency inversion principle
Dependency inversion principle:
High-level modules should not depend on low-level modules, but the dependence should result from abstraction.
DRY — Don’t repeat yourself
The DRY principle recommends not to repeat the same solution.
KISS — Keep it simple, stupid
The KISS rule recommends creating a solution in the simplest way possible. It is recommended to maintain an elegant, simple structure without oddities and unnecessary elements, and avoid overgrowing the form over the content. Its use is aimed at facilitating understanding of the solution, its subsequent maintenance, and development, e.g. a computer program. All posts… Read More »
Interface segregation principle
Interface segregation principle:
Many small and dedicated interfaces are better than few and general.
L jak Liskov Substitution Principle
Liskov Substitution Principle The application should work correctly when we put in the base class place every derived class. There is required full interface and method compatibility. You should remember, during designing class hierarchy, that every class can use their method from base class without overriding them. Methods of derivative classes should at most extend… Read More »
O as Open-closed principle
Open/closed principle All classes should be open for enlargement and closed for modifications. This principle is about two things: Open — Elements should be created in a way to be easily expanded. Changes in their behavior should not require modification of the current code but added a new one. Closed — Behavior modification should not be… Read More »
SOLID exercises — Kata
Today I practised SOLID by making Kata. I choosed very popular Kata: The String calculator. Do you know what Kata is? Kata Kata is a basic motion. It is a Japanese word, which describe specific motion sequence (fight moves). Regular Kata repetitions allow you to practice to perfection in your chosen technique. In programming, Kata… Read More »
S like Single responsibility principle
Single responsibility principle Every class should have only one reason to change. Every class should have: Only one goal of existence. Only one responsibility. Only one task to do. Only one reason for the modification. This rule can be applied to methods, functions, classes, modules and packages. Advantages More readable code. More understandable code.… Read More »
SOLID exercises
SOLID SOLID principles are basic rules of object-oriented programming. You should not only know them but also practice and use them at work. At first, I remind you of SOLID principles, and then I show you some exercises. Single responsibility principle Every class should have only one responsibility (every class should have only one reason… Read More »
SOLID
SOLID SOLID is a basic concept in object-oriented programming. It was introduced by Robert C. Martin, who gathered together five rules in one concept: SOLID. It is an acronym of 5 principles for good object-oriented programming: Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle Single responsibility principle Every class… Read More »