UML model of a Yii2 application, implementation of an interface by a group of classes. How? Is there a pattern for this?

Question

Yii

Hello. We need a specialist in OOP and UML, who worked with MVC at one time!
I’m just learning (I don’t offer courses and other options myself), but I don’t have a lot of time for specifically designing in UML, + I don’t have enough experience in OOP, so I’m asking for advice. I read GOF, Zandstra, etc. Right now I'm writing a simple directory management engine. Typical CRUDs, wherever possible, essentially form the basis of the project. But I do it based on the objectives of the training, in order to competently use the acquired skill, paying attention to BP in another project (online stores, etc.).
Task 1
Competently and appropriately use the capabilities of interfaces. In this case, I have not yet fully understood whether I need this or whether I can also stick between Base [class] and the final class - the so-called. Real[class], or is it better to use an interface for this? the class most likely will not have a body, because RealClass is essentially a generic class, which, however, is intended to be used already in the domain zone. Those. this is the base class of the domain, if we move a little further and look already at the scale of the metamodel.
Hence the question - is it better to have an interface or an intermediate class (..what if then for everyone in the domain you have to write additional functions or modify the constructor? You guess the hell. On the other hand, if you talk like that, you can say this about any interfaces that are not used for multiple inheritance, or am I wrong?)
Task 2
Just writing " [classname] implements [interfacename] " is of course possible in the code in each class. But is there a more elegant solution to this problem? The idea is actually as old as the world: accustoming myself to DRY, I reuse typical CRUD-actions in different Yii controllers, but maybe there is an optimizer dog buried somewhere, which I, due to inexperience, have not yet managed to dig up?
Subtask : how best to display in the UML the relation of a group of elements to another (for example, the same implementation of an interface by many Actions) without the need to draw it from each element (the hand will fall off if there are 100 of them). Recommend a visual pattern like: group(object1 -> Int, object2 -> Int, ... , ObjectN -> Int), where Int is an interface, "->" is a connection type, and Object is an Action in our case.
Note
- Base[classname] are wrappers to ensure a smooth update of Yii itself in the future, don't mind.
- let me remind you in advance: for such a simple task, I am using UML solely for the purpose of training and mastering
OOP, besides, this project has a chance to grow and scale, all the more so a competent architecture is needed from the very beginning.
With reverence and hope, I am attaching a class diagram, a DDL diagram, and an interface layout so that I can give mega-useful advice to OOP green dudes like me as quickly and without strain as possible.
Thanks in advance.

Answer 1

We need a specialist in OOP and UML, who worked with MVC at one time!

I see an inconsistency here. Usually when they talk about UML - all these things like controllers and so on. written at the component level. In UML, they usually describe only domain logic, that is, what is important.
In any case, in Yii, such approaches work very poorly. There you are not doing OOP, but designing a database (these are slightly different things), and everything else is based on this.
If you want to figure out UML (it’s not clear why the truth is, but that’s up to you), then it makes sense to take which ORM sharpened for OO-first (in fact, Doctrine2 from the current ones) and have fun there. There will be profit.
p.s. forget about that useless backend acronym MVC. While you are "designing controllers" - there is no sense in it (well, that is, as long as you have the logic of working with data in the controller).
Read Applying UML and Patterns - Craig Larman - great book. You can also read Uncle Bob (about SOLID). If you are interested in design topics, then this will be useful. Once again we started talking about the design of the logic of the subject area - Eric Evans - Domain-Oriented Design.
1) composition is always better than inheritance
2) inheritance is needed in order to organize subtypes. If you have entities that by their nature require inheritance, then you can. So, it's best to avoid it. OOP is not about inheritance at all.
3) interfaces are needed in order to organize dependency inversion and / or subtype polymorphism. You can read about protected variations from Larman in order to understand why they should be used.
In the UML, relationships between types are very easy and simple to display:
How can you ignore it if you are doing UML for the sake of UML? So far I haven't seen anything from OOP in your diagram. There are data structures with public properties, there are ... controllers (suddenly) that mutate the state of these structures .... This is not OOP - this is procedural programming with classes.
So far it looks like a waste of time because you've chosen the wrong tool (yii) to practice designing OO solutions.
I would recommend you:
- Understand what OOP really is (this is not about encapsulation, polymorphism, and even more so not about inheritance, because all this was before OOP and all this, except for inheritance, is an important principle of structured programming). This is about state hiding and dependency management (connectivity, coupling & coheasion by Larman)
- Take tools that are more suitable for designing OO solutions (some kind of fashionable Laravel + Doctrine2 now)
- if you want to keep messing with Yii, make sure that the domain logic doesn't know anything about Yii, then you won't need to deal with these Base* classes at all. Read about Row Data Gateway (it's essentially the predecessor of ActiveRecord) and how it was used in the context of a domain model.
I'm not sure what you need, but I'll add. Patterns are a dictionary. These are names for typical things. They say "Vasya, start caching the directory with the repository decorator" and Vasya understands what and how to do. You don't need to focus on them.
The original book on GoF is so-so in this regard, now it's better to look towards Head First Design Patterns Well, in addition to patterns, you need to understand general principles such as the law of demeter, SOLID, GRASP, etc. Then the understanding of everything will be more systematic.