1

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

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
oliver_siegel
  • 121
  • 4
  • Did you understand inheritance? Also, study several programming languages: C++, PHP, Ocaml, Smalltalk have a very different view of OOP.... – Basile Starynkevitch Aug 14 '14 at 09:13
  • That's a good start, but depending on the object model of any specific language a lot of details come to play in how a system behaves once things like inheritance start to get a bit more complex (eg C++ dreaded diamond). Also communication between classes needs well defined interfaces. You should look into design patterns to get an idea what problems may typically appear and how they can be solved. – thorsten müller Aug 14 '14 at 09:17
  • 7
    Start _answering_ questions about OO on here: the act of trying to explain something clearly is really helpful for consolidating your own knowledge (and the slightly meta _knowledge of your knowledge_), and as a bonus you'll see what other people think of your answers. – Useless Aug 14 '14 at 09:27
  • I've added an explanation about inheritance, because a couple of you mentioned it... – oliver_siegel Aug 14 '14 at 09:43
  • This question may be a duplicate of something, and needs fleshing out, but it is NOT a duplicate of the "well written code" question. – user949300 Jun 09 '17 at 22:43

3 Answers3

7

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?
amon
  • 132,749
  • 27
  • 279
  • 375
  • There we go! Thanks, those are some good questions to do more learning and research about!! :-) – oliver_siegel Aug 14 '14 at 10:00
  • 2
    Very nice answer! The only obvious omission is *messaging*, apart from that, I believe you got pretty much everything covered. I especially like the allusion to Cook re ADTs (this is often overlooked). Open recursion is also often forgotten. Maybe throw in a question about the relation between closures and objects, and OOP and mutable state. – Jörg W Mittag Aug 14 '14 at 11:20
  • +1, this list is excellent. But I feel it really needs to include the Fragile Base Class problem and composition vs inheritance. Inheritance is probably the most alluring yet problematic aspect of old-school OOP. – Doval Aug 14 '14 at 17:31
1

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)

utnapistim
  • 5,285
  • 16
  • 25
  • Thanks for the answer! How I see it, the things you mention under `you can look at classes as` are pretty much referring to different perspectives on scenarios how classes could be used. I pretty much look at each item in your list and I go like: Ok, `building blocks within a global design` ARE A `collection of functions with some global-ish variables` USED IN ORDER TO `reuse code and keep files short`. And I can basically apply it to each list item, even if I never came across the term before and have to guess its meaning (e.g. `actors within a protocol`). Please help my naive mind – oliver_siegel Aug 14 '14 at 09:53
  • 1
    "I pretty much look at each item in your list and I go like" - that was my point: as long as you do that, you oversimplify OOP, and miss a lot of it's nuances, advantages and proper ways to use it. Consider that OOP is not (necessarily) for code reuse/short files, but also for flexibility of implementation (see design patterns), modularity (protected/private), separating abstraction levels, expressing various concepts naturally (interfaces, abstract classes, concrete classes), fulfilling contracts between modules and so on. You have to understand these before having a "good grasp". – utnapistim Aug 14 '14 at 11:07
1

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

Mario T. Lanza
  • 1,700
  • 1
  • 13
  • 22