SOLID & # 8211; 5 principles of object-oriented design

1. Single responsibility principle

Temporarily translated: Single-minded principle

The principle of responsibility states that: each class or method should have only one and only one function (a.ka. is responsible for one thing). Often this rule is very easy to violate, like a User class is responsible for many things in the application, from validate email to logging in, sending email etc. Classes that do so many different things are often called god object .

This principle was first introduced by Principles of Object Oriented Design ( Robert C. Martin ), who defined that "responsibility" is a reason to change.

In the context of the Single Responsibility Principle (SRP) we define a responsibility to be "a lý do cho thay đổi." – Bob Martin

In exchange for the method, it is relatively easy to apply this principle. For example, in the crash test function game (let's call detectCollision() ) should not change the player's score, if the detectCollision() function does something other than the "detect collision" it violates a single rule. mission.

2. Open / closed principle

Temporarily translated: Principle of opening / closing

Entities software (classes, modules, functions, etc.) should be open for extension, but closed for modification

This principle can be understood that: classes or functions should be designed to expand, but closed to avoid direct change of source code. This means that the system should be set up to support later developers to extend existing classes to provide additional functionality instead of editing existing source code in the system.

This is beneficial that later programmers work on a code base without having to write test for existing code and minimize side effects . Because for large code bases, a small change can also have large, domino effect types.

To illustrate this example, see an example of the strategy design pattern :

3. Liskov substitution principle

Temporarily translated: Principle of Liskov swapping

The Liskov substitution principle (LSP) states that objects should be replacable with instances of their subtypes without thay đổi đúng của chương trình

This principle may sound complicated, but it can actually be simplified as follows: If a class uses an implemtation of an interface, it must be replaced easily by the implementation of that interface without need to fix something more.

This example is taken back from the previous article. We can see that StandardLogger and FileLogger both implement an interface and they can be easily changed without modifying the source code of MyLog .

4. Interface segregation principle

Temporarily translated: Interface separation principle (programming)

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

This principle states that the implementation of an interface should not be dependent on the methods it does not use. This means that interfaces must be properly arranged and divided. Instead of having a FAT interface containing all methods that need to be implemented, it should be broken down to which class implements it also without the redundant method.

In Laravel: From Apprentice To Artisan , Taylor Otwell has an example of the SessionHandlerInterface as follows:

Looking at the SessionHandlerInterface interface above does not seem to be a problem, but in fact it forces the class to use a lot of redundant methods such as open , close , gc . For example, we use memcached to store session it automatically expire data that we do not need implements the function gc (garbage collector). To solve this problem, SessionHandlerInterface should be broken down into many smaller interfaces and focus on inseparable functions. For example:

5. Dependency inversion principle

Temporary translation: The principle of inverse dependence

The dependency inversion principle (DIP) states that high-level code should not depend on low-level code, and that abstractions should not depend upon details

To make it easier to understand, the closer the code to the machine language or the more basic things are called low-level code (for example, direct query of database, read and write down files, network etc.). What code handles logic and uses low-level libraries is called … high-level code.

This principle states that high-level code should not depend on low-level code. Instead high-level should depend on an abstraction that supports interaction with that low-level code, but should not depend on the details of that low-level code.

This may sound like a nag, but we can understand this principle more easily through the following DIP violation example:

Suppose we have an Authenticator class, this class directly interacts with MySQL, and uses the md5 function to encrypt passwords. Visibility of that class violates both the above principles of DIP. Because according to the above principle, Authenticator is a high-level code, it should not depend on code that interacts with MySQL (either Eloquent or raw SQL) and the specifics are to use md5 to hash the password.

Instead, both should be injected into Authenticator . This is beneficial that we can easily replace MySQL with NoSQL (or do other things like connect with Facebook, Google), and replace md5 with a more secure hashing or encryption function.

To understand and go into more details about Dependency Inversion / Injection. You can refer to the previous article Laravel: Dependency Injection and IoC container

Conclude

It can be said that SOLID Principles help us build larger systems, which are easier to expand and maintain. But as you can see, we have to abstract the application a bit, using more interfaces, typing a little more. Some people think: Too much Java . This is true if our code base is small and never changes. But in fact, no one wants the application / business to not develop. Again maybe it is nice problem to have . These principles are not new, but I believe it brings quite a lot of reasoning and tools to build large applications and easy maintenance for all developers (except for pure functional programming players). :grin: ).

ITZone via butchiso

Share the news now