The S.O.L.I.D. Principles of OO & Agile Design - Uncle Bob Martin
Why Stack Overflow recommends it
Stack Overflow users link it when explaining SOLID, especially the open-closed principle, and as a well-regarded overview from the person who popularised the principles.
Recommended by 1 people across 1 different months, 2015 to 2020.
Why Software Engineering Stack Exchange recommends it
Software Engineering Stack Exchange users link it as a reference for what SOLID, the open/closed principle and dependency inversion actually mean, and for Martin's own view that polymorphism is the real gain of OO.
Recommended by 0 people across 0 different months, 2015 to 2021.
What it is
A recorded meetup talk by Robert C. 'Uncle Bob' Martin on the SOLID principles of object-oriented and agile design, given at the Schaumburg Microsoft .NET Technologies Meetup in 2015. He mixes the principles with the history of programming, decoupling, objects and polymorphism, and touches on single responsibility and dependency inversion near the end.
What people said
Recommends andnik · 2018-01 · Stack Overflow · on “OCP, is the client or the abstract class hiearchy open-closed?”
There is an example that I like: [LINK] It's written in Java, but nonetheless, hope that's readable. I also love Uncle Bob Martin seminar on SOLID principles [this video] . The thing about OCP is to make code your code extendable to new functionality. Now to you example, let's say you have: abstract class A { public string GetString(string str) { return Format(str); } public virtual string Format(string str) { return str; }; } class B: A { public override string Format(string str) { return $"%{str}%"; } } Let's say that abstract class A is in the library and you are using it, but want to extend with some formatting method Format. Now, it's not the best real world example, you probably would use f
Cites radarbob · 2015-04 · Software Engineering Stack Exchange · on “Dealing with class optional dependencies”
You seem to be getting at the Open/Close principle [this video] here. Frequent class modification suggests a a design issue of some kind. A coherent class would tend to not change - at best would change for one reason; i.e. it's responsibility changed. [LINK]
Cites bill schwarz · 2015-07 · Stack Overflow · on “Is there any Mathematical Model or Theory behind Programming Languages?”
There is no mathematical model for OOP. Relational algebra in the mathemaical model for SQL. It was created bt E.F. Codd. C.J. Date was also a reknown cientist who helped with this theory. The whole idea is that you can do every operation as a set operation, affecting a lot of values at the same time. This of course means that the database engine has to be told WHAT to get out, and the database is able to optimize your query. Both Codd and Date criticized SQL because they were involved in the theory, but they were not involved in the creation of SQL. See this video: [LINK] There is a lot of information from Chris Date. I remember that Date criticized the SQL programming language as being a t
Cites Robert Jørgensgaard Engdahl · 2016-06 · Software Engineering Stack Exchange · on “Dependency Inversion expands the API, results in unnecessary tests”
I'd go with: Should I realise that expanding the API is a downside of Dependency Inversion, and be very clear about why I chose not to comply to it here? - Supports iteration 2 However, in The S.O.L.I.D. Principles of OO and Agile Design [this video] (a at 1:08:55) Uncle Bob says that his rule about dependency injection is don't inject everything, you inject only at strategic locations. (He also mentions that the topics of dependency inversion and dependency injection are the same). That is, dependency inversion is not meant to be applied on all class dependencies in a program. You should do it at strategic locations (when it pays of (or might pay of)).
Cites Taras Boychuk · 2020-08 · Stack Overflow · on “Annotations in domain objects with JPA violates Database is a detail”
Please check out this very similar question : Are persistence annotations in domain objects a bad practice? [LINK] I think that as engineers we should be pragmatic. Any best practices, principles, or "guru suggestions" should help. They should not make things worse. So I suggest to treat them as guidance, not strict rules . For instance, I generally agree that "database is a detail". But we rarely change that detail. On the other hand, annotations do not execute any code. And the coupling is not so bad. Your domain object can be a JPA entity at the same time , and it will be very clean and useful. By the way, this does not violate the Single Responsibility Principle (SPR) . If you thought it
Cites Alexander · 2021-03 · Software Engineering Stack Exchange · on “Does encapsulation in OOP happen at run time or compile time?”
Yeah, it's a common (IMO) misconception that trigger my well ackchuyually [LINK] reflex. Out of the three main traits attributed to OO (encapsulation, inheritance and polymorphism), encapsulation is worse (compare to opaque pointers in C. or returning a closure in a functional programming language, you can't look at the local vars inside even if you wanted), inheritance is "eh". Only polymorphism significantly improved. Bob martin talks about it here: [this video]