SOLID in practices
SOLID is a good practice to get into and I've been using it for years now and I have found a lot of benefits using it. This can be from designing. usability\readability of the code and even when it comes to source control.
Saying this, its easier used when your with a new project. If your inherit an old project, which does not have any best practices and the code can have thousands of thousands of lines of codes in a class. Hundred lines of code within a method and DUPLICATION.

This is my understanding and how I've implemented it with old and new projects.
My implementation and understanding maybe not 100%!
IF my understanding is not 100% Please comment below and let me know.
I'm open to all opinions.

Single Responsibility Principle
Define:This means that every class, or similar structure, in your code should have only one job to do. Everything in that class should be related to a single purpose. Our class should not be like a Swiss knife wherein if one of them needs to be changed then the entire tool needs to be altered. It does not mean that your classes should only contain one method or property. There may be many members as long as they relate to the single responsibility.
The Single Responsibility Principle gives us a good way of identifying classes at the design phase of an application and it makes you think of all the ways a class can change.

This is one of the main elements within SOLID I use, but as I have inherited an older system somethings this can't be used or I have to rewrite a lot of code. (Depending on time constraints)

Designing - You design your class\classes with a given logic requires only.
Readability\Debugging - As a class has a single logic requirement, the class name should tell a developer what the class does. The once within the class, the class should be small and easy to read and navigate.
Source control - As the logic is done within an isolated class outside classes or methods already within the solution. Normally a single developer would be working on a element of logic (class). So when it come to committing that change it would a class, which no other developer should be working on.

Open/Closed Principle
Define:The Open/closed Principle says "A software module/class is open for extension and closed for modification".
Here "Open for extension" means, we need to design our module/class in such a way that the new functionality can be added only when new requirements are generated. "Closed for modification" means we have already developed a class and it has gone through unit testing. We should then not alter it until we find bugs.

Designing - You can design the new logic in isolation and not worry about effecting other elements or codes.
Readability\Debugging - When going through the code and there is new logic, this within its own isolated element and not written to try and fit into the current logic.
The current method or class does not end up a hundred of lines,
Source control - As the logic is done within an isolated class outside classes or methods which its resolving, The chances of any conflicts are minimal as your adding a ref to a new class\method and not removing. 9 times out of 10, you would not remove the current logic as it may need for something.
But you do need to make sure the code make sense and another developer would know whats going on.

Liskov substitution Principle
Define:The Liskov Substitution Principle (LSP) states that "you should be able to use any derived class instead of a parent class and have it behave in the same manner without modification". It ensures that a derived class does not affect the behavior of the parent class, in other words that a derived class must be substitutable for its base class.
This principle is just an extension of the Open Close Principle and it means that we must ensure that new derived classes extend the base classes without changing their behavior. I will explain this with a real world example that violates LSP..

Interface Segregation Principle
Define:The Interface Segregation Principle states "that clients should not be forced to implement interfaces they don't use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module.".
Like classes, each interface should have a specific purpose/responsibility (refer to SRP). You shouldn't be forced to implement an interface when your object doesn't share that purpose. The larger the interface, the more likely it includes methods that not all implementers can do. That's the essence of the Interface Segregation Principle.

Each time I need new interfaces, I create an interface class just for a single logic.
This keeps my interface classes small. This may not be the best way, but I find it working well.
I must say that I am quite new to interfaces

Designing - When you design the Interface class, you don't need to think of all it can do, but only what you need it to do at that time .
Size - The size of the class, will be smaller and much more readable.

Dependency Inversion Principle
Define:The Dependency Inversion Principle (DIP) states that high-level modules/classes should not depend upon low-level modules/classes. Both should depend upon abstractions. Secondly, abstractions should not depend upon details. Details should depend upon abstractions.

Created: 13/09/2016 Total Comment: 0


(Not Displayed)
Human validation
Enter 6132 number, before submitting to confirm your human
[Home] [All Blogs] [Contact] [Me]