Many client-specific interfaces can work better than one general-purpose interface.įor example, to develop a behavior for a multifunctional car, there are vehicles that we can only drive and there are vehicles that we can only fly. This states that no client should be forced to depend on methods it does not need or should not use. Monitors.Where(m => m.Type = type).ToList() Public List FilterByType(IEnumerable monitors, In other words, it should be easy to extend the functionality of classes without having to modify them.Ĭonsider the following example which deals with the filtering of computer monitors by type and screen: This pattern is useful for lowering the chance of bugs, and means “Open for extension, closed for modification” Public void Print(PersonDetails personDetails)Ĭonsole.WriteLine('Name: ' + personDetails.Name) Ĭonsole.WriteLine('Age: ' + ()) Ĭonsole.WriteLine('Identifier: ' + personDetails.Identifier) We overcome this by separating unrelated code.Īnd creating a new class to handle the responsibility of printing: More potential complexities will ensue if it is decided we want to add other unrelated functionality such save the person to disk too. It is not just holding details of a person but printing it too. The problem is that this class has more than one responsibility. PersonDetails person1 = new PersonDetails Consider the class PersonalDetails whose responsibility is to hold details about a person:Ĭonsole.WriteLine('Age: ' + Age.ToString()) Ĭonsole.WriteLine('Identifier: ' + Identifier) Īfter instantiating, we then use a public method to print out the details of that person: A summary of SOLID Principles as implemented in the C# language.Įvery class should have only one responsibility.

Principle app animation cheat sheet