18
Actually the question I’m trying to ask is exactly that: How to identify classes in an object-oriented system?. However, I would like to ask for two additions to the accepted answer.
She seems to describe the so-called OOA&D (Object-Oriented Analysis and Design) or Object-Oriented Analysis and Design. I do not know if this is a suitable request for the format of the OS, but I would like to ask for a canonical reference on the subject, and accepting complementary material to the canonical one (if possible indicating why I should prefer one material over another). If it makes a difference, I have more experience with Java. I am currently in doubt among the following references:
- Applying UML and Patterns (Craig Larman) - textbook adopted by my university after I graduated; it doesn’t seem to go into much detail with regard to finding the correct abstractions, but in its text the author recommends the Responsibility-Driven Design that is described in the book below;
- Object Design: Roles, Responsibilities, and Collaborations (Rebecca Wirfs-Brock, Alan Mckean) - the author is a reference in OO; the book introduces the RDD, which seems to be accurate on how to choose the correct abstractions when modeling classes;
- Object-Oriented Software Construction (Bertrand Meyer) - the author is a reference in OO, but the latest edition is not very recent;
- Object-Oriented Analysis and Design with Applications (Grady Booch et al.) - interesting because it compares classical and modern approaches to Object-Oriented Analysis and dedicates chapter 4 to "finding the right abstractions";
- Head First Object-Oriented Analysis & Design (Brett D. Mclaughlin et al) - no special recommendation, just like the style of the Head First series.
A more specific question regarding class modeling. I confess that although I thought that I "programmed OO" many years ago, because I studied my OOP discipline, I learned my quota of Patterns design, read about SOLID, knowing cohesion/coupling, favoring heritage composition and everything else, actually had a lot of freedom with my classes and did not really understand the original philosophy behind object orientation. If I did, I’d have known for a long time why they made sense "Rules of Thumb" as Tell Don’t Ask (that in its mildest form warns against leakage of business logic out of the object by means of getters unnecessary) or the er-er Principle, or the posting Dance You Imps of Robert Martin. Objects go beyond joining state and behavior outside of our intuition and individual experience; they would be more like "mini-machines" that provide an API of commands for your customers (your public methods, which as a rule should be more than one; otherwise it is probably a Procedure disguised as an object), they reveal a minimum of state (that is encapsulation; it has nothing to do with simply creating getters for private variables) and self-manage. You do not calf classes by default; you stifle the classes that are most appropriate, often having to discard the initially most obvious choices. To me these concepts are not at all intuitive and I believe there is material about how to correctly design classes whether in the books above or somewhere else, so the question-title: "How to find the right abstractions?" that must take into account this correct philosophy of object orientation. I would actually like to break this question into two parts: a long-term one, in which the answers indicate reading on the subject; and a short-term one, since I am starting the coding of a new project, with business rules, architecture, bank modeling and individual services already specified and since I found this deficiency I am feeling insecure about how to design classes within these services. Since the correct philosophy is not intuitive for so many programmers (this is what the experts say of the subject, and what attests to the wide ignorance of this canonical material that @Maniero spoke, and also sees the erroneous analogy that objects should reflect precisely the real world [1] [2]), and since to create the your class diagram by intuition instead of finding the most appropriate one is also incorrect, finding the right abstractions seems a bit more difficult than before.
It’s easy to fit that kind of question. Ask for a canonical reference on the subject rather than asking for "a lot of material", and say you accept complementary materials to the canonical. Knowing how to do it, not giving room for a meaningless answer, anything can be asked. You’re finding out, I don’t know if for good or bad that OOP is sold as something magical and universal and that’s not quite so. I don’t know if you’re going down a better or a worse path. If now will further complicate your codes to fix OOP errors, or will start making parsimonious use of the paradigm.
– Maniero
Making OOP correct is so complicated and so difficult to teach that it should already turn on a red light if it should be used ostensibly as many do. Of course, if the problem can adapt well intuitively to the paradigm, it is a good indicator that it is suitable. I don’t understand why people keep throwing punches. If it’s hard to understand, it’s because it’s hard to apply. The monoparadigm culture is not making software better. The "real world" was much used to sell the paradigm, to show how easy it would get into people’s heads
– Maniero
Okay, so I’m going to ask for a canonical reference and accept complementary canonical materials. If it makes a difference, my biggest experience is with Java.
– Piovezan
About book references "Design Patterns: Elements of Reusable Object-Oriented Software" (classic) and "Head First Design Patterns" (basically the previous simplified) are among the best about OO I have ever read. Now as @bigown spoke OOP is overrated, if you want to make real decent code you have to expose yourself to various paradigms and improve as much as possible your logic and knowledge of algorithms.
– BrunoRB
@Brunorb I complemented in the question that I already know design Patterns, I actually have these two books. But what I’m asking about is more general guidelines than Patterns design. About the paradigms you’re right, but particularly I prefer to master OO before leaving for the functional, for example.
– Piovezan
As it would be something incomplete for you, I decided to put as a comment and not an answer. I suggest a very interesting literature that presents very well the challenges and ways of thinking when we walk the path of programming, applying OO or not: The Pragmatic Programmer by Andrew Hunt and David Thomas. It’s a much higher-level book on programming philosophies. I even recommend that you look for bibliographies less "technical", since your problem seems to me much more conceptual.
– Thiesen
@Thiesen didn’t understand what you meant by conceptual. My problem is exactly technical.
– Piovezan
@bigown You say that because of the monoparadigm culture there are problems that shouldn’t be solved with the OO paradigm. That’s a point. Also, in your opinion for the general case which paradigm should dominate? Or what multiparadigma solution? Or maybe there is no general case?
– Piovezan
None. The domain would be bad. I always liked the procedural/modular, but I use a lot of OOP. Remembering that line by line, the bulk of what we do is imperative. I have increasingly enjoyed the functional. There are other interesting ones that are hard to swallow. But I found functional difficult too and I find less and less. It has a lot of more limited paradigm that are interesting. Most can be used to complement others, type: generic, meta, contracts, events, aspects, competitive, etc.
– Maniero
The functional s/radicalisms, accepting a bit of imperative, c/alternatives and p/oop escapes think it may be the best modern option in general terms. But I’m still improving my training in this area. I’m not in a position to take a definitive position. All I know is OOP has too many problems to be used as default. Functional is boring at first, but as you go along, you see that it’s not so much, it happened with OOP. In fact OOP is so complicated that almost no one knows how to use it right. Procedural right is not so obvious, it needs plenty of experience.
– Maniero
In other words, programming is difficult and nothing works magic. The paradigm does not help the programmer avoid nonsense, only express certain patterns better. Typing, memory management, a good compiler and other tools help the programmer more than just another paradigm. I think that there is still a lack of good languages in most paradigms, the functional would be better if there were more less radical languages. Of course the functional does not solve everything well either. But I have seen languages mixing things well. Some if they had better taste and corporate support from big techies, would go forward.
– Maniero
At this point it would be good if languages had the characteristic of promoting the correct application of the paradigm.
– Piovezan
Yeah, that’s not possible. Paradigms try to help but there are limitations. You’ve received a response that fa what OOP does best, if it sells well. It gives a generic definition of what OOP is. So it fits into anything. Then you code just by looking at this definition, and it doesn’t help at all. But on the other hand if this is OOP, any language is OOP because it can represent the real world in any paradigm.You have received the answer I expect, one that does not help at all to improve understanding about it. And for a change you mix things up and put relationships that don’t exist
– Maniero