How do you design classes in OOP and how do they interact?

Question

OOP

Suppose you have a technical specification for a certain project, and according to your mind, you must first Design all the necessary classes before you start coding, so as not to invent anything "on the fly" and not mess up (which can lead to an architectural dead end and rework of Everything).
So, what do you usually design in? On a piece of paper (like me :)), in some special programs that create UML diagrams, or just "in the mind"?
By design, I mean exactly the connections "this class does this and that, then it takes another class and does this with the help of it. Either it is a service class that itself is transferred somewhere to the client class and must do something, and etc.

Answer 1

In the PHP community, design and architecture issues are generally not developed. Most sculpt what they come up with. PHP was originally born for primitive homepages, it absorbed all the frivolity, a low entry threshold and, as a result, a rather weak community, which often becomes the object of jokes.
You need to look for answers to design and architecture questions in Java. For example, almost everyone there from the very beginning heard about the de facto layered architecture that has become the standard, it is also layered architecture, it is also n-tier architecture and saw an image similar to this
From which you need to understand that the entire program can be divided into several layers and the dependence between the layers should be directed from top to bottom, but not vice versa. Thus, for example, a framework can be encapsulated in a presentation layer and at any time painlessly replaced with another one, since other layers do not know anything about it. All business logic is encapsulated in the domain layer in the form of a plain old java object, which does not depend on anything at all, and also provides interfaces (for example, repositories) for the infrastructure layer, and only in this layer will actually be the very real OOP that is so trying hard to find. There is no third-party code in the business logic, and accordingly, all third-party code can be changed at any time without touching the business logic at all.
To do this, you need to open some book, where they will lead you by the hand from scratch to a specific application built using this architecture. For example Implementing domain-driven design, even though this book is about DDD, but I have already said that layered architecture is de facto. With experience, it will be clear that in simpler applications, the number of layers can be reduced, understanding what compromise will have to be made, that sometimes you can combine the domain and the infrastructure part and get the well-known Active Record template, or even discard these layers and get the transaction script template, when the solution simply does not require something more complex. An understanding will come of how you can start with a transaction script and eventually gradually roll towards the domain layer, through an active record or not through an active record if you ever need it, and the like. It will become clear why, how and when to use the patterns that Martin Fowler wrote about in his book Patterns of Enterprise Application Architecture .
The acquired knowledge can be applied to any language. Including PHP. It would be nice if the level of this community would at least slightly catch up to the level of Java, instead of bombing five-level ifs creating such cyclomatic complexity that all code metrics burn brighter than red.

Answer 2

Divide TK into modules, define their external interfaces (what some modules can request from others), try to minimize them.
For example, the authorization and authentication module is a lot of things inside, but outside - only general user data (for output) and the ability to find out if he is authorized or not. If user rights are implemented, then other modules do not need to know exactly how (for example, whether the user belongs to some group). They need to know if it has a specific level of access to a specific module or not.
When you have decided on the modules, you make a similar division into classes inside each of them: first the interface, then the giblets.
And only by going to the implementation of each class, you can turn around to your procedural and see if there is code that can be used from there as raw material for class methods.

Answer 3

It all depends on the scope of the project. The larger and more complex the project, the more design. The beauty of UML is that you can immediately generate code from it. Of the minuses - it does not always work exactly as you need in the project. Well, in general, I would prefer to mainly design component interfaces because the internal structure is already the second step and does not affect the overall picture of the world

Answer 4

Instead of a piece of paper - miro. But the essence is the same - to describe the objects, methods and components in which these objects are collected. Next to it are the api methods and the database structure. But this is so. I would also love to read about the correct process and design software.

Answer 5

Most often, in the area where you work, there are already adopted architectural solutions. Best practice. Stick to them - get rid of many problems in the future.
1. generally accepted - so there will be no surprises for programmers who maintain the code
2. no need to waste time reinventing the wheel.
3. The names of variables, packages and functions speak about the purpose in the context of the architecture.
4. community help.
Now, if the programmer decides to stick to the generally accepted (good) solution, he will have no questions about how to organize the key classes. 20% of the classes remain for special cases (simplify, break up large classes, etc.) It is desirable to solve these cases also "generally". Try templates if they fit. Typical solutions and typical names.
If even a piece of paper is needed for design, this means there is complexity. This is already bad. This complexity must be very justified. Trying to make everything as simple as possible is an art and creativity in this.)