The Problem with Most Object-Oriented Designs and How to Fix It
Вставка
- Опубліковано 12 жов 2024
- 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
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.
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.
You definitely seem passionate. Subbed 😊
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.
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.
Great metaphor!
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.
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.
People created computer programs before OOP was created. How, then, did anything get done?
I love browsing software design books too!
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!!
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!
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.
I totally agree!
But, people are willy-nilly.
They are not oo programs.
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.
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.
Looking forward to these videos. Thanks!
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.
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.
@@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.
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'
You are welcome!
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).
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!
@@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).
@@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.
Do you believe DDD is the way to go? Does it solves the most important issues you mentioned?
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.
@@ThePassionateProgrammer Thank you for your reply, I appreciate it. It would be great if sometimes you can show examples for that topic.
OOP- Obfuscation oriented design.
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.
Dope
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.
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😅😅
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.
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.
@@Luis-Torres Right? Sometimes I peer review a piece of code and it's astonishing how bad someone can solve a problem
@@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.