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
I think that especially programmers, that were experienced in the development with function-oriented languages, had trouble understanding the concepts of OOP. At least, it was really confusing to me and i did a whole bunch of things to program functional while using an OOP language(Java).
But i also think that the OOP approach is a great thing to beginners because this approach ist very "natural".
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 ClassIf I can think of a good example that shows a case where either might be appropriate, I'll add it...
Thank you for your answers.
I think giving examples works best but not every time, right ?!
I heared the creator of C++ when he said, it takes time and patience and you will understand it better by trying.
I never really had any confusion but I learned programming along the time-axis it evolved. so I had assembly, c, c++, java, c# and loads of other which is not relevant here. What you have to embrace is that everything shall be expressed by an object and an object contains information describing itself (properties) and that they can perform tasks related to them (methods i.E.: Car.GetAllCars();).
For inheritance and polymorphism and all the rest I recommend practice. practice everything - since practice makes perfect. Try to develop the examples given in all the books.
Once you understand the oo basics take a look at design patterns and design principles (e.g. by reading Head First Design Patterns). It will teach you how you should actually use the tools that oo gives you. While this is no substitute for practical experience it can certainly speed up the learning process.
Yes, I experienced a bit of confusion initially. This was back in the day when OO was just starting to become mainstream, so there were a lot of books out there which covered it, but didn't explain it well for people who didn't already know what it was. As a result, I started out thinking that an object and a class were largely interchangeable and defining a new class for each object I wanted to create.
I finally "got it" by playing around on LambdaMOO, a MUD (think World of Warcraft, but with no graphics) with an object-oriented in-game programming language. Ironically, MOOCode makes no distinction between classes and objects - objects inherit directly from other objects. (It did have a convention of objects intended for use as "base classes" to be named "Generic Foo" as a way to distinguish them from specific ("instance") Foos, but that's as close to a class/object distinction as it had.)
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.
Indeed, I think way too much emphasis is put on the 'class' concept.
The biggest leap forward in my understanding was when reading about the "Tell, don't Ask" principle.
I only started 'feeling' Object Orientation when playing around with (and reading about) duck-typed environments like Ruby, JavaScript, Python etc... after like 8 years happily creating truckloads of classes in C++.
Statically typed languages are great for production code, but you pay a lot of overhead when trying to get a feeling for Object Orientation.
Also, next to the commonly used term OOP, often one forgets that first comes OO**A** and OO**D**.