[thebigspacefuck]

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]

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.