OOP concepts confusion?

Question

While reading some programming books, I notice that the authors says that, in OOP, you may have some confusion while understanding the main idea of OOP.

And hell yeah!. I had some confusion. Did you have the same and what makes this confusion to programmers(even experienced programmers)?!

And if you had it, how could you beat this ?!

Thanks

Answer 1

The Animal trope works when explaining it to most people.

(Further useful links here and here)

Answer 2

A lot of the confusion when learning OOP comes from trying to pick the right relationship between objects and classes of objects, particularly whether:

• Object contains Some other Object (or Object1 has an Object2)
• Object is an instance of Class

If I can think of a good example that shows a case where either might be appropriate, I'll add it...

Answer 3

OOP takes a "problem oriented" approach to programming as opposed to the traditional "machine oriented" approach used in languages like C and Pascal. Learning OOP can be quite tough if you've programmed extensively in procedural/functional languages. It is to these programmers that things tend to be more confusing. If you are new to programming, you'll probably find things a lot less confusing since you're starting off with a fresh mind.

Having said that, I've seen many programmers who've worked extensively with languages like Java and claim to be good OOP programmers when they were actually far from it. Sure they use Java language features like interfaces, inheritance etc, and create objects "which are instances of classes", and "send a message to an object". Most people use a lot of OOP jargon because they are exposed to it. But when it comes down to writing a simple application their resulting code exposes their poor understanding.

My advise to you is don't get caught in using jargon alone. Question and learn the underlying concepts diligently. You might have your first semi-nirvana (like I did) when you learn polymorphism and the benefits it brings to code re-usability. Another semi-nirvana when you understand the trade-offs between reuse via inheritance and reuse via composition. In the end, you will know that you've understood OOP well if you able to design well, or rather, a good OO design is easily a good measure of how well you understand OOP.

If you are serious about OOP, you should read the first two chapters of the GOF book on Design Patterns. It might be a little tough on new programmers, but it lays the crux of the thinking behind OOP. This book is an important reference which any serious OOP programmer should have. If you understand the concepts in this book well, consider yourself to be a good OO programmer.