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.
Funny, pretty much every interview I've been through (20+) kicked off with simple OOP principle questions.
Ask HN: How to Learn OOP
51–60 of 78 posts
Re: Ask HN: How to Learn OOP
#52As 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. Th…
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.
Re: Ask HN: How to Learn OOP
#53What 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.
Re: Ask HN: How to Learn OOP
#54I'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...
Re: Ask HN: How to Learn OOP
#55[deleted]
Re: Ask HN: How to Learn OOP
#56Here'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…
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
Re: Ask HN: How to Learn OOP
#57Earlier quoted context omitted.
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.
Re: Ask HN: How to Learn OOP
#58May 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.
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.
Re: Ask HN: How to Learn OOP
#59- 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
Re: Ask HN: How to Learn OOP
#60May 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.
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.