solid-principles

I know about "class having a single reason to change". Now, what is that exactly? Are there some smells/signs that could tell that class does not have a single responsibility? Or could the real answer hide in YAGNI and only refactor to a single responsibility the first time your class changes? 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

I was recently having a debate about the Dependency Inversion Principle , Inversion of Control and Dependency Injection . In relation to this topic we were debating whether these principles violate one of the pillars of OOP, namely Encapsulation . My understanding of these things is: The Dependency Inversion Principle implies that objects should depend upon abstractions, not concretions - this is the fundamental principle upon which the Inversion of Control pattern and Dependency Injection are implemented. Inversion of Control is a pattern implementation of the Dependency Inversion Principle,

Have any one used the SOLID programming principle (or any of it's parts) while developing JavaScript? I've just started up on reading on it but can't seem to find anyone that used it for JS. The only part I find easy to implement/use is the "Single responsibility principle". What I'm looking for is articles or example where these principles are used. And are there any argument's why one shouldn't use some parts? For example the "Interface segregation principle" says that "the notion that many client specific interfaces are better than one general purpose interface." But from my knowledge there

Robert Martin says: "There should never be more than one reason for a class to change" . Let's consider the ViewModel class which is bound to a View. It is possible (or even probable) that the ViewModel consists of properties that are not really related to each other. For small views the ViewModel may be quite coherent, but while the application gets more complex the ViewModel will expose data that will be subject to change for different and unrelated reasons . Should we worry about the SRP principle in the case of ViewModel class or not? gcores The ViewModel single responsibility is to

I have an interface public interface ITrnsitReport { List<UserDefinedType> GetTransitReportData (); } And it has only one implementation which is public class TransitReport : ITrnsitReport { private IValidateInput _inputValidation = null; private readonly ITransitRepository _transitRepo = null; public TransitReport (IValidateInput inputValidation, ITransitRepository transitRepo) { _inputValidation = inputValidation; _transitRepo = transitRepo; } public List<UserDefinedType> GetTransitReportData (string input1, string input2) { List<UserDefinedType> ppdcReportList = null; bool isValid =

In the database world, we have normalisation. You can start with a design, crank the steps and end up with a normal form of the database. This is done on the basis of the semantics of the data and can be thought of as a series of design refactorings. In object orientated design, we have the SOLID principals and various other adhoc guidelines towards good design. Do you think it is possible to define the equivalent of normal forms for OO, such that a series of refactoring steps could move a procedural piece of code (or poorly factored OO design) into a correct (in some well-defined sense)

I would like to learn about the One Class, One Responsibility principle. I have found some articles about it, but without examples. It would help me if you can give me an example of a class that violates the principle. I'm familiar with the idea that a method should do only one thing, for instance get and set methods. It must not be the same as One Class, One Responsibility , because set and get methods are both implemented inside a class. So does this mean the class is violating the rule because the class has responsibilities both to set and to get? What is the One Class, One Responsibility