The Problem with Most Object-Oriented Designs and How to Fix It

Подписаться 1,7 тыс.

Просмотров 8 тыс.

50% 1

In this insightful video, David Scott Bernstein shares a transformative approach to software design, moving beyond traditional methods to create dynamic, flexible, and resilient systems. David explores the flaws of static design models and emphasizes the importance of using design patterns, abstractions, and polymorphism to shape a maintainable, effective domain model. He also touches on how these design principles extend beyond software development, offering valuable perspectives on logic, abstraction, and problem-solving. Plus, a sneak peek into a powerful upcoming video on Commonality and Variability Analysis-a game-changing design technique!
Key Takeaways: - Why traditional object-oriented design often fails. - The power of design patterns and polymorphism in building flexible software. - How mastering abstractions can lead to better software and broader life insights. - The critical role of separating concerns and managing dependencies.
Work with Me:
At The Passionate Programmer: to integrate AI into software development - PassProg.com
At To Be Agile: to integrate Agile Technical Practices into software development - ToBeAgile.com
I am now offering a limited number of coaching spots to integrate AI into software development for individual developers, software development teams, managers, and executives. To learn more, visit passprog.com/c....
Transform how you develop software with my Agile training for software developers. I offer comprehensive courses and personalized coaching to help you become an expert in Agile technical practices, the ones that make the biggest difference and include in-depth skills in Extreme Programming, design patterns, and refactoring. Learn more and start your journey here: ToBeAgile.com.
Expand Your Knowledge with My Books
“Beyond Legacy Code: Nine Practices to Extend the Life and Value of Your Software” Learn essential practices for writing quality code more rapidly and with fewer defects: BeyondLegacyCo...
“Prompt Engineering for Everyone: A Comprehensive Guide to Unlock the Potential of ChatGPT and AI Language Models.” Get actionable techniques to unlock the full potential of AI. Learn more at passprog.com/p...
Join the Conversation
Do you have questions, suggestions, or thoughts? Please share them in the comments below-I’d love to hear from you!
Next Video in the Series:
Check out more videos from my channel, @ThePassionateProgrammer -
/ @thepassionateprogrammer
#ThePassionateProgrammer #DavidScottBernstein #SoftwareDevelopment #AIPromptEngineering

Опубликовано:

21 окт 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 100

@davidboreham 4 дня назад

This would carry more weight if there were code examples.

@nickbarton3191 9 дней назад

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.

@ThePassionateProgrammer 8 дней назад

@@nickbarton3191 Wow, that happened to you too? Back in the day circa 1989 I built the dialogs for a program in OS/2 in two days, just the dialogs, but my manager thought I build the whole program. It was hard to convince her that there wasn’t any logic behind the buttons. Now I start with the business rules in testable objects and later I build the UI and I don’t put logic in the controls. I find I end up with a much better separation of concerns.

@nickbarton3191 8 дней назад

@@ThePassionateProgrammer Happened to me more recently, like 10 years ago, I built the front end AngularJS, HTML, CSS, lots of animation but dummy data. My guy wanted to start populating the database, lovely, well-meaning chap who did understand my explanation even though I'd already presented a project plan. DTOs are the best solution to UI separation, leaving the UI to deal only with presentation issues.

@jimmiller9330 9 дней назад

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

@user-mu6ii3jg1o 6 дней назад

But why obfuscation? OO is really a principle of encapsulation which can/is a good thing. OO is really nothing more.

@makiroll9960 2 дня назад

@@user-mu6ii3jg1o how about instead just having Module (Data)structs Functions ?

@jenreiss3107 11 дней назад

The common thread in this video is why I love functional programming so much. Writing code in a pure functional language like Haskell or Agda forces you to separate your domain logic from the side effects that it produces: for example, my side project is a distributed order management system for financial derivatives written in haskell, and the core logic of the program (sending, cancelling, rejecting, acknowledging orders) is all written as pure mathematical functions on the order state object of type OrderEvent -> OrderState -> OrderState (or OrderEvent -> State OrderEvent () for those in the know about monads). This means that given some set of order events, I can replay the order state basically for free because I don't need to rely on external side effects to maintain it.

@ThePassionateProgrammer 11 дней назад

That is really powerful. I find some problems lend themselves better for functional programming and others lend themselves better for object-oriented programming, and still others lend themselves better for using both.

@DevSofo 9 дней назад

You definitely seem passionate. Subbed 😊

@user-mu6ii3jg1o 6 дней назад

Not necessarily. Functional is only a paradigm. But design is agnostic to paradigms. You already admit to side-effects before even getting started - how long do you think you will last?

@jimiscott 6 дней назад

@@user-mu6ii3jg1o Exactly - how does Order State get persisted in the first place????

@gruntaxeman3740 5 дней назад

Functional programming: Imagine things to be as much as possible, stateless. Every data transformation happens using functions. It is really superior way to avoid coupling. Object oriented programming: It is about modelling concepts. Some concepts do have the state so OOP is engineering about those states, and mapping real world entities to objects. In context of programming, objects are just not only found from business processes like "customer", it is also technical objects like creating service that is lazy loaded when needed. Both paradigms have their place. OOP benefits a lot when there is something like "framework", something that has all concepts defined what to use solving business problems. OOP is more like having piece of data and writing functions to describe the logic like mathematician. I think we should use more functional programming because developers around a world write same loops in same problems in every software, instead of calling function to do things. Just think how long it take to get map/filter/reduce etc. type of functions to standard libraries used in OOP.

@theMuritz 4 дня назад

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

@torbjorngannholm3551 12 дней назад

As another old guy I agree with everything in this video, learned the hard way. Here is another pro tip: if you are focusing on what a thing IS, you are creating a dumb datatype for use in functional style programming. If you focus on what a thing DOES you are designing an object. Good code is usually made of both datatypes and objects.

@ThePassionateProgrammer 12 дней назад

Yes, well said. I like to say that there are really two things in OO and in the world: entities and behaviors. Entities own behaviors and understanding what entities should have what behavior is key to writing scalable object systems. I like how you put it. This distinction goes me beyond coding for me and helps me organize my thinking. I notice that the people who I see as great thinkers all do this (associating behaviors with the entities that own them) when they describe things.

@fredrikbergquist5734 8 дней назад

Niclaus Wirth said: ”a program is just code and data”. Isn’t this what you are saying? But the code comes before the data?

@torbjorngannholm3551 8 дней назад

@@fredrikbergquist5734 why does one come before the other? In functional programming, a function is also just a "thing", what it IS. So you could get a program to work that way. Or you could just look at behaviour, what it DOES and get a whole program to work that way. But that kind of purity tends to be awkward.

@torbjorngannholm3551 8 дней назад

I guess it might also be worth mentioning that the conventional wisdom for procedural programming is that the data structures are more important to defining the algorithm. To paraphrase Fred Brooks: Show me your code and conceal your data structures and I will forever be mystified. Show me your data structures and I won't need to see your code, it will be obvious. That said, procedural programming tends to be very low-level get stuck in the "how" to do something instead of describing "what" is being done, so you want to raise he level in either the FP or OO direction, or a mix.

@marna_li 11 дней назад

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.

@vladislavaleshaev7662 8 дней назад

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.

@ThePassionateProgrammer 6 дней назад

Actually, I do offer a course coming up later this year. More info here - tobeagile.com/training/ and you’ll also find lots of resources on my website. Enjoy and I hope to see you in class!

@user-mu6ii3jg1o 6 дней назад

In principal. Abstractions usually take a form of evolution so the effective realization of abstraction tends to come into being often later rather than sooner. Between now and then you have to put in the work to grind through the logic.

@clumsyjester459 2 дня назад

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.

@MatrixQ 7 дней назад

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

@fredrikbergquist5734 8 дней назад

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.

@rashadhatchett6677 13 дней назад

A lot of times we jump into the well headfirst when just a pebble or two can prepare us for a short fall or a long decent. A little design upfront can go a long way.

@ThePassionateProgrammer 13 дней назад

Great metaphor!

@Cdaprod 3 дня назад

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

@ThePassionateProgrammer 3 дня назад

You are so welcome. Thank you for sharing!

@williambyrne6855 8 дней назад

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.

@aboringfart413 4 дня назад

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?

@khatharrmalkavian3306 11 дней назад

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.

@ThePassionateProgrammer 11 дней назад

I totally agree!

@cbbcbb6803 9 дней назад

But, people are willy-nilly. They are not oo programs.

@johnridout6540 9 дней назад

I think OOP is fabulous for user interfaces and many other purposes, but with multi-threaded services I avoid mutable state as much as possible, which makes OOP a bad fit. I still use objects, but I don't approach it from an object oriented perspective. It's not the only tool we have and sometimes it's the wrong tool.

@sealsharp 6 дней назад

The teaching is stuck in mid 90ies "model the problem" attempts. How are you supposed to understand when abstraction is useful if you don't get data first? The guy who made OOP was a biology PhD who noticed that bodies are build from immensely complicated smaller cells which are treated by their behavior which was really simple compared to their internal complexity. So OOP principles gave us abstractions like a database-connection that allows to read from a db in 3 lines without needing to write or understand the 500.000 lines that are behind the abstraction. And somehow we ended up with IUserDataCreationFactoryProviderSetupSettingsBuilder. Stop that. Do actual work.

@TomBaldwin-n2u 4 дня назад

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! 😉

@dawnrazor 11 дней назад

I was very aware of design patterns from quite early on but I still couldn’t figure out why so many of projects still were not on the right track. When working on a particular problem that did not fit one of the gof patterns then I would mash up a new set of abstractions myself. I was still trying to apply solid, but when I look back on the many mistakes I made I can see now that I either didn’t understand the patterns well enough and/or forgot to keep solid at the forefront of my mind. One example of this is making liberal use of if statements to resolve problems rather than use abstractions resulting in many concerns being mixed together. If finally dawned on me that separation of concerns is of paramount importance EVERYWHERE not just when you feel like it and strong cohesion, minimised coupling with dependency injection. I feel like my designs are much better now but it is a constant headache making sure I keep these essential properties in my. I’m using golang as my daily driver so oo is out the window, but I also love the declarative approach so functional is a common weapon of choice, but I also have to keep in mind that too much functional can add runtime overhead potentially hitting performance. I love engineering but my god it’s really hard!!

@ThePassionateProgrammer 11 дней назад

Thank you for sharing that inspiring story. Yes, it can be easy for people to misapply design patterns or not really understand how to fulfill their intent, especially without a strong foundation in design principles and concepts like separation of concerns. Yes, engineering is challenging but it is also rewarding!

@amira-supermiemie 8 дней назад

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.

@ThePassionateProgrammer 6 дней назад

I totally agree. I think you are going to love my videos! Welcome.

@PulpFreePress 9 дней назад

I love browsing software design books too!

@AllanSavolainen 11 дней назад

As long as you don't do inheritance, it will probably be ok, though myself I would still stay away from OOP if possible, just put the data in structs and call some functions on them.

@ThePassionateProgrammer 11 дней назад

I agree that inheritance can be problematic when misused (and I see that a lot). I still use it for varying behavior but only one subclass level whose base class is abstract. Yeah, you’re right, we are better off without it. Since three of the five SOLID principles are really ‘rules of inheritance’ if we get rid of inheritance we’d just have SO. There are other aspects of OOP that make it valuable.

@AllanSavolainen 11 дней назад

@@ThePassionateProgrammer composition seems to be much more usable technique but it isn't OOP specific. Also there is the original OOP and modern interpretation of it. I do work with it daily, but when possible I prefer to go imperative ways with data and functions being separate. Dunno why but OOP never suited me outside maybe UIs coding or some game objects.

@jimiscott 6 дней назад

Inheritance when used judiciously is fantastic - plugins and addins gain most for allowing existing objects to be inherited and their behaviour modified to the specific needs of the plugin or addin. Composition becomes clumsy as you need to inject that composition (either via a property or constructor) OR you need to give the 'base' class a series of events.

@TheWiseRabbit 14 дней назад

This sound a bit like Hexagonal design (or whatever it's called) at least the part of collecting all business logic in one place not in objects. BTW what books suggested this obj hierarchies? That would be a good reference to have.

@ThePassionateProgrammer 13 дней назад

Nearly every book I’ve seen on software design say to first find the entities in the domain, identify common behavior, and compose hierarchies. In my experience, it leads to brittle code. I much prefer to first look for the abstractions and then look the the concrete entities. I learned this distinction from James Coplien’s doctoral thesis called “Multi-Paradigm for C++.” It kind of went unnoticed but I feel there are some important ideas in it. I hope to have a video about it soon and also one on hexagonal architecture.

@mehtubbhai9709 13 дней назад

Looking forward to these videos. Thanks!

@jimiscott 6 дней назад

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.

@davidboreham 4 дня назад

DI is just a fancy obfuscating name for global variables.

@jimiscott 4 дня назад

@@davidboreham No its not and you don't know what you're talking about.

@derekreed6798 10 дней назад

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'

@ThePassionateProgrammer 9 дней назад

You are welcome!

@Nellak2011 18 часов назад

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.😂 😂

@marko5734 12 дней назад

Do you believe DDD is the way to go? Does it solves the most important issues you mentioned?

@ThePassionateProgrammer 12 дней назад

I’m not sure there is just one ‘way to go’ for anything and the DDD book assumes you understand the basics but overall, yes, I think domain-driven design offers solutions to many problems that I thought were intractable. You probably don’t need it for writing simple scripts but for building enterprise software I find it invaluable.

@marko5734 11 дней назад

@@ThePassionateProgrammer Thank you for your reply, I appreciate it. It would be great if sometimes you can show examples for that topic.

@dylanjayatilaka8533 11 дней назад

I don't get it at all. I use the OO design philosophy, but it wasn't explained at all why "it sucks". There was a brief mention of variable method signatures causing havoc (which can be solved by putting those arguments into the object, right?). If those parameters are just set, the object can just "do the appropriate job". Another strange thing is this word "abstraction", but an object is just an abstract data type (ADT). But "abstraction" here sounds like a synonym for "pattern" or "design", which seems to me to be a way that ADTs or ovjects are supposed to interact? So it seems not a criticism of OO, but rather a higher level way of arranging how the objects are supposed to interact? But this is highly problem specific, no? There has to be myriad ways to do this, some better, some worse. So, I am very confused about what is being said. (I program large scale scientific software).

@ThePassionateProgrammer 11 дней назад

Thank you for your question! Steep inheritance hierarchies can lead to code duplication and fragment behavior, making it harder to maintain. Missing abstractions can make the code become disorganized and difficult to work with, especially as a project grows. Abstractions aren’t just about data types-they typically represent categories of behaviors that can be extended using polymorphism. This allows us to add new features or variations to the system with minimal changes to the existing code, which also reduces the risk of breaking other parts of the system. From a business perspective, this flexibility is crucial because it can lead to significant savings when the code needs to be extended or modified. I hope this helps clarify things a bit!

@dylanjayatilaka8533 11 дней назад

@@ThePassionateProgrammer So, are you saying that the polymorphic type, when properly instantiated with the correct genus, embodies the said business logic? So, abstraction = polymorphism? Sorry to press the point, but this abstraction word in the computer science context is hard to pin down. And yes, from painful experience, deep hierarchies can be tricky, since if you get them wrong, it is hard to reassemble the pyramid. But, does abstraction/polymorphism necessarily mean you avoid deep hierarchies? What is the key insight that would prevent this disease? (A person below mentioned Haskell and, I think, its typeclass idea, which confers some shared properties among the data types, it's similar to polymorphism except that there is no requirement that the data types be polymorphic, I think ... anyway I'll have to see the next video, thanks for your kind reply).

@ThePassionateProgrammer 11 дней назад

@@dylanjayatilaka8533 Thank you for your follow-up! It’s great that you’re digging deeper into these concepts, as they can definitely be tricky to wrap your head around at first. To clarify, abstraction and polymorphism are related but not the same thing. Abstraction is more about simplifying complex systems by hiding the details of how something works, focusing instead on what it does. Polymorphism, on the other hand, is a way to leverage abstraction-it allows you to treat different objects (that share a common behavior) uniformly. This doesn’t mean abstraction equals polymorphism, but polymorphism is one of the ways abstraction is often implemented, especially in object-oriented programming. Regarding deep inheritance hierarchies: you’re right-if you get them wrong, they can be tough to refactor. One key insight to avoid this issue is to favor composition over inheritance. Instead of deeply nesting classes, you can compose behavior by combining smaller, focused objects. This tends to make code more flexible and easier to modify as requirements evolve. And yes, Haskell’s typeclasses offer a different take on polymorphism where you don’t need a class hierarchy to share behavior. That’s a more functional approach compared to the object-oriented model, and it’s interesting to compare the two.

@cbbcbb6803 9 дней назад

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

@ThePassionateProgrammer 8 дней назад

@@cbbcbb6803 I think OOP helps us write more scalable systems that are much more complex than what we could build in procedural code back 20 years ago. Sometimes it is hard to see progress but if you remember what software was like 30 years ago like I can the difference is stark!

@user-mu6ii3jg1o 6 дней назад

Asking the wrong question. The quality of engineering in software is generally poor regardless of whether it is OO or not.

@carjaune6793 День назад

Nice desk

@ThePassionateProgrammer День назад

Thanks.

@perseus086 8 дней назад

Cool robot lamp

@ThePassionateProgrammer 6 дней назад

Thank you!

@atabac 8 дней назад

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.

@RealisableSoftware 6 дней назад

Wrong

@gruntaxeman3740 5 дней назад

Wrong. In management, software architecture actually very much also people management, what team handle what stuff, and those teams or developers communication channels are equal to software architecture. OOP is unrelated to that, also super developer that can create software alone (like I do) is not the point. I wrote those initial software versions and other people can jump on those, and it very important make understandable structure. We have software frameworks for purpose. Without software framework, I should document all details and conventions myself. With ready framework, those can be found from framework documentation.

@atabac 4 дня назад

@@gruntaxeman3740 wrong. software architecture and people management are two different things. frameworks doesnt care about how it is coded(like how strict OOP you used or some other code style shit), all of it are abstracted, all it matters is performance. extensibility can be solved by releasing new version. usability can be improved in next versions. you dont actually need to write documentation for frameworks you've written unless you intend it to be used by neophytes or non-technical because code itself is self-documenting.

@atabac 4 дня назад

@@RealisableSoftwareyour probably dont code in low level😆

@gruntaxeman3740 4 дня назад

@@atabac Code usually don't tell decisions what is lead to current design and it has mappings to surrounding world, and information of surrounding world isn't necessarily in code. Also it is very well known fact, that software architecture is same as team structure or communication channels between developers. This was observed back in 60's and it is true today. That is why we have for example microservices, because there are different teams working on different services independently. Also because humans do have limitations, it forces to make architecture decision because one dude can't efficiently work on 1M lines of code that is just one big chunk of dependencies that need to understand as whole. Even the super developer requires there architecture that he can work on module or component level without caring rest of the code base.

@jamesstelvin 9 дней назад

Dope

@danilomenoli 12 дней назад

non object oriented + procedural code is also crap, full of side effect triggered by cryptic combination of parameters, extremely hard to reuse and test. If someone says OO is crap and the person uses a functional language I can understand a bit his frustration, but someone that says OO is no good and this person programs in imperative style like a programmer from the 70's, I assume this person is a cowboy coder that is not on par with state of art of software development. It's always a grandpa (someone who started in the 70's with COBOL/C/Fortran) a HPC practitioner or a game dev. Game devs in particular, they write really awful code.

@Luis-Torres 12 дней назад

As a game dev who cares a lot about how I write code, I take offense to this 😆 Jokes aside, yeah game devs tend to write code very poorly😅😅

@ThePassionateProgrammer 12 дней назад

In case you didn’t notice, I am an old guy who got started in the ‘70… but I totally agree with you. It is a different world and today’s skills are not the ones we used long ago. I also agree that very few people know how to use OO for creating extensible code. Nearly every object-oriented program that I’ve reviewed (and I’ve reviewed hundreds of programs at the top companies in the world) is procedural code with a class statement wrapped around it. I rarely see behavior created through the interaction of objects, which is how OO gives us the most flexibility.

@ThePassionateProgrammer 12 дней назад

Yeah, I’ve seen some sloppy code from game developers but I’ve also seen game developers do things that I thought were impossible in code, so I also have a deep respect for game developers.

@SergeantZong 12 дней назад

@@Luis-Torres Right? Sometimes I peer review a piece of code and it's astonishing how bad someone can solve a problem

@danilomenoli 11 дней назад

@@ThePassionateProgrammer sorry didn't mean to offend hahaha, I've read your book and I know you recommend the opposite of staying in a single programming style for your whole career. Some people, however, just don't accept newer methodologies/languages other than what they are used to. Even Linus Torvalds, that guy is a living deity of programming but by the other hand I think his criticism on C++ is just too unfair.

@dreastonbikrain1896 9 дней назад

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.