How do you define a Single Responsibility?

The Single Responsibility Principle There are many obvious cases, e.g. CoffeeAndSoupFactory. Coffee and soup in the same appliance can lead to quite distasteful results. In this example, the appliance might be broken into a HotWaterGenerator and some kind of Stirrer. Then a new CoffeeFactory and SoupFactory can be built from those components and any accidental … Read more

Difference between OOP basics vs SOLID? [closed]

the answer is simple: languages or concepts which don’t support Encapsulation, Abstraction, Inheritance and Poly are not object oriented. If you do something object oriented you can always apply these OO basics, because they are available. One doesn’t call such things principles. SOLID in return is optional. When developing an OO design you should strive … Read more

Can anyone provide an example of the Liskov Substitution Principle (LSP) using Vehicles?

For me, this 1996 Quote from Uncle Bob (Robert C Martin) summarises the LSP best: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. In recent times, as an alternative to inheritance abstractions based on sub-classing from a (usually abstract) base/super class, we … Read more

What is an example of the Single Responsibility Principle? [closed]

The most effective way to break applications is to create GOD classes. Those are classes that keep track of a lot of information and have several responsibilities. One code change will most likely affect other parts of the class and therefore indirectly all other classes that use it. That in turn leads to an even … Read more

SOLID for functional programming

As far as I know (I’m no expert), SOLID principles do not tell anything about state. They should be applicable as well in a functional programming languages. They’re more advice about how to achieve modularity. Some of them are rather obvious or at least well-known. Single-responsibility is the UNIX principle “do one thing and do … Read more

Dependency Inversion Principle (SOLID) vs Encapsulation (Pillars of OOP)

Does IoC always break encapsulation, and therefore OOP? No, these are hierarchically related concerns. Encapsulation is one of the most misunderstood concepts in OOP, but I think the relationship is best described via Abstract Data Types (ADTs). Essentially, an ADT is a general description of data and associated behaviour. This description is abstract; it omits … Read more

Having a repository dependent on another repository

Repository should have single responsibility – persist one kind of entity. E.g. employees. If you have to delete some associated records from other repository, it looks like business logic. E.g. When employee is fired we should remove his work log And usual place for business logic is a domain services. This service will have both … Read more

Learning Single Responsibility Principle with C#

Let’s start with what does Single Responsibility Principle (SRP) actually mean: A class should have only one reason to change. This effectively means every object (class) should have a single responsibility, if a class has more than one responsibility these responsibilities become coupled and cannot be executed independently, i.e. changes in one can affect or … Read more