Just stay away from Elixir language. The community will do anything to keep you away from OOP concepts.
Ask HN: How to Learn OOP
61–70 of 78 posts
Re: Ask HN: How to Learn OOP
#62Here'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 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.
Re: Ask HN: How to Learn OOP
#63Come 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.
Re: Ask HN: How to Learn OOP
#64I'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...
Re: Ask HN: How to Learn OOP
#65What 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.
Re: Ask HN: How to Learn OOP
#66Here'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 Cham…
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.
Re: Ask HN: How to Learn OOP
#67Here'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 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…
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.
Re: Ask HN: How to Learn OOP
#68Earlier quoted context omitted.
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.
Re: Ask HN: How to Learn OOP
#69Here'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…
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...!
Re: Ask HN: How to Learn OOP
#70Practical Object-Oriented Design in Ruby (POODR) by Sandi Metz opened doors for me - http://www.poodr.com/
+1
This is the book I wish I had 25 years ago.