What is the correct way of learning OOP deeply?
The Head First Object Oriented Analysis and Design Book would be the first place to start.
Then maybe Fowler's Refactoring
Unfortunately, the answer in how to learn OOP deeply is practice. It is only after years of designing and constructing object oriented systems that one instinctively sees the pitfalls of a particular design, or the merits of another. Books will probably give you a good kick-start on that route, but they can only get you so far.
I think the best way to learn is to write programs. Practice a lot. There are a couple of sites and books to get you started, www.oodesign.com for example. But you'll never get realy good at anything without practice.
Another way is to do some pair programming with someone that's very experienced already. Give Corey Haines a call.
Others listed here good books. Buy one from these or one of your preference. You should google for "oop best practices" "design patterns" "gang of four" and such.
Then try to learn something from them, think of them deeply. If you are not experienced all the hussle to get experienced at once is futile but you have to try it hardly in some iterative way.
My way was that 1) I read about it and thought about it deeply. 2) Made some code 3) I've got the design patterns and books again and checked what i should have done some other way. You can ask your experienced friends too but NEVER forget thet they are just humans and experience not necessariliy means deep knowledge. 4) goto 1 :)
Try that way. Read, try, then self-inspection (and other's peer review) is the way to be deeply experienced.
Have a good luck!
There is no substitute to actually using object-oriented programming to learn about object-oriented programming.
Books are indeed a good source for information, but without actually writing programs and designing programs, it's difficult to learn object-oriented programming. It's going to require a few "ah-ha" moments before really appreciating OOP and design patterns.
One suggestion I could add is to take a look at how object-oriented programming is used in software projects. If you're into Java, you can take a look at the Java API and see how classes are designed.
Making an library or API (just for fun) can be a good exercise. It will require making classes and having certain parts of exposed to the user, using design patterns for implementing certain features, and can overall be a pretty good practice for designing in an object-oriented manner. Try to emulate the design of good APIs are designed; after all, it's probably best to learn from people who do a good job at what you want to learn. For Java, the Java Collections Framework is a fairly well-designed API.
I've said it before (here, at work, the pub, and to anyone who will listen!) and I'm now going to say it again: For me the best OO book I've ever read was Object Oriented Software Construction 2nd Edition, see gushing praise and amazon link.
This book looks at OO from a language design point of view. I.e. if you were designing a OO language what features would you need to support and why. It may sound heavy but I found it a compelling read. This book is all about how to think OO. My favourite example from the book is this:
Suppose you had to write a psuedo random number generator, what sort of class heirarchy would you design? He then discusses some of the not so good possible solutions, but dismisses those for this:
[Sequence]
|
[Psuedo Random Number Sequence]
The sequence class has MoveNext and GetCurrent abstract methods. I've not expressed it too well here but meyer spends a couple of pages on this example. Trust me, it's one of those rare books that will make you a better programmer forever.
Learning Smalltalk would be a good way to learn real OOP.
But beware: Not everyone has the same definition of OOP. OO feels different in Smalltalk (+ Ruby), Java, and CLOS.
You can roughly carve up "deep learning" of most domains into four components:
- Study
- Drill
- Reflective practice
- Teaching
There isn't a particular order in which you'll do those. I suspect that most people don't start with study; they dabble in something, decide they like it and then take it seriously.
Study consists of reading books, articles, Web sites and so on. Also consider seeking OO code that others consider good, and asking them what makes it good. Don't just read about code, also make sure to read lots of code.
"Drill" is probably the most overlooked area in the practice of programming: writing code that you intend to throw away, not for the sake of its functionality or of solving a problem, but solely to get the "moves" as close to perfect as you can. (Check out "Coding Dojos" for one format that seems to work well.)
Reflective practice is just using your new skills on regular projects, but taking care to pause regularly to assess how well you're doing and if you should reorient your learning in this or that direction.
Finally, and also often overlooked, an excellent way to learn something deeply is to (try to) teach it to others who are beginners compared to you. Write an article, or mentor a junior programmer. This forces you to articulate your own insights.
Be patient with your own learning and with others'. Deep learning, i.e. striving for mastery, is a process that takes a lot of time. There are estimates that it takes 10 000 hours of practice, over a decade, to attain true mastery of any domain.
Anything you learn, don't forget two things:
- object self-containment
- the DRY principle
If your code violates either of them, you've got something wrong - no matter the OOP patterns involved.