What is SOLID?

  • The acronym SOLID stands for Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle
  • SOLID is a set of software design principles that can be used in conjunction with object-oriented programming and design. Robert C. Martin introduced the underlying concepts of SOLID in 1995 with his 11 commandments of object-oriented programming (OOP). Michael Feathers coined the acronym SOLID in the early 2000s as a mnemonic device for remembering the first five concepts.

What is SOLID Purpose?

  • SOLID is a set of design principles, it does not teach people how to program. Instead, SOLID principles help programmers write better code
  • •The goal is code will be more robust and usable

Why SOLID?

  • The answer to “Why SOLID?” is simply that SOLID principles produce better code
  • SOLID principles to counteract developers habits of writing code containing thousands of lines and numerous methods or functions in a class 

Dirty Code Detector

Does the code implement a design pattern?

  • Adopting a design pattern in your code or program is not compulsory
  • Use your best judgment to decide whether or not you want to implement patterns
  • Patterns provide an extra, coated layer to your program so that you can write robustly with little chance of falling.

Is the code tightly coupled?

  • In software engineering, coupling is the manner and degree of interdependence between software modules; a measure of how closely connected two routines or module
  • This means your application or software is tightly coupled, which means your code qualifies as dirty code 

Is the code testable?

  • Advantages the code is testable

It reduces the reworking time needed due to any unrecovered issue.

It provides ability-testing code within code.

It reduces the time needed for debugging code—with the help of test-driven development (TDD) we can easily and quickly locate problems.

It allows for easy determination of whether or not recent changes or refactoring broke the code.

  • Writing tests may be unpleasant and time-consuming, but tests are important 
  • TDD helps us to improve code quality and draw our focus to the main purpose of our task 

Is the code human readable?

  • Because your code will be read by humans, it should be meaningful code.
  • In order to make your method name meaningful, don’t hesitate to use a long name such as Is ValidForCharactersOnly
  • Visit your code and see if you can read it. If not, that means you are writing bad code.

Is the code duplicated?

  • Create a Common class if you can’t decide where to place your common code
  • avoid and remove any redundant code
  • It’s a good idea to visit your code many times, and in different ways, in order to check for redundancy
  • For example, you can write Console.WriteLine(“SOLID Principles Succinctly!”); instead of System.Console.WriteLine(“SOLID Principles Succinctly!”); if you have already added ‘namespace.’ In this case, ‘System’ is redundant and can be removed.

Is the code too lengthy to understand?

  • Avoid writing lengthy code.
  • A function can be hard to understand if it contains thousands of lines.
  • Lengthy code caused hard to understand especially for new Developers.
  • We can mark our code as bad code if we are writing lengthy functions or methods when we could instead break them into small and meaningful functions.

Solid understanding

SOLID principles are neither laws nor rules—they are principles intended to help us to write neat code. By following SOLID principles, our code can be easily extended and maintained

Single Responsibility Principle

A class should have only one responsibility. Let’s say our class is responsible for saving data. That means it should not also be responsible for retrieving data or any other tasks.

Open-Closed Principle

Once a class has been written, it should not allow anyone to make changes. No one should be able to go back and amend the class code in order to implement new functionalities.

Liskov Substitution Principle

A dependent object should be able to use any object of type parent object.

Interface Segregation Principle 

A smaller interface is recommended. If an interface has one method, there will be only one place to change if we need to change the code. However, in the case of interfaces with more methods, there might be more reasons for change.

Dependency Inversion Principle 

Put simply, this addresses loose coupling. With the help of DIP, we can write code that does not depend upon concrete classes.

Visit Software Architect Indonesia Community to get more knowledge.

Reference:

SOLID Principles by Gaurav Kumar Arora.

Author

Seorang ayah dari 3 anak, yang mempunyai mimpi menjadi sebaik-baiknya manusia yaitu manusia yang paling bermanfaat.

Write A Comment