I do not understand how to identify classes when developing a program. Worse, I just can’t understand how classes should interact and what classes should do. Although the PLO is taken from our lives, still somehow nothing is obvious. Well, take the key words from the description of the future program - it is still possible to find out the behavior, how the program works in steps, but there's no point, because I cannot understand how classes should interact and what classes should do.

  • how everything is complicated ... well, and questions ... see examples, each class is a display of an idea, their behavior and interaction is a realization. Example, class apple - properties are green, class - basket, property - wicker, interaction - basket keeps apples, can add and remove them from itself. - Gorets 4:04 pm
  • 3
    @Barmaley "Although OOP is taken from our life" - who did this with your life? Once I thought that if, while solving ordinary tasks, the PLO creates problems, then in simulation, this is what the doctor prescribed. Later I read that about modeling I was very wrong. - alexlz
  • 3
    @alexlz and then where are I ?! - Barmaley
  • 3
    @Barmaley is so thin trolling :) - Zowie
  • one
    @alexlz duck topikstarter another, Barmaley just edited the message - rasmisha

9 answers 9

Try to write a couple of very simple classes consisting of a couple of methods and try to link them, as already mentioned above. No need to immediately raise a non-strong niche by re-reading tons of theory and practice. It is better to do this and that gradually, rather than vice versa.

    If it is difficult for you to design from above, then once try to write a program from below in Chinese style without declaring classes and functions at all, leaving only variables, mathematical expressions and built-in libraries of the language. As soon as it grows in size so that you can no longer debug, start to merge repeating sections of code into functions. Saw repeating variable bursts unite them in structures. Once realized that the same functions are applied to the same structures, it's time to declare a class. Has the Project expanded to such an extent that there are several classes similar to each other? It is worth thinking seriously about inheritance, polymorphism and the separation of interfaces from implementation. Was the project just huge? It's time to release the STL data type independent algorithms. Developing an iterative process and if you have enough patience you will sooner or later come to the desired class hierarchy. Far from the fact that it will coincide with the one that you assumed at the very beginning. In order to immediately ensure such a coincidence, a great deal of design experience is needed.

    For example, the version with Tetris that was offered to you in the comments is a good example of OOP over-engineering and incorrect design. With proper skill, this whole game can be reduced to a one-dimensional byte array storing the playing field and dozens of functions above it without declaring a single class. Generating the desired figure, deleting full lines, lowering the entire image one cell down, rotating the figure (the figure is not a separate class, but just 4 bytes in the array), determining whether the figure collides with the main structure, etc.

    • and stuff it all into one class called "bitcrushing_premature_optimized_tetris". It would have been a true masterpiece. - igumnov
    • Apparently @Yura Ivanov deleted his comment about the small glass. So the response comment from @igumnov somehow hung ... - avp
    • 3
      As a useful comment, I would like to answer that in real life, the question of over-engineering in many cases is a "reserve for the future." Rarely does a project end on the first version and the issue of extensibility arises very acutely when planning the budget for the second version. What can be done in one ingenious procedure, neglecting any principles (not only the EP, but also in procedural programming), rejecting the convenience due to the "cumbersome" structures leads eventually to rewriting the entire project from scratch. The same will be with an example about tetris, with a probability of 1. - Yura Ivanov
    • 2
      If the path from Chinese to the ideal can be useful at the stage of learning a profession, then in adulthood there will be no such luxury. - Yura Ivanov
    • 2
      It seems that a discussion of this issue showed that it is really difficult to come up with a small task in which the use of the PLO would not be "far-fetched." - avp

    My answer will be quite unexpected. To learn how to design classes and their interaction, you need to study philosophy. Of course, it does not contain any ready-made recipes, but it teaches you to think in the right way. Designing classes requires advanced abstract thinking, the ability to distinguish the essential features of an object from the non-essential, the ability to identify common properties from a whole host of classes. Philosophy is doing just that. Only the subject of her research are the objects of the real world and how they interact with each other.

    Well, or you can go a simple way. There is a very practical rule that helps in 99% of cases. The fact is that abstract thinking is closely related to language. Very closely. In fact, when a person thinks, he thinks in some language (experienced programmers immediately think in C ++). Therefore, philosophy is very closely connected with linguistics. And it can be used as follows. The rule is very simple: if you manage to come up with a simple name for a class that fully reflects its essence, then the class is designed more or less successfully. Of course, when adding something new to the class, you need to ensure that the name still matches. The trick is based on the fact that in a language that has developed over the centuries, there are already convenient names for all the necessary abstractions. If the name cannot be picked up, then something is wrong with the class.

    • Interesting thoughts. - And in my opinion, philosophy is closely connected with linguistics only because it does not produce anything new. In fact, new things (thoughts) are non-verbal at first, they appear in the form of certain visual images (often dynamic, changing). Then, of course, these images and the process of their transformation are described in words, i.e. a combination of already existing (and verbal) concepts. Otherwise, this new will remain only in the head of the inventor. - Of course, for practical programming (... in the comments there is little space ...) the trick with the names looks reasonable. - avp
    • one
      Common sense dictates that it should be so. It seems that any thought first appears in the head, and only then does its translation into the language occur. Unfortunately, in this case, common sense misfires. The expression of a thought in a language is not just a translation from the language of thoughts into the language of concepts. There is simply no language of thought. And people simply cannot think such thoughts that cannot be expressed in a language they know. This question is very well researched. People with limited vocabulary have no problems with how to express their complex thoughts. In their heads complex thoughts do not originate. - Shamov
    • Another hypothesis is possible: There is simply no language of thought. And people simply cannot think such thoughts that cannot be expressed in a language they know. This question is very well researched. it's just that we are all different, and the researchers involved in this topic are structured the way they describe it. - avp
    • This is a very true idea. Indeed, we are all different, and therefore the language of thought cannot exist. After all, language is an instrument of interaction. Roughly speaking, this is an analogue of the interface for interacting with different objects that have something in common. But we are so different that the thoughts of two people cannot be reduced to a common interface. Yes, this is not necessary. At least, until people evolved into telepaths. - Shamov
    • four
      @Shamov "experienced programmers immediately think in C ++." Even experienced pascal programmers? - alexlz

    I would say that about design. This is, in general, 90% art, here it is either given or not.

    Take for example the design of the architecture of the game "tic-tac-toe". If you are not able to think of anything, then you are not given. If within an hour you give birth to a viable structure (albeit not ideal), then it means given. Then you can read smart books or, for example, such a set of articles , in general, gain experience and so on.

    • And what to program in tic-tac-toe? There will be a main function and a maximum of two functions. In one check who won, in the other, you can redraw the playing field. And what about art, can a person become a great musician without knowing how to use a musical instrument? And I can say almost no experience in the PLO. - chevchelios
    • @chevchelios Classes which will be in tic-tac-toe? PS Designing a program is how to write music. Agree, even being able to play instruments, not everyone can write music. - Barmaley

    Nothing is clear. If you need an understanding of the OOP syntax, then read Laforet R. "Object-Oriented Programming in C ++" or, better, Straustrup.

    If you need an understanding of "design, ideology, paradigm," then I recommend to study this on the book "The Philosophy of Java," Bruce Ekkel.

    • 2
      I know the syntax. But to know the syntax does not mean to know OOP. - chevchelios
    • one
      ru.wikipedia.org/wiki/… - Gorets
    • Is OOP syntax C syntax or Smalltalk syntax? (Historically, it can be the synula Simula 67, i.e. the extended syntax of Algol-60) - alexlz
    • C ++ syntax - chevchelios
    • A. And then you can still remember the closures of the lisp / circuit, which can be considered as object-oriented programming inside out ... - alexlz

    I advise you to read the book "Object-Oriented Analysis and Design" Gradi Bucha. It is written in a bit heavy language, but it helps to understand the OO paradigm perfectly.

      @chevchelios , don't worry! I, too, at the very beginning of my journey did not understand the meaning of the PLO (yes, I am not the only one, I think ...). Once I had to solve a problem that without the PLO could be solved with a crutch, as I actually did. Long puzzled over the task, until one of my friends suggested to me to use OOP. "I do not see the point!" - I said, but the “same Familiar” showed me how to solve this problem easily using OOP. His code looked much more elegant and shorter than mine, worked in any cases, unlike mine =) Long digging into his code and examining everything that I did not understand, I suddenly gasped and realized the power of OO programming! The moral of this story is: Do not rush, wait for the right moment to study, and all you need is to “climb” into your head. Everything is learned in practice.

        Microsoft has a free book for small C #, OOP is not very well described there. Far from ideal, but still.

        I would also recommend CLR via C # 3rd edition author Jeffrey Richter. This is not quite the PLO, but about the language itself is object oriented. Some of what I know about OOP has now been derived from this book. If you plan to contact C #, I recommend it immediately and read it.

          Read exactly Björn Straustrup "The C ++ Programming Language" ("C ++ Programming Language") and, if you drag out, I recommend his other book "Design and Evolution C ++". Why him? Yes, because he was actively involved in creating the ANSI / ISO standard for C ++, the book has many awards and is written in an accessible language.