Object orientation - How to find the right abstractions?

Asked

Viewed 607 times

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.

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

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

oop modeling language-independent paradigms
  • 2

    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.

  • 5

    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

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

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

  • 1

    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 didn’t understand what you meant by conceptual. My problem is exactly technical.

  • @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?

  • 2

    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.

  • 1

    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.

  • 2

    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.

  • At this point it would be good if languages had the characteristic of promoting the correct application of the paradigm.

  • 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

Show 8 more comments

4 answers

6

I’ll risk a simplistic answer to the main question:

How to find the right abstractions?

Top-down approach

In a personal reflection, I came to the conclusion that one of the ways to solve problems that is most efficient for me is an approach top-down, from the most abstract and generic concept to the most concrete and specific.

For example, let’s assume that the client wants a program to control a robot that prepares juices. Back to the most basic principle of computing (input, processing and output), I have:

  • Starters: fruit, water and sugar (ingredients)
  • Processing: robot uses the liquitier, there may be different types of "recipes"
  • Exit: drinking

So, at a high level, I can determine the main interface of the system:

class Robo {
    Suco preparar(Ingredientes, Procedimento)
]

Basically, you ask the Robot to make the juice, provide the ingredients and say what the procedure, receiving as a result the vitamin.

Sure, it’s something very simple, but here’s the advantage. A good modeling, in the definition I’m using, includes two main elements:

  1. The fact that many details are not represented is great freedom to the way everything will be implemented. Processes can be broken into subprocesses, more abstract objects can be composed with other simpler objects, interfaces or main classes can have specialized versions, interactions between elements are not fully defined and so on.
  2. At the same time we have a well-defined "public interface" for "customers" of this class to make their vitamins.

In short:

"Correct" abstraction would be the one that allows you to implement and specialize existing functionalities with freedom without changing the higher levels.

Considerations

Object orientation vs. other paradigms

In several questions that have arisen these days, has been raised the question of advantages of the POO against some other paradigm.

In no way should we see this as a competition. The different paradigms can and should be used together.

The POO, with its classes and attributes does not replace the "procedural" or imperative programming nor prevent the use of functional programming, but adds encapsulation and abstraction capabilities that would be more difficult to express in the other paradigms.

Nothing prevents, for example, a "procedural" code from building a collection of objects and performing a map-reduce to obtain a consolidation of the collection data.

Data structures vs abstraction

Note that in my "modeling", I did not even enter the question of the data structures used, that is, which attributes represent an ingredient, etc.

The POO’s trump card is not in organizing data sets, nor (in my opinion) in representing real-life entities, but in abstraction or in what it is possible to specify undefined the details.

Real-life attributes can be represented in "lifeless" data structures and processed by independent functions or routines.

On the other hand the elegance of good class modeling is, in my opinion, not in the modeling itself, but in how easy and intuitive it is for other people who will access, implement and extend. Of this, no purely procedural language has come close to today.

Making concrete knowledge

I will not recommend a specific literature of the subject. In fact, I do not know and I do not think there is anything that is definitive. Any text or book will address at most some aspects of what it is to model the problem on objects.

The only way I know how to make a "correct" modeling is:

  1. Read everything you can on the subject
  2. Try to apply this to a problem the best way you can
  3. Make proof of use in practice and collect feedback
  4. Identify problems and research solutions for them
  5. Redo the template trying to solve the items found in item #4 to have a "more correct modeling"
  6. Repeat everything dozens of times

A creative process

Contrary to what is described in the question, I would not say that someone finds the correct abstraction, as if this is something that exists independent of the programmer.

Programming is a creative process. An artist does not find the right way to paint or model something, he does it arbitrarily within the limits that he imposes himself and, of course, within his own ability.

  • Excellent point: "intuitive modeling - of this, no purely procedural language has come close to today". I can try to represent domain objects in procedural programming, use pointers to simulate polymorphism, etc., but in the end I won’t be using the paradigm but just writing too much code to try to simulate it. And if language doesn’t support OOP I’m trying to force a paradigm into a universe where it’s not welcome.

5

Although many people simply interpret the verse "Object Orientation helps represent the real world", the fact is that it is exactly this idea that will help you find the right abstractions.

Demystifying the "representation of the real world"

  • The map with the names of streets and neighborhoods pasted on the wall at home represents my real city?

  • The plaster cast my dentist made represents my real mouth?

  • The plan that the architect made of the building where I work represents the real place where I work?

The answer to all these questions is yes and no:

  • The map helps me find an address but doesn’t tell me which streets have good sidewalks so I can walk quietly.

  • The dentist mold helps you solve problems of my teething but could not help another doctor diagnose a problem in the mucosa.

  • The architectural plan of the building where I work helps in a refurbishment or in the redeployment of furniture but does not say anything about the refrigeration in the office, the relationship between people, the projects we work on, etc.

That is to say:

A model actually represents a real-world object, according to the perspective or abstraction that matters to the solution of a specific problem.

No type of model in this universe is capable of representing an object with all its features and functions. No model is capable of representing even the most important features and functions of an object!

Each model needs to represent only the characteristics and functions of an object that are interested in solving a specific problem. That’s what OOP is for and it’s with this idea in mind that you’ll be able to find the right abstractions.

To this ridiculously small minimum set of characteristics and functions of the real objects that interest us when designing a solution, we can call problem area; or, for short, we can only call domain.

Already the design of the solution, the translation from the domain to objects, we can call model, and the activity of designing the model we can call modeling.

I believe what I’ve written so far you already knew, but it’s good to line up. So you also know what the next topic, instead of calling How to transform the real world into a model of objects, he calls himself:

How to model the domain?

Object Orientation is not the most difficult.

Representing the real world (within the concept already explained here) using object orientation is also not.

What is more difficult is to convince the programmer to forget the technology for a moment and focus on the real world problem that needs to be solved.

When the topic is "object orientation", you hear a lot of people talking about "heritage", "polymorphism", "interface", "Generics", "ORM"...

Programmers don’t spend an extra minute to get a deeper understanding of a business requirement, but don’t mind spending hours trying to map via ORM an entity heritage (unnecessary) to the database.

It turns out that it’s the business requirements, the domain of the problem, that will deliver the information you need to find the right abstractions.

A careful conversation about the domain, with people who understand the domain, will reveal the names of the objects, the delimitations of these objects, their attributes and functions; and will also reveal the interactions between these objects and how they should be coordinated to solve the problem.

Many programmers impose on themselves the limiting belief that the client does not know what he wants. Working with this premise leads to poorly designed, overly complex, wasteful software that does not solve the problem well.

Involve the customer (see "product Owner" and "Domain experts") is what will help you understand the domain and therefore identify the correct abstractions.

Knowledge and experience

It is clear that technical knowledge of object orientation is indispensable, because the Domain expert won’t teach you to program.

Knowledge of Patterns design (formal or only by experience), is also fundamental for you to make good decisions about how to coordinate the work of objects.

But this kind of technical knowledge is not what will determine a good or bad modeling; it is just prerequisite. The determining factor is the knowledge of the domain and, logically, the application of this knowledge in the modeling.

As a study material, if you already have experience with OOP and Patterns design and everything else, I recommend the Domain-Driven Design, of Eric Evans.

I point out this book when the programmer has already reached the maturity of realizing that his technical knowledge is not being sufficient to successfully design and implement a great software.

It is always good to remember that all the philosophy contained in this book only makes sense in complex domains (which is not the case for example of small mobile applications, more registered or query websites, or even large and distributed systems with millions of users but with low business complexity).

  • The client may know what he wants, but he does not know how to deliver the chewed requirements; one domain term can mean one thing for one department and another, and worse, everything is described in natural language. Candidate nouns may be disguised as verbs and it is the developer’s task to translate this heap of information into specific requirements using a non-ambiguous language. I think we agree on that, right? But that I at least give as a prerequisite if one is willing to produce software. Wrong is not understanding the right domain. Also...

  • ...Rebecca argues that not everything needs to have a real-world counterpart. "Stop trying to model the real world. It’s a Myth that Objects should accurately reflect real-world Things". What does the DDD say about abstractions? She argues that "there are several reasonable abstractions, and some very good". I understand she says that after the problem has been defined, in unambiguous terms and requirements. And finally, watch out for what objects are not; I wrote a whole text about it, which I will try to describe better after reading a little more.

  • @Piovezan Yes, the same term has different meanings in different contexts of the same domain, but modeling needs to respect this instead of trying to avoid (see "bounded contexts"). And no, we don’t agree that it’s up to the developer to resolve the ambiguity: it’s up to dev. understand the ambiguity and along with the domain expert establish the language (names and verbs) that will be used by everyone, including in the code. The customer does not deliver the chewed requirements but he is the key, we have to listen to him to chew the requirements and not try to fill the holes alone.

  • That’s what I call solving ambiguity: understanding ambiguity, understanding differences, and establishing unambiguous terms.

  • @Piovezan You say that "it is wrong not to understand the domain" but to consider that it is up to dev. resolve ambiguities and see the natural language of the domain a problem, if this does not constitute a misunderstanding of the domain then it is even worse: it is disrespectful of the domain. As for Rebecca, she is only agreeing with me: as I said in the answer, no model on the face of the earth (neither of OOP nor any other) is made to accurately represent the real world; but only the mastery of the problem.

  • I get it. dev should not establish unambiguous terms alone. But I’m not saying that the natural language of the domain is a problem, but that implementing the system depends on the non-ambiguous terms. As it also depends on the ambiguous.

  • Would that be so? "Programmers don’t take an extra minute to understand a requirement and establish together with the domain specialist the unambiguous language needed to model the problem (...)". Otherwise it looks like he’s not even trying to establish it himself.

  • @Piovezan could be. The main point is that the answer to finding the right abstractions lies in the knowledge of the domain of the problem, in the respect and application of the domain language when coding; and not simply in the experience with technology. Of course having access to domain knowledge you will still need some techniques, hence Patterns design and OOP and DDD concepts will help.

  • 1

    Interesting, but you wouldn’t say that the very concept of Design Patterns, to put it succinctly, "Reusable solutions to problems that occur frequently in software projects," is nothing more than the documented embodiment of experience in system modeling, and, consequently, in technology? Not to mention the fact that knowing Design Patterns is one thing, because reading the book is easy, knowing how to apply them in order to solve the problem of your domain also refers to experience and experience.

  • I do not judge the techniques presented here, and I confess that I thought it was nice to read about something I had never thought of so technically. But I still think that the role of the experience has much more importance than what has been put. I would not underestimate this at all.

  • @Thiesen How do you know Patterns design help in specific situations, not in the whole system. And as for the principles behind them, they are valid but using them does not teach you the core than is an object. Read my question, I have evidence that an object is something more specific than OO classes led us to believe. "Rule commands are more than one case otherwise they are probably disguised procedures" I took from the Bertrand Meyer. And objects must be findings, nay made-up. Wirfs-Brock say that.

  • Of course experience is important. Dissecting the client’s requirements in his language, finding the language unambiguous, all of this involves experience. Even the way the technique of find the objects must be affected by the experience. But without paying attention to these concepts core that I quoted it is being misapplied.

  • I understand that this reply from @Caffé is valid but takes us only to a certain extent. There are things that for the customer are a black box and these concepts do not apply. I have a microservice that for the client is indifferent as it will be implemented. This microservice receives commands via socket. These commands need to be parsed to then be understood and processed. But I must create a verbal class Parser with a method parse() to do this? Bertrand Meyer says no. Is this intuitive for you? Because for me it’s not.

  • 1

    @Piovezan Do not forget that your question asks for a reference and my answer indicated a book of 560 pages, which obviously I will not rewrite here. My answer goes as far as it proposes: to indicate a path. I have the answer to your problem of modeling the service that answers by socket (I think the book will help you find this answer too), but who knows you ask another question about it, and who knows I’ll answer...

  • 1

    If I ask the question I’ll be happy if you can answer. DDD does seem to have a design approach that is MDD (Model-Driven Design). I think to compare with some others in the order in which they were emerging, ie, the MDD should be last. It is interesting that Rebecca makes a comparison of the different "xDD" approaches and among other conclusions believes that the most appropriate choice depends on the scenario and that some can be combined.

  • Correction: DDD and MDD are separate things. I just don’t understand why the DDD book has a section called The Building Blocks of Model-driven Design. They have some degree of kinship in which one is derived from the other in some way?

  • @Piovezan For it is, the universe of software development does not follow a ubiquitous language hehehe. Indeed Model-driven Design is at the core of the DDD, but the MDD acronym may have been used around with variations as well. There are several MD-blahs out there. There is one for example that suggests that the whole system is drawn in diagrams and then the software or a part of it is generated from these diagrams and this for example is not part of the DDD.

Show 12 more comments

3


Object-oriented design: historical context and current situation

In the early 90’s there was an explosion of methodologies for developing applications oriented to competing objects, many with own CASE tools, called "method Wars". Among the books cited in the question, the Object-Oriented Analysis and Design with Applications describes the Booch method, and the Object Design is the updated version of the RDD method, initially proposed in the book Designing Object-Oriented Software. Highlights include James Rumbaugh’s OMT and Ivar Jacobson’s OOSE. 1 2

Booch, Rumbaugh and Jacobson ("the three friends") joined with the intention of developing a unified method, but what stood out was the creation of a unified notation for their and other individual methods, the UML (Unified Modeling Language). 3

The question therefore remains as to which of the methods to use, in parallel with the growing adoption of agile software development methods/frameworks that do not establish a specific design approach. The 90’s methods are considered more "Planned design", as opposed to the so-called "Evolutionary/Continuous/Emerging design" that more can be done ad hoc during development. Martin Fowler suggests combining the two approaches. 4

If there’s something wrong please correct me.

Specific points

I will finish answering the question with what I learned so far after a few checks and correcting some wrong impressions I had when I did it.

  • For a problem there are many reasonable solutions and some great. Also, different design approaches (RDD, DDD, etc.) may even be combined in a beneficial way. So @utluiz is right, there is no correct design and no canonical material, we have to read as much as we can on the subject. Often though, Rebecca says, you first make the code work and then worry about making the objects simpler.

  • Yes, objects are like mini-machines, but there is no impediment to them providing a single command. The principle er-er does not actually generalize the idea that objects ended in -er are bad, this is a wrong interpretation of it. Bertrand Meyer warns of objects with a single command but only in the event that they don’t even have a parameterized constructor (this is probably a procedure disguised as an object).

  • The spirit of the principle Tell Don’t Ask (keep the data and the behaviors that manipulate them in the same place) is good and valid for the general case according to Fowler and Rebecca, but there are some situations where it is interesting to separate them (for example, in the pattern Specification ddd).

  • Personally I have the almost automatic habit of applying DRY as soon as the first sign of duplication appears in the code, creating functions or new hierarchies of classes. That’s part of my problem when I say I create classes by default, and it’s called premature generalization. Every design decision should be taken carefully because it reweights the code and generates a ripple effect on other design decisions. There are times when it is better to let the duplicity happen for a while until you have a good view of the code so that the decision to generalize is more correct.

2

Well, although I don’t think any answer is appropriate to your question, I will risk helping Oce on the path that you want to tread.

The direct answer to your question "How to identify classes in an object-oriented system?" , it would be "what makes sense with regard to the separation of responsibilities of its application, focusing on reuse seeking not to duplicate unnecessary code".

In a broader context, the identification of classes in an application, although some techniques passed by some authors may help you in various ways, in the end it is really your experience and systemic vision that will hit the hammer.

I would say that identifying these classes and the relationship between them (inheritance, polymorphism, attributes) is a combination of common sense, knowledge and mainly, experience.

I always say that programming and designing systems is not like "building a wall", it’s much more like "painting a picture". Someone might even teach you how to apply colors, but only you, using your common sense, knowledge and experience can decide which color to use at which point, and would say more, only after applying the colors a few times you will getting the way which are best to use in the most appropriate times.

As for your doubt about references, I’d say read them all. The first will give you a cool view of UML, which is an interesting step to better understand object orientation and also an interesting way to learn how to identify classes, since the use case identification exercise is an important step in this path. The other references are very technical, and I give prominence even to Heads First, despite finding a technical and massante literature (reading, exercise, little questions... thing for those who seek certification).

I still recommend the book to you "The Pragmatic Programmer" for some reasons:

1- It is not a book focused on language and knowledge of OO has no direct connection with the language that Oce uses. 2- It is a book that explains everyday situations of a programmer, presents playful scenarios and concepts of "Broken Window", "Bend or Break" and "Stone Soup" 3- I see as obligatory literature for any programmer who wants to design architectures and accumulate good practices as I think is your case.

As for the final part of your question, I believe I have answered a good part of it in the initial introduction and throughout this extensive reply.

Finish here leaving two precious tips for you:

  1. Security about technical decisions made correctly, whether OO or not, come with technology experience and thousands of wrong decisions made. Of others as well as yours. Don’t be afraid to make a mistake, but don’t make a mistake by not consulting the people around you.
  2. The books help you apply the colors and are essential in this walk, because they help you build a conceptual baggage that everyday life can’t. I know a lot of programmers who do things on automatic and don’t know why they’re doing it. These days even one of the guys here applied me a Singleton pattern and didn’t know it was a Pattern design, he just knew it solved his problem. On the other hand, only day to day will give you the feeling of how to apply each of these concepts.

Hugs and Good Luck

  • I know the basics of UML, enough to know that it’s not the key component to finding the right classes, it’s just a tool. Most of the question books will teach you how to use UML and when to use it, the difference is whether or not to teach you how to find these abstractions, this is the cat jump. Say it depends on a combination of common sense, knowledge and mainly experience is what the default OO programmer does; and that’s the mistake.

  • 2

    If OO done correctly was intuitive, every reasonably experienced programmer would have an innate talent for finding the optimal class diagrams for each situation. And that doesn’t happen; we think it does. We find a reasonable abstraction, which in most cases meets and may not give major problems; but each class sprang up by intuition and not by a more detailed search of the correct abstraction. When it is said that most OO programmers do not do OO correctly, it is not talking about lack of experience or common sense.

  • Do you want a formula to find class abstractions? I’m sorry to disappoint you, but it doesn’t exist. What you need is to read a lot, work hard and then find your "cat jump". When you have a book on the shelf called "Formula to Find Class Abstractions," let me know

  • On the contrary, there is. "Entire books were written about selecting the abstraction of objects". It’s not me talking, it’s the Allen Wirfs-Brock.

  • I suggest you go read one of them and find the answer you are looking for yourself. In fact, when you find it, put it here as an answer so that everyone can take advantage of the knowledge.

  • 1

    Don’t get me wrong. I don’t say "I can’t program OO" after all these years without a bruise on my pride. And I know your answer is well-meaning. What I’m trying to emphasize is that in a diagram ideal or near-ideal There is a science behind class choice that has been "forgotten" by industry and which people are not normally aware of. I’m not saying it’s a panacea or that there’s a unique ideal design, but there are some of them for a scenario and it goes beyond the intuition and experience.

  • Even designers of standard Libraries of programming languages make mistakes in this respect. That’s what @bigown means by making correct OOP is complicated and hard to teach.

  • Ideal design is what solves your problem, facilitating refactor when necessary, assigning resposabilities cohesively and coherently, meeting your requirements, avoiding duplication of code, promoting componentization, separation between layers and clarity of code. If there is a specific abstraction that would be better than others, it may well be, but it is so dependent on the specific problem that you are solving, that to derive a routine from this process seems to me quite utopian and open to interpretation. What you would think ideal I might not find, and vice versa.

  • Rebecca Wirfs-Brock says that although every designer models one way, "for a given problem there are many reasonable solutions, and some very good solutions". Certainly not using the right abstraction affects the quality of the design in some way. I cannot say to what extent these "very good solutions" improve the qualities of the software, however. Bertrand Meyer kindly directed me to chapter 5 of the 2nd edition of his book OOSC in which he discusses the advantages of the correct use of OO for maintainability, extensibility and reusability on an analytical level; that’s what I have at the moment.

  • 2

    @Piovezan the best thing a programmer can do with a technology is to admit that he doesn’t understand it well unless it’s unequivocal that he understands. Everything you say on this page makes a lot of sense and showing above-average understanding. If everyone did the same, the programs would be much better :) This does not magically solve anything, but it is a point to avoid major disasters as we see every day on the Internet, here at Sopt. As it is difficult, everyone will respond generically, there is no way. Any formalization will only meet specific points. Lack space p/ debate everything

  • Over the years I have come to appreciate this answer more (and it goes against a point @utluiz on acquiring and applying experience): +1

  • Fantastic friends, always happy to contribute. I think everything put here, including the selected answer are great beacons for other developers

Show 7 more comments

Browser other questions tagged oop modeling language-independent paradigms

You are not signed in. Login or sign up in order to post.