Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to Learn OOP
67 points by ympavan on Sept 14, 2016 | hide | past | favorite | 75 comments
I want to learn Object-oriented programming. When I was in college I had learnt few concepts, but now I don't remember most of the things. Also, presently my work doesn't demand to learn object-oriented concepts or OOP.

Any suggestions on: how/where to start? which book to refer?




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.


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.


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.


I agree that learning Smalltalk is the best way to learn OOP. But you should be careful with design patterns, design patterns are not a tool that you just use, they arise naturally in an OO model, and you should know them well to recognize them. Besides, several of the design patterns from the GoF are not necessary in a language with closures.

I strongly recommend three books:

Smalltalk, Objects, and Design - by Chamond Liu

Object Thinking, by David West

Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock


No. Design patterns are just idioms, ways of accomplishing something. They aren't enshrined in any way by OO.

As for the idea of a set of common patterns that can be reused in a variety of situations, yes, that's a natural consequence of OO. But that's a natural consequence of any paradigm. OO's just had better marketing and GoF gave them a name.


In addition to what you said, OO to me is all about things sending messages back and forth between black boxes, such that the message contains everything the recipient needs to either do its job or find the information needs to do its job. Alan Kay (since you brought up Smalltalk) has said that he wishes he called it Message Oriented Programming instead, because people took the wrong message out of the name. In this line, Erlang and Smalltalk, and to a slightly lesser extent Objective-C more fit in with this. But you can code that way in Java or whatever, if you just think about the message between entities being an actual first order thing in your system.


Yes. Java's main failings were its strong typing (forcing interfaces to be a needlessly awkward solution), and an emphasis on inheritance, creating deeply nested hierarchies, and leading people to use Hungarian Notation, creating even more awkward naming.

In any case, you can write OO in any language. Heck, if you look into the history, Scheme, A multiparadigm language in the Lisp family typically associated with FP, was actually intended to be something approximating OO (it was designed to implement Carl Hewitt's Actor Model, so as to help Sussman and Steele understand it better. They subsequently realized that their code for creating actors and sending messages was identical to their code for instantiating and calling functions, leading them to generalize and only include lambda in the language, concluding that actors and functions were one and the same. Hewitt did not approve).


An alternative route would be to study programming paradigms from Concepts, Techniques, and Models of Computer Programming [0].

One of the authors is teaching a two-part MOOC on edx over the material [1] (how much of it, I don't know).

[0] https://mitpress.mit.edu/books/concepts-techniques-and-model...

[1] https://www.edx.org/course/paradigms-computer-programming-lo...!


I think qwerty's explanation is a little bit too high level. It feels to me more like a definition that people that already understand OOP can use to talk about it than a useful definition for a beginner to understand it.

OOP at it's core is about answering the question "Where the fuck do we put our code?"[0].

Imagine it's the long ago and year is of 1 B.O.(before OOP). Your language has primitive types and functions. You maintain a large line of business application. Someone has just invented the apartment building so you are given the task that to make sure your application handles apartment units correctly. You go through and find all of your functions that take parameters like "int streetNumber, string street, int zipcode,string city", and you add apartment number to them getting "int streetNumber, string street, string apartment, int zipcode,string city". Having these 5 parameters that you pass into all the same functions is super painful. It's also error prone to edit.

So you decide there has to be be a better way and decide to create structs. You decide to group these 5 parameters together into struct(which you just invented) called mailingAddress. This is really great because you have organized these 5 parameters into one object, so mailing address is now 1 parameter instead of 5. And if you need to add or change one of these parameters there is only one place to change it. You won't accidentally forget to add apartment to some function because as soon as you add a mailing address parameter it comes with an apartment baked in. But unfortunately you still have to hunt down every function that is scattered around your goliath project to find what functions modify this mailing address. You have an itch that this could be done better. You lock yourself in your closet and go into a deep meditation for 3 days.

You come out decide there is a better way and you create classes. You decide that you'll group all of these functions that modify and interact with mailing address and put them in the same file with your struct and call it a class. This is great because in the future when you want change how the mailing address(which is something that your stake holders cares about which we refer to as the domain) works you know exactly which file to go to.

It really is that simple. 80% of OOP is just making sure you group the right code together in a way that you can find and change the code when a stakeholder asks you to. There is much more advanced OOP foo, and for that I would ironically suggest https://fsharpforfunandprofit.com/series/designing-with-type... which will blow your mind when you're ready.

[0] - yes of course it can be get more complex in terms of typing/ encapsulation/inheritance/polymorphism. [1] - I know this is simplistic because functions are data.


Strong types are by no means necessary to OO.

As for your explantation, that's technically true, but that's a very dangerous way to think about OO. OO is about treating objects as collaborating, independant entities, and if you view objects or classes as just, "a place to put your code," you'll run into trouble when you have to start thinking about objects as, well, objects.


Out of curiosity, why Java is not best language for reading OO? Any reason?


Because Java uses strong typing and largely early binding, which are almost always The Wrong Thing in OO.

Actually, by the Alan Kay definition, Java isn't even really OO at all. It just kind of looks like OO. You can apply OO techniques to it, but it's better to learn real OO than the bastardized version that's taught to Java programmers.


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.


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

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.


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!


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.


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


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/ Her talks are highly recommended too.


Sandi Metz is great.

This talk is such an amazing example of clear thinking:

https://www.youtube.com/watch?v=8bZh5LMaSmE


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.


Seconded. As a self taught generalist ruby/python/java guy, I read POODR two years ago and it stands out as a great investment of time. Lots of "a-ha, that's what I should be doing" moments. Has anyone checked out her new 99 Bottles book?


I was about to chime in with the same message. An important part of this book is that the language used--not just the code language, but the writing language as well--is very easy to follow and understand. This is not a book you'll regret reading.


+1

This is the book I wish I had 25 years ago.


Look for Uncle Bob's talks on SOLID design.

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod


You can always check out Object Oriented Analysis and Design by Head First (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).


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.


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.


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.


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.


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.


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.


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.


I don't like OOP very much myself, but it doesn't have to result in "more code" (depends on a language support for concepts), doesn't have to lead to "over-complicating problems" (depends on language support and design skills) and it doesn't necessarily make your application hard to understand and debug (depends on the language, tooling and domain).

As with every tool you need to know how and when to use it, but it can be quite effective if done right.


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


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.


More code, more complexity? See this: https://www.youtube.com/watch?v=8bZh5LMaSmE


The speaker just introduces more OOP complexity into already complex OOP code. All that’s going to do is make the code even harder to modify or step through.


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.


https://learnpythonthehardway.org/


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.


Link for the lazy: https://www.amazon.com/Object-Thinking-Developer-Reference-D...


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


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


How would you develop the language specific skills?


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.


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

https://en.wikipedia.org/wiki/Design_Patterns

https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent...


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


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.


Seconded. This book does a very good job at telling you why and when you'd want to use a specific design pattern, and why it would be better than the alternative.


- 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


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


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.


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


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.


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


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


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/


Check out Robert Nystrom's Game Programming Patterns:

http://gameprogrammingpatterns.com/contents.html


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


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


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


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.


It's still very relevant in the job market. Probably upwards of 50% of jobs are going to want you to know OOP, and many of those will cover it explicitly in technical interviews.


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.


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.


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.


What? http://githut.info/ 5 out of the 6 top languages on Github are OOP(not counting CSS). And PHP still supports OOP. Pretty much if you want to create an app for web/mobile/desktop with one of the most common languages you are going to end up using OOP. How can you "never need it"?


By and large, the party line on HN is that everybody does (or should be doing) functional programming and / or lisp.


Which really does not reflect reality at all. Outside of research/education, and stuff hobbyists are doing, FP typically isn't typically used alone. Some ideas are just borrowed from it and sprinkled onto OO languages to make things a bit nicer. FP has a lot of good ideas, but that doesn't make it reasonable to assume that it's all you need to know, or even the most important thing for you to know.


I didn't say it was an accurate reflection of reality.


I didn't think you did, was just commenting on what you'd mentioned.


Yeah, I don't know where all these people have worked where they think that OOP is dead. OOP is very well suited to many problems that businesses face and until something comes along to change that then OOP will be used heavily.


I don't need to be able to drive at work right now. I'll probably never need to do it in an interview. Does that mean that I shouldn't try to get better at it?


Funny, pretty much every interview I've been through (20+) kicked off with simple OOP principle questions.


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 :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: