Hot answers tagged

171

S = Single Responsibility Principle So I'd expect to see a well organised folder/file structure & Object Hierarchy. Each class/piece of functionality should be named that its functionality is very obvious, and it should only contain logic to perform that task. If you saw huge manager classes with thousand of lines of code, that would be a sign that ...


163

Basically we want things to behave sensibly. Consider the following problem: I am given a group of rectangles and I want to increase their area by 10%. So what I do is I set the length of the rectangle to 1.1 times what it was before. public void IncreaseRectangleSizeByTenPercent(IEnumerable<Rectangle> rectangles) { foreach(var rectangle in ...


131

Yes, it is a violation of the LSP. Liskov Substitution Principle requires that Preconditions cannot be strengthened in a subtype. Postconditions cannot be weakened in a subtype. Invariants of the supertype must be preserved in a subtype. History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (...


129

final expresses intent. It tells the user of a class, method or variable "This element is not supposed to change, and if you want to change it, you haven't understood the existing design." This is important because program architecture would be really, really hard if you had to anticipate that every class and every method you ever write might be changed to ...


86

Gosh, there are some weird misconceptions on what OCP and LSP and some are due to mismatch of some terminologies and confusing examples. Both principles are only the "same thing" if you implement them the same way. Patterns usually follow the principles in one way or another with few exceptions. The differences will be explained further down but first let ...


71

In many cartoons or other media, the forces of good and evil are often illustrated by an angel and a demon sitting on the character's shoulders. In our story here, instead of good and evil, we have SOLID on one shoulder, and YAGNI (You ain't gonna need it!) sitting on the other. SOLID principles taken to the max are best suited for huge, complex, ultra-...


62

Yes. This violates LSP. My suggestion is to add CanClose method/property to base task, so any task can tell if task in this state can be closed. It can also provide reason why. And remove the virtual from Close. Based on my comment: public class Task { public Status Status { get; private set; } public virtual bool CanClose(out String reason) { ...


58

It avoids the Fragile Base Class Problem. Every class comes with a set of implicit or explicit guarantees and invariants. The Liskov Substitution Principle mandates that all subtypes of that class must also provide all these guarantees. However, it is really easy to violate this if we don't use final. For example, let's have a password checker: public class ...


55

Modularity. Any decent language will give you the means to glue together pieces of code, but there's no general way to unglue a large piece of code without the programmer performing surgery on the source. By jamming a lot of tasks into one code construct, you rob yourself and others of the opportunity to combine its pieces in other ways, and introduce ...


40

No. SOLID exists as guidelines to account for inevitable change. Are you really never going to change your logging library, or target, or filtering, or formatting, or...? Are you really not going to change your caching library, or target, or strategy, or scoping, or...? Of course you are. At the very least, you're going to want to mock these things in a ...


37

I was in your shoes couple months ago till I found a very helpful article. Each principle is nicely explained with real-world situations that each software developer may face in their projects. I am cutting short here and pointing to the reference - S.O.L.I.D. Software Development, One Step at a Time. As pointed in comments, there is another very good pdf ...


35

Royal Family: They don't do anything particularly crazy but they have a billion titles and are related to most other royals somehow.


34

Yes, SOLID is a very good way to design code that can be easily tested. As a short primer: S - Single Responsibility Principle: An object should do exactly one thing, and should be the only object in the codebase that does that one thing. For instance, take a domain class, say an Invoice. The Invoice class should represent the data structure and business ...


34

I'll go through your points numerically, but first, there's something you should be very careful of: don't conflate how a consumer uses a library with how the library is implemented. Good examples of this are Entity Framework (which you yourself cite as a good library) and ASP.NET's MVC. Both of these do an awful lot under the hood with, for example, ...


34

Yes This is the whole point of the term "cross-cutting concern" - it means something that does not fit neatly in the SOLID principle. This is where idealism meets up with reality. People semi-new to SOLID and cross-cutting often run into this mental challenge. It's OK, don't freak out. Strive to put everything into terms of SOLID, but there are a few ...


33

It's always difficult to judge an approach based on a screencast, since the problems picked for demos are typically so small that applying principles like SOLID quickly makes it look like the solution is completely overengineered. I'd say SOLID principles are almost always useful. Once you become proficient with them, using them doesn't seem like something ...


31

I'm surprised that no one has yet mentioned Effective Java, 2nd Edition by Joshua Bloch (which should be required reading for every Java developer at least). Item 17 in the book discusses this in detail, and is titled: "Design and document for inheritance or else prohibit it". I won't repeat all the good advice in the book, but these particular paragraphs ...


30

Better maintenance, easy testing, faster bug-fixing are just (very pleasant) outcomes of applying SRP. The main reason (as Robert C. Matin puts it) is: A class should have one, and only one, reason to change. In other words, SRP raises change locality. SRP also promotes DRY code. As long as we have classes that have only one responsibility, we may ...


28

I think it's stated very well in that question which is one of the reasons that was voted so highly. Now when calling Close() on a Task, there is a chance the call will fail if it is a ProjectTask with the started status, when it wouldn't if it was a base Task. Imagine if you will: public void ProcessTaskAndClose(Task taskToProcess) { ...


28

[Note: I'm going to be talking about objects here. Objects is what object-oriented programming is about, after all, not classes.] What the responsibility of an object is depends mostly on your domain model. There are usually many ways to model the same domain, and you will choose one way or the other based on how the system is going to be used. As we all ...


27

If all your objects are immutable, there is no problem. Every Square is also a Rectangle. All the properties of a Rectangle are also properties of a Square. The problem begins when you add the ability to modify the objects. Or really - when you start passing arguments to the object, not just reading property getters. There are modifications that you can do ...


26

LSP applies to passing an instance of a class into a method, having the method do some stuff with that instance, and often produce some sort of result. This doesn't matter for static classes since in C# you cannot create an instance of a static class. Even more importantly, static classes are sealed and therefore cannot be inherited. This makes your ...


26

Dependency Inversion in OOP means that you code against an interface which is then provided by an implementation in an object. Languages that support higher language functions can often solve simple dependency inversion problems by passing behaviour as a function instead of an object which implements an interface in the OO-sense. In such languages, the ...


24

Don't IOC containers break a lot of these principles? In theory? No. IoC containers are just a tool. You can have objects that have a single responsibility, well separated interfaces, can't have their behavior modified once written, etc. In practice? Absolutely. I mean, I've heard not a few programmers say that they use IoC containers specifically to ...


24

For logging I think it is. Logging is pervasive and generally unrelated to the service functionality. It's common and well-understood to use the logging framework singleton patterns. If you don't, you're creating and injecting loggers everywhere and you don't want that. One issue from the above is that someone will say 'but how can I test logging?'. My ...


23

I submit that this anti-pattern be named Jack of All Trades, or perhaps Too Many Hats.


22

First of all, TDD does not strictly force you to write SOLID code. You could do TDD and create one big mess if you wanted to. Of course, knowing SOLID principles helps, because otherwise you may just end up not having a good answer to many of your problems, and hence write bad code accompanied by bad tests. If you already know about SOLID principles, TDD ...


22

Tackling each of these at a time: Regarding the Project Structure This one can be subjective at the best of times, but projects are typically structured by logically dividing your code into sub-folders or sub-projects based on their general area of responsibility, or which 'layers' they belong to. For example, Models, Views, Controllers, Core ...


22

The single responsibility principle can be tricky to understand. What I've found useful is to think of it like how you write sentences. You don't try to cram a lot of ideas into a single sentence. Each sentence should state one idea clearly and defer the details. For example, if you wanted to define a car, you would say: A road vehicle, typically with ...


21

my project managers told me that I am really in the wrong way and too idealist for the Bank world. GTFO! Time to leave and pity them. Why should you give a fuck? You know it'll cost them money in the long run with their incompetent staff. This ain't a game of technical discussion. This is about politics. Have them train the other developers or GTFO! If ...



Only top voted, non community-wiki answers of a minimum length are eligible