
Ask HN: How to Learn OOP - ympavan
I want to learn Object-oriented programming.
When I was in college I had learnt few concepts, but now I don&#x27;t remember most of the things.
Also, presently my work doesn&#x27;t demand to learn object-oriented concepts or OOP.<p>Any suggestions on:
 how&#x2F;where to start?
 which book to refer?
======
qwertyuiop924
Here's the OOP model:

A program can be modelled as a set of communicating black-box objects, with
their own state.

The idea is to separate concerns, abstracting away implementation behind well-
defined interfaces, which can in turn be implemented by other objects to
cleanly replace parts of the application.

The rest of OO is pretty much just understanding Design Patterns (a set of
names for common interactions between objects, and methods for setting these
interactions up), grokking inheritance, and the difference between inheritance
and composition, and grasping how to design a good OO system (how thickly to
layer your classes, how much abstraction and what sorts, etc.)

The best languages for learning OO are Ruby and Smalltalk.

~~~
tonyjstark
This is actually a really good summary. I also agree on learning Smalltalk to
learn OOP since it has a really easy syntax, you can deep dive into
implementation details if you want to easily and it enforces some best
practices like setter and getter instead of giving you the ability to just
declare members public. I learned Java in University and switched soon to
Objective-C and it took me a while to see reasons behind getters and setters
especially since I worked only in small teams on short living projects at that
time. Also s Smalltalk is purely OOP so you won't get distracted by numbers
and bools behaving differently. And finally it gets you to think in data
structures thanks to the collection methods.

~~~
qwertyuiop924
Yup.

Getters and setters only really work in programming languages with good
metaprogramming support. In Java and Objective-C, they're ungainly and
awkward. In Smalltalk and Ruby, they just kind of happen.

------
thebigspacefuck
I didn't learn OOP very well in school, but once I wrote enough code I started
to see that it was becoming a massive cluster fuck and I couldn't remember
what I wrote half the time. So I broke it down into functions, but then I was
passing huge amounts of arguments into some of the functions. Then I realized
I had a lot of functions where the 90% of same thing was happening so I passed
a keyword into the function to make it do something slightly differently in an
if else. Then I realized I could create a class, store the variables in the
class and call the class methods without passing the arguments, which was much
cleaner. Then I realized that I could create a class that inherits and
overrides the 10% difference of the other class, which was again much cleaner.
Those are the basic two problems that OOP solved for me and I've taken it many
steps further a couple of times, but it can definitely be abused. If you get
to that point, you should start looking at design patterns to learn how OOP is
used correctly. Lynda.com has some good videos on OOP design patterns you can
use their free trial for. They're by the author of one of the highest rated
books on design patterns and pretty short.

~~~
wpietri
This is a great explanation of how to really start seeing objects. Like you, I
just look for data that travels together. Then I find code that only ever gets
used on that data. I pull it out and figure out a name for it. This
observational approach avoids a ton of architecture astronautics, where people
dream up giant object hierarchies and stick with them no matter what the code
is telling them.

The main compliment I'd suggest to this approach is Eric Evans' book Domain-
Driven Design: [https://www.amazon.com/Domain-Driven-Design-Tackling-
Complex...](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-
Software/dp/0321125215)

In a bottom-up approach, you can often break things down in a variety of ways.
But the most stable/useful ways are often the ones that align with the
conceptual model of the domain. If I notice that certain data and behavior
goes together with incoming money, I might call that an
InboundMoneyWorkingUnit. But if I talk to people who've spent years working in
the domain, I'll realize the object should be called Payment, and their
description of what a Payment does will inform my hunt for other objects and
methods.

------
osullivj
You don't mention a language; I suggest you pick one then look for a good free
text. For example, choose Python then go for Mark Pilgrim's Dive into Python.
I'm sure others could make recommendations for C#, Java, Ruby or JavaScript. A
good view of OOP in a relatively language neutral manner if the GoF patterns
book: Johnson, Gamma, Helm, Vlissides Design Patterns. It summarised state of
the art OOP in the mid 90s and was a big influence on Java. Things have moved
on since then, and IMHO, other techniques for structuring your code are just
as important as OOP. I'd highlight generic programming, asynchrony and
coroutines. There's a lot to discover and enjoy - good luck!

------
klibertp
Could you tell us what kind of experience you have? There are many ways of
learning OOP and they vary greatly in how approachable they are depending on
your previous experience.

If you come from a procedural programming in a low-level language like C, for
example, there is an excellent book "Object Oriented C", which teaches you OO
concepts by implementing them in C.

If you do GUI programming in a procedural language (again, mostly C) you could
download Pharo and go through "Pharo by Example".

These are just examples - there are much more languages/books combos out
there.

------
thorsteneckel
Practical Object-Oriented Design in Ruby (POODR) by Sandi Metz opened doors
for me - [http://www.poodr.com/](http://www.poodr.com/)

~~~
rimantas
If you only get one book, get this one. It is more about 'why' than about
'how' and shows what tradeofs are involved in one or another design, what
problems you can run into with different solutions. Also, there is a new book
by Sandi coming out:
[http://www.sandimetz.com/99bottles/](http://www.sandimetz.com/99bottles/) Her
talks are highly recommended too.

~~~
xwvvvvwx
Sandi Metz is great.

This talk is such an amazing example of clear thinking:

[https://www.youtube.com/watch?v=8bZh5LMaSmE](https://www.youtube.com/watch?v=8bZh5LMaSmE)

~~~
vinceguidry
I actually watched that talk twice. The technique of introducing a seam set
off light bulbs in my head that didn't go off the first time I watched it.

------
AlexCoventry
Look for Uncle Bob's talks on SOLID design.

[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod](http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod)

------
icecold12741
You can always check out Object Oriented Analysis and Design by Head First
([http://www.headfirstlabs.com/books/hfooad/](http://www.headfirstlabs.com/books/hfooad/)).
Their books are more about learning the concepts than the theory so they
employ a lot of games and learning activities. They are a lot more interesting
than a textbook on OO, even if the format seems a little juvenile at time (I
mean they have word-searches and crosswords with key terms).

~~~
teh_klev
That's a terrible book (and series) to learn from, the level of visual clutter
on each page distracts from the actual task of learning anything. I had a copy
of "Head First Design Patterns" and after only a few pages I thought my eyes
were going to fall out.

I found Bruce Eckel's "Thinking In Java" useful back in day to learn OO
programming and concepts. Much of what you learn is transferable to other
languages.

------
allendoerfer
As soon as you know a little bit, I would start as soon as possible to learn
by copying existing code. Learn by using different frameworks, which show you
how to do things.

The classic OOP examples ("This class is a car, this Mercedes class inherits
from the car class, it also has a method to move, and this Mercedes object is
an instance of a Mercedes") are pretty easy to grasp for a person of normal
intelligence. The frustration is to then apply this when you are stuck
thinking in a procedural or functional model. However once you have learned
for example how to handle a database connection, you start to apply that on
your own and when a similar problem comes along, you start to notice patterns:
"This is really similar to the db object, I know I did right, because I just
copied the concept, so I will do this in a similar way." After that learning
the design patterns is quite easy, too. But at first knowing what - in this
example a - singleton is does not get you anywhere, because generally you do
not know how to start.

~~~
llamaz
If you think inheritance is central to OOP, then you are mistaken. The most
important aspect of OOP is dynamic dispatch (e.g. objects accessed through
Java interfaces), and that's closely related to the idea of messaging. Have a
read of what other people are writing here.

~~~
kazinator
A language without classes that feature inheritance (at least single) can be
used for OOP, but cannot be said to have support for it. It may not be
central, but it is important.

Java Interfaces are in fact an example of inheritance. Moreover, they are an
example of "non OOP inheritance": it's an inheritance of type checking that
actually doesn't bring any attributes to an object. It exists in support of
compiler diagnostics and compile-time optimization of dispatch.

In some languages (even ones that _do_ support inheritance very well) objects
of different types can be substitutable over a common set of functions without
any explicit inheritance of interfaces or anything.

We can make a Dog and Cat class in complete isolation from each other, with no
common dependency, and give them a speak() method. Then pass an instance of
either class to some function which just calls arg.speak(). This produces
"bark!" if arg is a Dog, or "meow!" if it is a Cat.

A Java-style interface just makes this dispatch easier to optimize via a
static type system, and to implement checks. The function cannot call
arg.speak() unless arg is a reference to an ICanSpeak type. That is assured
externally because code which passes anything else to that function will not
compile. Thus Dog and Cat must inherit this ICanSpeak, which causes their
instances to be eligible as arguments to that function. When they implement
speak(), their implementation is type-checked against ICanSpeak's speak(): to
have the right number of properly typed arguments.

------
whamlastxmas
What I always recommend and didn't see in the comments at a glance:

Think of something you want to build, then build it. Learn the language as you
go along. Pick whichever language seems like a good choice for your particular
project (based on popular opinion). Learning OOP and how to build applications
in one language transfers to other languages without much effort.

You also learn how to break down projects to simple tasks with this. If you
want to build Facebook, first you need to have a simple HTML file. Then it
needs to be served by Apache/Nginx. Then it needs JavaScript for UI behavior,
then it needs a back-end framework for routing requests, then it needs a
database for data persistence. Most projects can be broken down like this to
make learning not the equivalent of drinking from a fire hose.

------
jorgeleo
Take a behavior. Pull the nouns (classes) and what they are told to do
(methods). Finally, I don't need to know how you do what you do, that is your
problem, not mine.

Very oversimplified, but that is what it is. See the pieces that you are
playing with, and they can receive messages asking them to do something, this
will be method calling. This describes objects and message passing.

Sometimes different parts need to respond to the same message, think on a car:
push pedal, it means to release gas into the engine to the gas pedal, but it
means squeeze the wheels to the brake pedal. Welcome to polymorphism.

And when I press a pedal I don;t need to know how it accomplish what I am
asking to do. In a gas engine means releasing more gas, but in a tesla it
means reducing resistance between the batteries and the motors. That would be
encapsulation.

And by the way, think also in the instrument panel, they don't go asking then
engine "what are you doing now", instead they just display whatever
information the engine is volunteering. The engine makes a little wire spin,
and the speedometer shows the speed. That would be the bases for the
observable pattern. There are others, but this one helps abstract the engine
it self from the car body. In other words, the UI should be nothing but one
example on how a user can interact with the engine, for this you need to build
your engine without thinking in ui. This would be how to structure an oo app.

------
dreta
If you’re going to learn OOP, you need a larger project to go along with it so
that you can understand ASAP that it only makes you write more code, over-
complicate problems, and makes your applications hard to understand, and
debug. It’s going to save you from spiralling into the typical “OOP is fine,
i’m just not doing it right, i should’ve designed that differently” loop that
most college graduates go through during their first professional years.

~~~
rkangel
(Over)using inheritance hierarchies can have negative effects, but if you
think that in general OOP results in more code then you need to go and develop
some serious C. You spend a lot of time manually accounting for multiple
instances of things, in a way that you get for free in an OOP language like
C++.

~~~
dreta
Right now i do iOS development mostly in pure C, outside of the unavoidable
Objective-C. So i do have the right experience.

The issue with OOP is that as soon as you introduce inheritance, and things
like virtual functions, you’re introducing variable program behaviour based on
context. And most of the time you end up having to special-case things up in
the hierarchy because nothing ever goes as you envisioned it.

Structuring your code so that you have simple data and code that operates on
the data means that what’s happening in the code at a particular time is
always explicit, and any deviations based on objects the code operates on are
right there in front of you, not hidden in 4 virtual function implementations
in different files.

It’s all special-case code you have to write anyway, but if written in OOP
fashion, the complexity of it is most of the time unclear, and it’s hard to
judge what code will actually be doing just by glancing at it.

------
ilaksh
Come up with an interesting project to work on in your favorite language. Keep
adding more features until some functions have a lot of parameters. Then
Google to see how you can group the variables together into objects so you
don't have to pass so many variables around. Then just keep doing that in your
new programs. After a few months or years you will get used to organizing code
that way.

One thing you should not bother doing is to order giant piles of paper just so
that you can say you read X famous author on OOP or Design Patterns or
whatever. That is a waste of time and money now that we have Google and
blogs/online articles etc. And anyway you are going to learn by doing it for X
years or months, not by reading a book.

Also, be careful because people will to make it seem much more complicated
than it is. The more complex or subtle aspects you are probably only going to
remember or understand if you learn them through practice anyway.

------
caruso_g
[https://learnpythonthehardway.org/](https://learnpythonthehardway.org/)

------
dmux
I'd highly recommend Dr. David West's "Object Thinking" book. It does an
excellent job of (1) describing how most programmers who use an OO language
fall into writing "small Cobol" programs and (2) how to avoid this.

~~~
kzisme
Link for the lazy: [https://www.amazon.com/Object-Thinking-Developer-
Reference-D...](https://www.amazon.com/Object-Thinking-Developer-Reference-
David/dp/0735619654)

------
collyw
I remember stumbling across this book in my university library back in 2000,
that really helped me understand the principles when all the other books were
talking far more about syntax and functionality without really explaining the
"why" part.

[https://www.amazon.com/Introduction-Object-Oriented-
Programm...](https://www.amazon.com/Introduction-Object-Oriented-Programming-
Timothy-Budd/dp/0201824191)

------
reacweb
Bertrand Meyer Object Oriented Software Construction is excellent. It details
the concepts of OOP and remains very independent of the programming language.

~~~
john_reel
How would you develop the language specific skills?

~~~
vinceguidry
The hope behind learning paradigms, like OO or functional, is that you can
transfer what you learned in one language to another. So if you're just
looking to level up your OO, your best bet is to pick up the most interesting
OO book you can find and just follow along. I like Practical Object-Oriented
Design in Ruby by Sandi Metz.

It's going to be difficult to find excellent OO resources for every
conceivable language and stack.

------
sebastianconcpt
I've learned a lot from building a system in Smalltalk and these books:

[https://en.wikipedia.org/wiki/Design_Patterns](https://en.wikipedia.org/wiki/Design_Patterns)

[https://www.amazon.com/Smalltalk-Best-Practice-Patterns-
Kent...](https://www.amazon.com/Smalltalk-Best-Practice-Patterns-
Kent/dp/013476904X)

------
ninjakeyboard
This was the book that really drilled into my head how to design in OO. It's
VEEEEERRRRYYY easy to understand and will give the good heuristics to use in
OO design. [https://www.amazon.ca/dp/B00AA36RZY/ref=dp-kindle-
redirect?_...](https://www.amazon.ca/dp/B00AA36RZY/ref=dp-kindle-
redirect?_encoding=UTF8&btkr=1)

~~~
wpietri
Might I suggest you include the title and author in your comment?

I also suggest you drop everything in Amazon links that isn't necessary, which
is most of it. I rarely click on a link without looking to see where it goes,
and Amazon links are particularly suspicious because the affiliate program
gives people a financial motive to get link clicks.

------
kapv89
\- Read SICP

\- Understand how all programs can be written as lists of lists of lists...
and so on

\- Pick up the language that you work in. Identify what construct of that
language allows you to approximate scheme/lisp lists. For me this is objects
in java & php, and functions in javascript

\- Code your program as a list of lists of lists... in the language of your
choice.

\- Congrats, you got OOP

~~~
eru
Doesn't SICP stress closures more than lists? (And this list-heavy approach
only really works in a dynamically typed language.)

~~~
kapv89
I have used it just fine in Java. "dependency injection" looks a lot like
lists-of-lists...

And SICP talks about a lot more than any particular constructs. Its the sort
of book you can come back to, and take what you need to go further.

~~~
eru
I've recently actually done the latter, and gone back to SICP. Alas, it shows
its age badly: it's too untyped for my tastes these days.

Yes, you can emulate dynamic typing in statically typed languages---but why
would you want to if the static type system is expressive enough? (I can see
how in Java dynamic typing might be the smaller hassle.)

------
Myk267
What kind are you after? There's sort of two: 1\. The Philosophical OOP,
brought to us by Alan Kay's mind, which probably has to be experienced through
a language with sufficient OO-ness. It's always the ship on the horizon.

2\. Working OOP, which you can learn in an afternoon from a handful of blog
posts and/or library examples.

------
kazinator
_Object Oriented Analysis and Design_ , by Grady Booch.

That's the fellow who invented UML, and wrote the foreword to the GoF Design
Patterns Book.
[https://en.wikipedia.org/wiki/Grady_Booch](https://en.wikipedia.org/wiki/Grady_Booch)

------
jsmith0295
If you're looking for Java style OOP specifically, this would be a good place
to start:
[https://docs.oracle.com/javase/tutorial/java/](https://docs.oracle.com/javase/tutorial/java/)

------
b3h3moth
The best way is to refresh your 'memory' with a good course[1].

[1] "CS 108 Object Oriented System Design":

[https://web.stanford.edu/class/cs108/](https://web.stanford.edu/class/cs108/)

------
fitzwatermellow
Check out Robert Nystrom's _Game Programming Patterns_ :

[http://gameprogrammingpatterns.com/contents.html](http://gameprogrammingpatterns.com/contents.html)

------
nurettin
Just stay away from Elixir language. The community will do anything to keep
you away from OOP concepts.

------
_RPM
Implement a OOP programming language will really help you understand
Inheritance, Polymorphism, etc

------
maremmano
Would like to know if there are some good language-agnostic resources?

------
eru
May I ask why you want to learn OOP? You don't need it at work right now, and
you'll probably never need it. Not even in interviews.

~~~
wpietri
To be a better programmer?

I don't think I'll ever work in a purely functional language, but I still took
an online course to learn something about functional approaches. It was great;
it has definitely changed how I program for the better.

~~~
jambox888
Yeah, I was going to say, OO is brutally overused and seems to be fading quite
quickly in the new world of highly scalable systems, e.g. Spark, CouchDB and
so on. Objects still have a place in widget sets, datetimes, etc.

Overall though they were often used by default where there were better ways
and just as often abused to allow a ton of shared state (globals in disguise),
which almost always makes code harder to follow.

~~~
wpietri
That's definitely true. I think classic OO works a lot better in a context
where objects are relatively long-lived.

The problem is that the way most modern systems are scaled, they are very
short lived. When the purpose of a code base is to turn HTTP requests into SQL
queries and SQL results into HTML responses, then the objects end up being a
thin layer between function calls.

That's not a necessary outcome; in a parallel universe something like
Prevayler would have given us long-lived object graphs in a lot of the places
where we now use OO languages on top of external databases. But that's sure
not the world we live in.

Another factor that I think made things worse was the massive increase in the
number of programmers during the Internet boom. I love working with code from
master OO developers, especialy those of the test-driven, domain-driven sort.
But OO approaches allow so many degrees of freedom that it's easy for
relatively junior developers to make giant messes. Messes that I don't even
think of really as OO, just snarls that happen to be in OO languages.
Regardless, I think the September That Never Ended kept the average OO code
base in a state much worse than the best ones.

Anyhow, I'm excited to see the state of practice moving forward, inch by inch.

------
mlvljr
Search for the history of the discipline, find the crucial names and study the
papers + listen to talks, then think all by by yourself and decide whether /
to which degree things are applicable to the contexts of your interest.

That would be the best way.

Names would be: Dijkstra, Parnas, Kay, Booch, and many others. Once you
assemble a nice collection of notes, links and questions, you'll be allright
and will never fall for "OO is A, B and C!" oversimplified nonsense many books
attempt to sell.

Do not believe any comment in this thread either, rather take things with a
(huge) grain of salt -- remember, we're dealing with a Holy Grail here, and
everyone interested is quite opinionated :)

