Ask HN: How to Learn OOP

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.

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.

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.

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.

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