Self-Evaluation: How do I know if I actually have a “good grasp” of OOP? [duplicate]

Question

This question already has answers here:

How would you know if you've written readable and easily maintainable code? [closed] (19 answers)

Closed 6 years ago.

If I skip the back story and any thoughts I have on this topic, there's really only one question left to ask:

How can I find out if I have a "good grasp" on OOP?

(I am specifically using PHP, but it probably won't matter...)

Right now I kind of think of classes as a collection of functions with some global-ish variables accessible by all those functions. This helps to reuse code, keep files short and the namespace clean.

Some of you mentioned inheritance: To me that again just means that I can extend an existing class with more functions and more global-ish variables. It's like an add on to my existing class. And the same benefits come into place: reuse code, keep files short.

I have a ominous feeling that I'll be disillusioned here in a minute...

Answer 1

I assume that I know a system sufficiently well, if…

• I know what parts of that system I don't know intimately. E.g., I might know that some obscure feature X exists, but I wouldn't know off hand how to use that. Having skimmed through all documentation can help here.

• I know how that system compares unfavourably to competing systems. I.e., I know the system close enough to know its warts. Knowing multiple sufficiently different systems is helpful here. In the case of OOP implementations, it would be interesting to compare Java with ECMAScript, as they are drastically different.

If you have a good grasp of OOP, you should be able to give an interesting answer to at least half of these questions:

• What is an object?
• What is a class?
• Do we need classes for OOP? What other possibilities are there?
• What is a method? How are methods different from ordinary functions/procedures/subroutines? How is a method call resolved?
• Why is there a this or self parameter/keyword in methods? What is open recursion?
• How is OOP different from other paradigms such as functional, procedural, or modular programming?
• How is OOP related to Abstract Data Types?
• What strategies for code reuse does OOP offer?
• How does inheritance work?
• What is multiple inheritance, and what are the problems associated with this? What possible solutions exist?
• What are classes, abstract classes, interfaces, mixins, and traits? (Note that most OOP implementations only offer some of these)
• Can you list a few common OOP design patterns? Which problems do they solve? Do you know OOP systems that don't require explicit implementation of these patterns?
• What are common OOP anti-patterns?
• What is the relation between the command pattern and functional programming?
• What is the relation between a constructor and a factory method?
• What is encapsulation?
• What does the acronym SOLID stand for?
• What is the single responsibility principle?
• What is the open/closed principle?
• What is the Liskov Substitution Principle?
• What is the depencency inversion principle? How can this be achieved?

Answer 2

How can I find out if I have a "good grasp" on OOP?

Normally, when I look at webinars (and read blog-posts and such), I try to see how many concepts I struggle with. Lately (in the past year or so) I tend to understand most of what I read. This is a very subjective question, by the way.

Right now I kind of think of classes as a collection of functions with some global-ish variables accessible by all those functions.

That's a limited view. You can also look at classes as:

• encapsulation units
• concept expressions (see "is-a" vs. "has-a")
• actors within a protocol
• building blocks within a global design

Things to look into:

• design patterns

• UML (models the relationships between objects quite nicely)

• method virtualization and "interface as a contract"

There are more, and some of them are only relevant in some contexts (for example, in C++ you can talk about regular and semi-regular types)

Answer 3

When I first forayed into the realm of truly understanding JavaScript, I subscribed to newsletters, read code for new libraries and frameworks, and read books and every interesting blog post I stumbled across. My appetite was voracious. But over time as I worked on JavaScript projects -- actual experience is essential -- and kept up my reading, I eventually noticed fewer fresh ideas. My JavaScript worldview shrunk. Much is familiar.

My more recent foray has been Functional Programming. I've grokked high-order functions, composition, currying, referential transparency, and most of the fundamentals, but I still tread into unfamiliar territory when I find posts related to Monads, Functors, and parts of Haskell. When you start to notice that your appetite has been satiated -- namely, it's harder to find something fresh and exciting -- that's when you've got a "good grasp."