What is the middle ground between understanding basic OOP concepts (inheritance, composition, aggregation) and design/architectural patterns?

Question

I've been coding in python for about 6 years now. I am proficient enough to understand a good amount of the language features. When I look into source code for a number of libraries such as pandas or requests I'm able to understand a good deal of what is going on.

I've worked with python long enough to develop a real feeling for object oriented programming. I understand key concepts like inheritance, composition and aggregation. I recently learned more about type hinting so that I can statically check my code and be more aware of the types that are flowing through my program.

Over the years, I've also developed a bit of an obsession with design patterns. I bought the GoF book which I consult regularly. I also study the code on websites such as refactoring.guru or sourcemaking to try to get a better grasp on OOP and truly implement this in my code.

Unfortunately, aside from minimal/academic examples concocted for educational purposes, I have never really been able to build truly object oriented code in a production setting. Every time I try, my code gets way too complex, and I end up falling back on more simple patterns like functions. Don't get me wrong, I know that classes are useful in programming, but I just fail to make use of them such that they make my life easier. In contrast, I can see the use of higher order functions, so I use those sometimes to great effect.

I feel like there must be some sort of middle ground between the two extremes:

• Understanding the basic building blocks of OOP ((multiple) inheritance, composition, aggregation, nominal/structural subtyping, the diamond problem)
• Understanding full-blown design patterns and patterns of patterns (such as MVC)

I doubt that even experienced programmers decide what design pattern they want to use before they start coding. I feel like they probably start coding and use a couple of key concepts to organize code into classes as they go. What am I missing to start incorporating classes into my work such that they can help, rather than hamper me? What is the middle ground?

Answer 1

I've been coding in python for about 6 years now.

Here's your problem.

I've also developed a bit of an obsession with design patterns. I bought the GoF book which I consult regularly.

It's like you're saying you've been practicing your football skills every day and still can't make the basketball team.

I end up falling back on more simple patterns like functions.

The GoF book was written about patterns found in languages that wont let you do that. It's not that your code isn't good OOP. It's that your language doesn't require many of the work arounds that C++, Java, and C# do (or did). You have higher order functions. Use them. OOP doesn't mind at all. Because the patterns book isn't about what is and isn't good OOP. It's about what we had to do to make things work with what we had back then.

And that's as much as I'll defend them. Keep in mind, the GoF book authors have all been convicted for crimes against computer science.

Answer 2

I would say you're coming at this from a difficult direction.

What some of us like to do is to consider (1) the problem domain, and (2) what kind of automation you're trying to offer to help in that problem domain.

For example, in a domain of books & libraries, are you trying to allow full text search, or title/ISBN cataloging, or tracking of who has what copies of which books?  What kind of automation you're trying to do determines the abstractions you'll want to model.  Then we use objects to model these abstractions, we use classes to construct the objects.  But the level of detail needed to implement varies depending the automation we're trying to do.  Do we need separate classes for hard cover and soft cover?  Probably not, rather an instance field that indicates what kind of book it is — unless we have substantially differing behaviors between these kinds of books.  Figuring this out requires analysis of the automation we are attempting in support of the problem domain.  Design patterns have almost nothing to do with this kind of design.

Yes, we can use design patterns, mostly as workarounds for missing language features.  Yes, we can use objects, classes, inheritance.  But all of that should be motivated by an overall thoughtful design, which goes to the problem domain and the automation we're trying to bring to bear.  Figure that out, then determine the entities that you need to model, their behaviors, and their relationships, and model that.  Once you have those conceptual notions, you can start to think about code design.  And if you run into some issue where the programming language you're using doesn't easily do something you'd like then look for a design pattern (or switch to a programming language that has that feature).

The thoughtful design should probably start by identifying the persistent state of and which entities and their relationships that you want to model.  That persistent state should support adding new entities, new relationships, and answering queries you need in the automation you're providing to the problem domain.  This persistence of course, can evolve, but probably is more fundamental to design than writing classes with inheritance or using design patterns.

Answer 3

You seem to have put "write a proper OOP application" on your bucket list. As long as you do not run into problems that call for OOP solutions it may take a while before your dream will come true.

It is not like "Here's a problem... now how can I apply all these OOP principles I learned about?" It is more like recognizing one or more of these patterns in your problem after a straightforward approach has proved to be insufficient.

An OOP principle or any problem solving approach addresses a particular issue. If you do not have any of these issues, all the better. Applying patterns is never the goal, creating a comprehensible solution to your problem is.

It is a common thing though. If you get some tool for your birthday you will start looking for reasons to use it and will likely do more damage with it than good. Or maybe that's just me.

Answer 4

You started your question by writing about design patterns, but later you write:

I know that classes are useful in programming, but I just fail to make use of them such that they make my life easier.

And in the end you ask:

What am I missing to start incorporating classes into my work such that they can help, rather than hamper me?

It seems like you are jumping ahead slightly more advanced design techniques before really getting the basics of OOP. You mention the basic here:

Understanding the basic building blocks of OOP ((multiple) inheritance, composition, aggregation, nominal/structural subtyping, the diamond problem)

What is striking to me is that you left some of the most important aspects of OOP: Abstractions, especially polymorphism. I claim you can write object oriented code without inheritance and subtyping, but you can't without using abstractions.

The topic is too deep to get into it in this post, and there is plenty of resources about it. But let me leave some suggestions on how you can improve:

• forget about design patterns for a while, design patterns are great tools to solve problem.
• Read about polymorphism and try finding applications for polymorphism in your code.
• read about SOLID principles. I found Robert Martin's books Clean Architecture does a very good job at explaining them, but there is plenty of sites about that topic as well.
• Python is not a very strict language, with many aspects of OOP like typing and encapsulation left to the programmer. Try using a stricter language like Java or C# that makes you think about accessibility and interfaces. This is not to say that these languages are better, but force you to think differently about programming. It never hurts to learn another popular language, and knowing another language will also make you a better Python programmer, since the same concepts still apply even when not being explicit.
• see where you get stuck with applying these concepts to your code and then go back to design patterns and how they can solve some of these issues