#solid design principles

[zenesysusa]

Learn the fundamentals of SOLID design principles and how to apply them effectively in your C# projects. This comprehensive guide covers each principle in detail, providing practical examples and real-world scenarios to illustrate their impact on software development. Gain a thorough understanding of how SOLID principles can enhance your code's maintainability, extensibility, and overall quality.

[myfreecourses]

[Skillshare] SOLID Design Principles In C# And .NET

[Skillshare] SOLID Design Principles In C# And .NET

This class teaches you the SOLID design principles using the C# programming language. The SOLID principles include:

• Single Responsibility Principle (SRP) • Open-Closed Principle (OCP) • Liskov Substitution Principle (LSP) • Interface Segregation Principle (ISP) • Dependency Inversion Principle (DIP)

In this class you’ll learn about these principles and see sample code that teaches you how to…

View On WordPress

[ltrainpr]

Open/Closed (OCP)--SOLID Design Principle

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

By open for extension, this principle means the ability for an entity to be adapted to meet the changing needs of an application. By closed for modification, this principle means that the adaptation of an entity should not result in modification of the entity’s source.

Interpretation: Open/Closed is for any given object; that object should not need to be modified in order to be used.

In JavaScript it is often used in situations where you want to extract functionality from a large function into other functions.  In other words, if you are having to change a function or class constantly due to updates or changes in requirements that's a sign of modification.  Instead extract the a base/super class/type and extend the behavior in child or subtype objects.

Seems easy but one of my mentors pointed out my violation of the Open/Closed principle when I added a compare method to the Array prototype in JavaScript.  My reply was 'don't you want to be able to compare arrays as part of the Array Prototype'?  Mentor's answer (which rocked my world): "In this case you're modifying the Array.prototype (globally) in order to add a convenience method. It could be considered "Extending" the Array class; but time and again this pattern of adding functionality onto an existing object/namespace/class at runtime bites people in the ass." 

He then pointed me toward underscore.js which is a library that has extended convenience JavaScript methods.  Lesson: Don't mess with something that works and is expected to respond in a specific manner. 

[malnewsome]

Single Responsibility Principle (SRP)

SOLID Principles are a set of object-oriented design principles that aid in the removal of code smells.   

The five SOLID Principles are:

Single Responsibility Principle Open-Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

The Single Responsibility Principle states:

A class should have only one reason to change.

The Single Responsibility Principle (SRP) is perhaps the easiest principle to understand conceptually, but tends to be the most often violated.  Because of this, let’s take a look at how to determine what responsibilities a class has.

1. Can you describe the behaviors of the class without using “and” or any other conjunction?

During my first code review of my Tic Tac Toe game, I was asked to explain what one of my classes was doing.  When I began explaining it out loud, it immediately occurred to me that my class had too many responsibilities when I could't describe it without using "and".  The interesting thing is that I didn’t realize it while I was actually writing the code.  

This proved to be an important lesson for me.  It was at this point that I realized the importance of verbalizing out loud what a class is doing.  It was also at this point that I determined I would make this a practice of my own from that point on. 

Referred to as Rubber Ducking, Andrew Hunt and David Thomas describe this technique in The Pragmatic Programmer with regards to debugging.  I’ve found it particularly useful anytime I’m reviewing the code that I’ve written.  Force yourself to explain out loud what your class is doing--whether or not there's anyone around for you to explain it to.  Doing so will help you spot if your class is doing too much. 

2. Do the behaviors of the class relate to the class name?

In order to explain this one, I’d like to show an example from my Tic Tac Toe game:

Here I have a class named GameSequence.  At this particular point in development, this class had more than one responsibility.  Can you spot it?

The game_over? method violates SRP.  I could have spotted this right away based on the fact that determining if the game is over is not a part of determining the game’s sequence.  I had already created a TicTacToeBoard class that was responsible for knowing the state of the board.  Determining if the game is over is obviously a better fit for that class.   

When checking for responsibilities, ask yourself if the behaviors of your class are related to the name of the class.  This can be an easy way to spot a SRP violation.

Why is SRP important?

The more often a class needs to change, the more difficult the application will be to maintain.  When a class has multiple reasons to change, you’re at risk of having a rigid and fragile application that can break easily when changes are made.  Further, having classes with single responsibilities makes it easier for others to understand what’s going on in the application and saves them time when they need to make changes for any reason.   

[ltrainpr]

Single Responsibility

Previously I blogged about the 5 SOLID Design Princinples.  Now I will break them down independently starting with Single Responsibility.

Most of the information and examples in this post are from Chapter 2 of Practical Objected Oriented Design in Ruby (aka POODR) by Sandi Metz.  I highly recommend reading this book.

Single Responsibility refers to classes and methods that do the smallest possible useful thing.  Applications that are easy to change consist of classes that are easy to reuse.  Reusable classes are pluggable units of well defined behavior that have few entanglements.  A class that has more than one responsibility is difficult to reuse.

One way to determine if a class has single responsibility is to ask it questions about its methods.  "Please Mr./Mrs. class what is/are method?"  Another way is to attempt to describe the class in one sentence.  If the simplest description has the word "and" then the class has more than one responsibility.  If it has "or" then the class has more than one responsibility and they aren't even very related.

When everything in a class is related to its central purpose, the class is said to be highly cohesive or to have a single responsibility.

Hide Instance Variables: Always wrap instance variables in accessor methods instead of directly referring to variables.  This changes the instance variable from data referenced all over to behavior which defined only once.

Hide Data Structures:  If the data coming into the class is a complicated data structure (i.e. array of arrays) then separate the structure from meaning.  A handy way to do this is with Structs.  Here is the example they use in POODR.  This style of code allows you to protect against changes in exteranlly owned data structures and to make your code more readable and intention revealing.

Extract extra responsibilities from methods:  Same way as classes; ask them questions about what they do and try to describe their responsibilities in a single sentence.  Guidelines: Separate iteration from the action that's being performed on each element.  Extract calculations that are not directly related to the single responsibility of the method.

Isolate Extra Responsibilities in Classes:  Here is the refactored example that moves the diameter method into the wheel struct.

Methods that have a single responsibility:

Expose previously hidden qualities.

Avoid the need for comments.

Encourage reuse.

Are easy to move to another class.

[ltrainpr]

5 SOLID Design Principles

In my journey to become a better developer I'm currently concentrating my efforts on design patterns and principles.  I came across this video by Sandi Metz on how the 5 SOLID design principles apply to Ruby.  SOLID is about managing the dependencies in your application.  

Single Responsibility (Coding Strategies): There should never be more than one reason for a class to change.

Open/Closed (is a Goal): A module should be open for extension but closed for modification.

Liskov Substitution: Subclasses should be substitutable for their base classes.  If you make a class Foo and a subclass Fooish you should be able to replace Fooish in any place you use a Foo.  If you don't do that, then the callers have to figure out what to do with that object and you've created a dependency.

Interface Segregation: Many client specific interfaces are better than one general purpose interface.  You care about this if you program in statically typed languages like Java or C++, does not apply to dynamic languages like Ruby.

Dependency Inversion (Coding Strategies): Depend upon abstractions. Do not depend upon concretions.

REFACTOR, NOT BECAUSE YOU KNOW THE ABSTRACTION, BUT BECAUSE YOU WANT TO FIND IT.  TDD is great but it's not enough.  DRY is an excellent thing, but it's not enough.  Design because you expect your application to succeed and the future to come.

The goal is to have strategies to achieve independence. Red, Green, Refactor.  Ask yourself (the correct answer is yes to all of them):

Is it DRY?

Does it have one responsibility?

Does everything in it change at the same rate?

Does it depend on things that change less often than it does?  Make a picture diagram that of the objects and their likelihood to change from less on the right to more on the left.  You want objects that change all the time dependent on objects that do not change much.

If one of these questions is no you should change something in your code. Triangle of Responsibility: Refactor, Extract, Inject.

Identify the responsibility you want to remove.

You make a new spec and a new class that has that code and no other code in it.

You take that code and you inject it back into your original class.

You follow this pattern until you don't have anymore responsibilities to take out.  Do the simplest thing possible; don't guess where you're going to end up.