Class naming?

Question

PHP

Good afternoon. When developing one system, I ran into the issue of naming classes in complex cases. The problem is that in a class hierarchy, an individual element does not always have only one "ancestor" (not only in the sense of inheritance ("a flower is inherited from a plant"), but also more generally "a flower has leaves"). Actually, the question is as follows - according to what rule should these elements be named?
A few examples of classes with names that cause problems (sorry for stupid examples):
- Lily, inherited from flower (B, inherited from A)
- Petal, which only a lily can have (C, which is used only in B)
- Leaf , which can be both a lily and a flower in general (D, which is used in both B and A)
- A stamen, which can be in both a lily and a poppy, but not necessarily in a flower in general (E, which is used by both F (which, in turn, is inherited from A), and in B, but in A it is not used )
And an extreme case: there is an apartment in which there is some beautiful garbage. Lily, in principle, can be used as a beautiful garbage. How to name the adapter "Lily as Beautiful garbage" so that it does not get lost among all classes (because theoretically it belongs to the "apartment" group, but also depends on the "flowers" group)? Abstractly, there is a G that uses H; what is the name of I, which allows you to use B as H?
The hitch arose due to a strictly hierarchical file system and the habit of naming classes a-la folders (ie Fuston_Http_Response_Cookie_Marked). This habit just does not answer the question "what is the name of the interface that will allow Testing_Database_Cache_Cookies to use the foreign Fuston_Http_Response_Cookie class as its own Testing_Database_Cache_Cookies_Cookie?".

Answer 1

use namespaces.
namespace Tickets\LkBundle\Entity;
use FOS\UserBundle\Entity\User as BaseUser;

Answer 2

Think not about how to name the classes, but about how to use it all.
Think interfaces first. In your case, in my opinion, you need to partially abandon inheritance and use a strategy. Use the factory pattern to instantiate an object.

Answer 3

1. Never name classes
Parent_child_, etc. 2. Use namespaces, this will save you from ugly names
3. Look at the naming of classes in Zend (peer), the logic of their names speaks for itself
If you stick to these three points, then you will never get lost =) and the names will be beautiful and the structural logic will always be clear.

Answer 4

class Leaf {} // лист

class Thorn {} // шип (т.к. тычинка вроде как у всех цветковых есть)

class Flower // цветок
{
    Leaf[] leaves;
}

interface Thorny // с шипами
{
    Thorn[] thorns;
}

class LilyPetal {} // лепесток лилии

interface CuteThing {} // красивая фигня

// лилия — шипастый цветок, да и к тому же, красивая фигня
class Lily : Flower, Thorny, CuteThing
{
    LilyPetal[] petals;
}

class Apartment // квартира
{
    CuteThing[] things;
}

Regarding file naming in style:

"what is the name of the interface that will allow Testing_Database_Cache_Cookies to use the foreign Fuston_Http_Response_Cookie class as its own Testing_Database_Cache_Cookies_Cookie?"

... then it is not clear why this is needed at all. Especially given that this is often not possible.
The name of the class should briefly describe the entity, and not talk about the features of the internal structure.

Answer 5

1. I got the impression that inheritance is confused with delegation here. If different objects that do not participate in inheritance (i.e., in a good way, a room and a leaf should not have common ancestors), there should be common methods - then there are several ways of development: impurities, delegating a special object with common behavior to objects . And, if the implementation is simple, then for each super-class you can write your own implementation.
2. It is better to name classes clearly. Maybe you should pervert, write a small script that scans class files and creates an array: array('class_name'=>'class_file', ...)? You can do this only for this part of the project and register a separate autoloader for it.