Project anecdote coming up. I worked on one project, late 90s, about 30 developers, the management had things so buttoned down that the open-plan office was as quiet as a library. I suppose they thought that better progress could be made if everyone was seen to have their nose to the grindstone. Anyway, I was just leaving one evening and I got talking shop with a colleague on another team, and suddenly we realised that our respective subsystems weren't going to work correctly with each other. So I went to admonish the project lead about why no-one talked, he stared at me like an owl caught in headlights, "say what". Nothing changed. Teams need a culture of collaboration and communication, can't be done through specifications. Projects that really worked, there was always a quiet but insistent hum, I always listen for it as a first impression of the health of a project.

Love the thumbnail!!

The problem with oo designs is the obfuscation of the functions. Which is why functional programming is making a comeback. Viva Elixir!

I initiated with FORTRAN and ASSEMBLER and COBOL. I instantiated with C#.NET, Java and other object oriented languages because that is what the client asked for and they paid me money for it. Soon my finalization will come as I complete the loop of life. For now OO ...there it is.

I was always fascinated that God gave Adam the responsibility of naming the animals. Just shows how important lexicography is.

The most vital things NO ONE talks about. They keep hashing the same daft examples involving shapes or animals.

You are always complaining about everything.

Modula3 ?

Please consider this constructive criticism and not bitching. I've watched three of your videos and, so far, most are hand-waving and don't really instruct or inform. It is easy and pleasurable to talk in platitudes, but actually moving people's processes forward requires more meat. This video is entitled "How to Create ELEGANT SOFTWARE DESIGNS", but how much of the content actually taught that? Love your idea, waiting for the delivery.

Yep, I for one would like to see an example of this thought process.

I tried to write a php unit test today that checked the return value of a method. Inside the method needed to fetch a bunch of objects and get one property from them with a getter. So I mocked the getter giving the value and the value inside the object ended up being null. I had no idea why and I was on a tight deadline and didn't have time to start debugging how the library was not doing it, so I commented out the test and left a comment saying what the test was supposed to do and whoever was welcome to fix it.

uh oh, you just killed Kotlin

I came to programming from a background in architecture and planning, so I was familiar with Chris Alexander's "A Pattern Language" trilogy before reading Design Patterns. I suspect you've read them too.

Where have you been all my life!

Thank you for your passion and for sharing valuable information

What's the difference between extension and modification?

His code is so closed source in every video it suddenly became "open" thanks to the open-closed principle 😂

Yes, I like your compromise, I've never added features to an existing system where I didn't have to do at least some refactoring. But I like your idea of reviewing looking for weaknesses which would prevent OC principle.

Your videos and your channel is an oasis in a desert of madness. Sadly we developers spend time learning tools and architectures that never solve the real issues. Simplicity is key here and i see that the past years whenever i solve a problem well, i do it using simple and well tested principles, followed by good tests and generally make it easy enough to be extended with new requirements all else are white noise. Keep it up, the value your videos provide is huge!

Please continue doing both

When I hear OOP devs talk about encapsulation and inheritance, it is mentally translated to: "Make your program hard to test" and "Make your program tightly coupled by over engineering" Then they say this is good design.😂 😂

Nice desk

I don't have enough experience as a developer, but I think OOP is mostly suitable for use cases where parallelization is hard anyways and where abstractions themselves are actually valuable. The best case I know of is web development. Every request is unique and isolated and you can't really parallelize them. And if done right, most classes and objects conform to some business rule, legal entity or process. But I would try to use as little OOP as possible in other fields.

The point in this video is about Offensive Design & Offensive Programming in opposition to Defensive Design & Defensive Programming which lack intention, thus responsibility, hence making your code garbage.

This all sounds scary, like a cult welcome speech or a programme from the Matrix talking

Thanks so much love the passion. I’ll be sharing this

Another good video As an aside, it was OOP which informed Alistair Cockburn's 1990 "Crystal" methodologies Teams have their own data. They have their own processes. They look after themselves. They have Events. They have the public & private. Abstractions The parallels are there Most organisations are like spaghetti code, GOTO statements & Global variables! 😉

OO programmers don't add 1 and 2. They create abstract numberFactory classes and instantiate a numberOneSingleton object and a numberTwoSingleton object. Then they create an interface class for abstract classes including an add method. Or was it an abstract class for interface classes?

This would carry more weight if there were code examples.

You deserve my sub fellow white beard … it’s refreshing to have a mature face talking calmly and competently

IMO your point around DI is wrong. In large systems DI is almost a requirement as you end up having to implement a DI solution.

David, can you please expand on ways to measure improvements.

I was the same when I found that design pattern book. So eye opening.

Good observation. I think the original ideas of Object orientation has been lost throughout the years. People are locked in in those so called best practices without understanding the root and essence of the object orientation. It’s not OOP it has way more applications than just programming. Engineers should learn how to think not just follow paradigms and methodologies.

Cool robot lamp

Completely agree! For less experienced developers as me, where would you suggest starting to learn this approach-focusing on abstraction and designing software from that foundation? Specifically, are there any resources, such as books, courses, or examples, that you would recommend to help understand how to effectively organize business logic, processes, and maintain a clear division of concerns? It would be great to know if you offer a course or could point to some valuable examples on this topic.

object orientation approach was basically for management people and neophyte developers who are not really into technical stuff. it does not work for super developer who works alone and can finish large, complex, software by himself.

Began with K&R's C in the early 80s and embraced Bjarne Stroustrup's C++ not long thereafter. But decades later, the Design Patterns dictate was the absent-minded middle-management directive that gave credence to the same middle-management that knew none the better. However, today's non-poly object modeling is perfectly okay. The wide support for interface abstractions serves the vast majority of requirements. And I'll wager that AI language infrastructure is non-polymorphic.

My experience is that the UX developers have too much influence in the design of the project. The business model isn’t defined first. The boss says that the buyer of the commercial product only sees the UI so that is the most important.

Smart constructors, I've only recently discovered them.

Love your enthusiasm. Definitely don't start with the UI, it leads to a ball of mud of cross coupling. There's another downside, managers think that you've finished if they see a UI.

OOP- Obfuscation oriented programming. When no one else can understand your code. The key to job security.

People created computer programs before OOP was created. How, then, did anything get done?

Dope

I love browsing software design books too!

This video as all the other OOP: books, videos, and uncles - sounds chaotic vague an unscientific. No proof, no explanation, only opinions and "trust me"-s.

I have come across this saying alot; 'Do it right first time'. The premise with this is 'to be perfect'. This premise totally goes against agile's 'good enough' and incrementally improvement (and life). To take on the philosophy 'do it right first time' stifles any creative process by making you fearful of getting things wrong.

Funny I came across this (well maybe not it just shows the algorithm is working). I have been asked to look over our OOP code with the remit of making it more flexible based on interfaces/abstraction. Thanks for your reflections they are very much 'food for thought'

I keep hearing people gripe about OOP and when I ask them what's bothering them they immediately start complaining about the consequences of all the things you're not supposed to be doing in the first place. I suppose the real downside to OOP is lack of education. It's too easy to pick up a language and start using all the features willy-nilly, but until you learn the basic design principles you're always going to have a mess on your hands.

Another passionate developer here! This is the first time I watching your videos. I'm someone who likes to reason stuff, twist and turn things to finds out how to best understand them. I think OOP, as a modeling tool, is great if you know how to use the language, its structures, to model higher-level concepts through abstraction. I mean thinking abstractly, not using "abstract" classes. I see to many developers who are locked into viewing what they build in terms of the constructs use, rather than the meaning, what it represents. What makes your (one's) approach OOP is not that the language has classes, but that you can model objects and all that comes with it, even dealing with the side effects - using the full range of expressiveness that come from combining multiple paradigms. Hopefully, in an intuitive way.