ASPNET C# SOLID Principles [EN]

Hi,

Today I want to start a sequence of 6 posts about SOLID Principles in C#.

Let’s to start:

The theory about SOLID Principles was created by Robert C. Martin in his article, well-known: “Principles of Design and Design Patterns”.

Few years later, Michael Feathers became this theory to acronym mnemonic.

Basically, he separated e detailed 5 design principles with the responsability to become the software projects more flexible, easy to maintenance and understandable to other developers.

This article, I just want explain the basic theory of each principles. The next articles I’ll write more details and easy real examples using .Net C#.

Let’s Go:

1. Single Responsability: The method must have just one action. You need to have only one reason to change the method. After you finish your function, please, read it and try to find two reasons to modification. If you find, something is wrong! If you need to expand this method, you need to create one abstraction. For example: You have a SAVE method. It’s just to SAVE the object in database. Nothing more! This method can’t to valid field, send email, get information, etc. It’s good when you need to create unit test just to valid specific action, you won’t have the same code in different class.
2. Open/Close: The software functions must be open to expand and close to change. If you have a method that is working correctly and need to expansion, you can’t to change this method. You need to create another method which inherits from that the main method and create this modification inside there using all the responsability already existed.
3. Liskov Substituition: This is about inheritances! Inheritances are totally powerful and effective mechanisms, however you need to know how to use them correctly. The goal of this principle is: The class and methods must be substituible only for instances of the same types. If you apply this principle you’ll have separation of modules by functions and actions.
4. Interface Segregation: “Many interfaces with few methods are better than few interfaces with many methods.” This is clean code! You need to create specific interfaces for specific actions. If you look your code, sometimes you’ll find one method that shouldn’t be there. Maybe, it should be in another class or interface.
5. Dependency Inversion: This is the only principle that I have never used. This principle can show to us that is always better depend of abstractions than objects because the abstractions will change less and facilitate behavioral changes. You’ll find easy way when you need to evolve your code if use this principle.

Done! This is the resume about each principle! Now, I want to show some strong and weak points.

Strong Points:

• Facilitate to maintance, understanding and evolution of the code.
• Code reuse for other functionalities.
• Fast adaptation to project/design changes. (We know how many times it happen)
• Easy code to evolve without chances of happen problems with functions already working.
• Methods ready to be tested decoupled.

Weaknesses:

• Possibility of having reclated codes.
• Code without structure/pattern.
• Difficulty to understand the function to develop changes.
• Difficulty to get good results from the test.
• Almost impossible reusable code because everything is mixed.
• Facility to happen bugs and problems.

Then that’s it. The SOLID Principles need to be studied and showed more, but today I just wanted to show a “overview” about all principles. The next articles I’ll detail and show real examples and help the developers to develop good codes and delivery best results.

I’m forward to all comments, suggestions and examples to help this subject and article!

Thanks very much and see you soon! =)