18 ms·

Ask HN: How to Learn OOP

• osullivj 10y ago
  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!
• caruso_g 10y ago
  https://learnpythonthehardway.org/ https://learnpythonthehardway.org/
• thorsteneckel 10y ago
  Practical Object-Oriented Design in Ruby (POODR) by Sandi Metz opened doors for me - http://www.poodr.com/ http://www.poodr.com/
  • rimantas 10y ago
    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 10y ago
      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 10y ago
        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.
  • thebenedict 10y ago
    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?
  • ysavir 10y ago
    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.
  • terrywilcox 10y ago
    +1 This is the book I wish I had 25 years ago.
• eru 10y ago
  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.
  • rkangel 10y ago
    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?
  • jsmith0295 10y ago
    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.
  • duiker101 10y ago
    What? http://githut.info/ 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"?
    • GFK_of_xmaspast 10y ago
      By and large, the party line on HN is that everybody does (or should be doing) functional programming and / or lisp.
      • jsmith0295 10y ago
        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.
• icecold12741 10y ago
  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 10y ago
    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.
• maremmano 10y ago
  Would like to know if there are some good language-agnostic resources?
• klibertp 10y ago
  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.
• dreta 10y ago
  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.
  • klibertp 10y ago
    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.
  • rimantas 10y ago
    More code, more complexity? See this: https://www.youtube.com/watch?v=8bZh5LMaSmE https://www.youtube.com/watch?v=8bZh5LMaSmE
    • dreta 10y ago
      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.
  • rkangel 10y ago
    (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 10y ago
• jsmith0295 10y ago
  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/
• reacweb 10y ago
  Bertrand Meyer Object Oriented Software Construction is excellent. It details the concepts of OOP and remains very independent of the programming language.
  • john_reel 10y ago
    How would you develop the language specific skills?
    • vinceguidry 10y ago
      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.
• deleted 10y ago
  [deleted]
• qwertyuiop924 10y ago
  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.
  • _asummers 10y ago
    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.
    • qwertyuiop924 10y ago
      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).
• allendoerfer 10y ago
  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 10y ago
    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 10y ago
      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.
• mlvljr 10y ago
  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 :)
• AlexCoventry 10y ago
  Look for Uncle Bob's talks on SOLID design. http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• fitzwatermellow 10y ago
  Check out Robert Nystrom's Game Programming Patterns: http://gameprogrammingpatterns.com/contents.html http://gameprogrammingpatterns.com/contents.html
• collyw 10y ago
  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-Programming-Timothy-Budd/dp/0201824191 https://www.amazon.com/Introduction-Object-Oriented-Programm...
• dmux 10y ago
  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 10y ago
    Link for the lazy: https://www.amazon.com/Object-Thinking-Developer-Reference-David/dp/0735619654 https://www.amazon.com/Object-Thinking-Developer-Reference-D...
• thebigspacefuck 10y ago
  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 10y ago
    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-Complexity-Software/dp/0321125215 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.
• ninjakeyboard 10y ago
  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?_encoding=UTF8&btkr=1 https://www.amazon.ca/dp/B00AA36RZY/ref=dp-kindle-redirect?_...
  • uw_rob 10y ago
    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.
  • wpietri 10y ago
    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.
• b3h3moth 10y ago
  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/
• jorgeleo 10y ago
  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.
• kazinator 10y ago
  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
• whamlastxmas 10y ago
  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.
• sebastianconcpt 10y ago
  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/dp/013476904X https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent...
• deleted 10y ago
  [deleted]
• kapv89 10y ago
  - 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 10y ago
    Doesn't SICP stress closures more than lists? (And this list-heavy approach only really works in a dynamically typed language.)
    • kapv89 10y ago
      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 10y ago
        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 10y ago
  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.
• nurettin 10y ago
  Just stay away from Elixir language. The community will do anything to keep you away from OOP concepts.
• ilaksh 10y ago
  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.
• _RPM 10y ago
  Implement a OOP programming language will really help you understand Inheritance, Polymorphism, etc