7
A lot of the "OO" code you see around is procedural. I have already committed and continue to commit several "sins" per day by programming OO.
The paradigm is not easy to learn and it takes time, while several mistakes are made and the maintainability of the code suffers. When you leave college you’re just a chaos creator, who over time can develop the ability to create and restore order in the projects you’re involved in.
But if the cake recipe was available...
Does it exist? If it does, what is it?
What would be a well-directed OO study?
For example, in my apprenticeship I had much to know the replacement of Liskov. Tell don’t Ask was also a mind opener (create getters only where necessary and have the object perform the action instead of asking it for the necessary information and perform outside). I am gradually learning about design patterns, and I am also studying UML (since there is no A&POO book that doesn’t apply it). The whole technique of creating domain models is interesting because it helps me choose the right objects to be placed in the domain instead of inventing random abstractions. Other things are important too, cohesion, coupling.
These are "snares" that I would have liked to avoid if they had been passed to me beforehand. Hence the question.
Or drop all this and go sell coconut on the beach? (rhetorical question :).
EDIT: I changed the question to make it more objective, but without touching the original content too much.
To learn pure and traditional POO? I recommend getting away from 3 of the list: Design Patterns and UML. Design patterns because this is something that is first appropriate to feel the need (so it needs to be mature in the subject). UML because it is something more focused on engineering documentation, not construction itself. And also because I find it particularly useless ;-)
– Jefferson Quesado
@Jeffersonquesado I put UML because it serves to analyze the design individually and to discuss the design in groups. And because it is very difficult to see an APOO book that does not apply UML. But it really is not something you see using strong in the market.
– Piovezan
I understand that the question can be based on opinion. But there are three upvotes already. : ) could not be improved? What I want to know is what to focus on when learning O to avoid making mistakes in learning. Or the only option is to learn by catching up with these mistakes? It is costly, should have a better option.
– Piovezan
I’ve seen some reports from programmers/tutors of programmers talking that even when it comes to a high-level language team (like Java or Ruby or Python), those members of the team who had contact with C at the beginning of the studies got along better by having made many mistakes during the studies and learned to avoid them from being so callous. For example, Michale Feathers quote
– Jefferson Quesado
Still some things can be taught to avoid these calluses, for example Liskov substitution, how to model the domain correctly, prefer inheritance composition, GRASP patterns, cohesion, coupling... but I understand your point. Also, you cite C, which is procedural, being that errors in OO are what I would like to avoid.
– Piovezan
On the "Tell-dont-Ask", by Martin Fowler himself: "For me, [...] I don’t find it [Tell-dont-Ask] a point worth Highlighting"
– Jefferson Quesado
There was no way, it was too opinionated and I ended up helping to close. Next time...
– Piovezan