Как организовать семейство классов?

[Вурдалак]

Ты пытаешься решить какие-то проблемы, которые сам себе придумал. Зачем нужна абстракция для различных небесных тел? Зачем нужен setParent()? Зачем нужна ссылка на предка в принципе?

 

[Redjik]

Я вот тоже не понял, рассказываешь тут про наследование и какой-то функционал, а в итоге пытаешься какое то хранилище данных на классах сделать.

 

[Lionishy]

@AnrDaemon
Дело не в задаче. Вне зависимости от задачи Ваш дизайн недопустим, потому что Вы боретесь с формальной логикой.

Коротко говоря, если некоторый контейнер G используется и для записи, и для чтения, то G, параметризованный одним типом, никак не может наследовать контейнеру G, параметризованному другим типом, вне зависимости от того, в каких отношениях эти типы состоят, если только это не тривиальная ситуация: параметризация одним и тем же типом.

Если задаёте какую-то иерархию контейнеров, то Вы однозначно выключаете либо get, либо set, а при сложной иерархии и get, и set.
Чтобы не попадать в ловушки, когда система типов бизнес-логики диктуется техническими интерфейсами, в мире ООП уже давно есть Silver Bullet : не использовать get/set методы в предметно-ориентированном языке.

P.S. Объяснить это хорошо и подробно на понятном Вам языке у меня не хватит ни сил, ни времени, потому я и дал Вам ссылку на статью, где общими словами проблема описывается как нарушение абстракции.

Откажитесь от сеттеров и геттеров. Перепроектируйте класс так, чтобы их не было. Если Вы не видите, как это можно сделать, то опишите общую задачу, которую Вы, лично Вы, решаете посредством такого подхода, вероятно, Вам укажут на более состоятельный вариант.

 

[AnrDaemon]

Ты пытаешься решить какие-то проблемы, которые сам себе придумал.

Если бы мы не придумывали себе проблемы, жизнь была бы несколько более скучной, ты не находишь?

Зачем нужна абстракция для различных небесных тел?

Не "абстракция для различных небесных тел" а "общая логика объекта". Наличие/отсутствие атмосферы, жидкости, твёрдой поверхности, количество зон поверхности, формат названия объекта при выводе, это только то, что сейчас могу вспомнить.

Зачем нужен setParent()? Зачем нужна ссылка на предка в принципе?

Не предка, а объект, вокруг которого расположена орбита этого объекта.
Два из трёх стандартных форматов вывода подразумевают ссылку как минимум на одного предка (A, orbiting B) либо на всю цепочку наследования (Planet A, System X (x, y, z), Y sector (x,y,z), Z galaxy).

Коротко говоря, если некоторый контейнер G используется и для записи, и для чтения, то G, параметризованный одним типом, никак не может наследовать контейнеру G, параметризованному другим типом

От прямого наследования я отказался, спасибо вашим подсказкам.

опишите общую задачу, которую Вы, лично Вы, решаете посредством такого подхода, вероятно, Вам укажут на более состоятельный вариант.

Надо разобрать входной поток данных (три формата, машинный, полумашинный, человеческий), делать конвертацию между ними, перебирать их в обоих направлениях, делать простые операции, типа ::count(), ::format($someformat).
Плюс сохранение в БД для дальнейшей работы, но это уже не относится к теме. Там вообще вопрос не в объектах, а в ресурсах и метаданных.

 

[AmdY]

Проблема в том, что ты бизнес сущность вроде Планеты пытаешься объединить со структурной фигнёй как коллекция.

class Solarsystem {
    public function __construct($name, $parent = null) {
       $this->parent = $parent;
       $this->children = new Collection('IPlanet'); // в коллекцию добавим тип
    }
}
$solar = new Solarsystem();
$solar->children->add(new Planet('Mars', $solar));
$solar->children->count();
$solar->children->first()->parent;

 

[AnrDaemon]

children уже множественное число, так же как men
Извини, убегаю, работа… Твой код пока не понял, надо будет не на бегу прочесть.

 

[fixxxer]

Не предка, а объект, вокруг которого расположена орбита этого объекта.

Ну тогда и передавай в конструктор объект, на орбите которого расположен конструируемый. И интерфейс соответствующий, с соответствующими методами - ведь это Земля знает, как вокруг нее Луна будет вращаться. И так далее рекурсивно.

Опять же, тут может быть хитро, скажем - система из двух солнц. В этом случае будет какая-нибудь BinaryStarSystem в этом качестве.

 

[AnrDaemon]

@AmdY, код понял, выйдя за дверь Разделить объект логики и коллекцию подчинённых объектов, да, это логично.

@fixxxer, у меня может не быть этого парента, даже если логически он быть должен (прислали скан отдельно планеты, например.) Как быть в этом случае?
По поводу "бинари", тут всё легче, слава богу, в механике нет таких заумных вещей, как барицентр, всегда есть главная звезда, всё остальное крутится вокруг неё.

 

[WMix]

едь это Земля знает, как вокруг нее Луна будет вращаться.

от массы(гравитации) каждого и расстояния
хотя с gl точки зрения ты прав

 

[fixxxer]

от массы(гравитации) каждого и расстояния
хотя с gl точки зрения ты прав

ну так необязательно же это единое тело - вон я привел пример с бинари стар

 

[fixxxer]

@AmdY, код понял, выйдя за дверь Разделить объект логики и коллекцию подчинённых объектов, да, это логично.

@fixxxer, у меня может не быть этого парента, даже если логически он быть должен (прислали скан отдельно планеты, например.) Как быть в этом случае?
По поводу "бинари", тут всё легче, слава богу, в механике нет таких заумных вещей, как барицентр, всегда есть главная звезда, всё остальное крутится вокруг неё.

если нету - как орбиту считать? короче давай реальную задачу, а то какая-то угадайка

 

[AnrDaemon]

Орбиты я не считаю - нет такой задачи (Тьфу-тьфу, чтобы не сглазить!)
Реальную задачу я привёл, это действительно ВСЯ задача, та, что относится к моему вопросу.
Всё остальное, это работа с БД на уровне ресурсов, статистика, выборки, аггрегация… чистый SQL без тени воображения.

 

[fixxxer]

если это реальная задача, то тут банальные структуры данных и никакого ооп

 

[AnrDaemon]

Ну, э… В ПХП нет такого отдельного понятия как "структура данных"… Нет же ж?…

 

[Redjik]

Зато есть пэттерн стратегия, если хочешь заморочиться, тащи от верхнего предка стратегию добавления ребенка каждому следующему ребенке, наворачивая свои странные правила.

 

[Lionishy]

Надо разобрать входной поток данных

Отлично.
Вот и решайте именно эту задачу. Не надо закручивать галактик -- нужно писать конечный автомат.

Когда процесс будет понятен, тогда и перейдёте к интерфейсам и наследованию.

Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы.

(Александр Степанов)

 

[AnrDaemon]

"Конечный автомат" написан три года назад. Чтение, импорт в БД. Сейчас возникла необходимость работать именно с объектами как со структурой.

 

[fixxxer]

Ну, э… В ПХП нет такого отдельного понятия как "структура данных"… Нет же ж?…

Можно изобразить массивом, можно использовать классы как структуры.
А вот во что это инкапсулировать (чтобы появилась какая-то логика и, соответствнно, ООП), из твоих пояснений непонятно совершенно.

 

[Lionishy]

"Конечный автомат" написан три года назад.

То есть, описанная вами выше задача уже решена.

Тогда откуда возникает необходимость

работать именно с объектами как со структурой

?
Тем более не ясно, как Вы пришли к заключению, что есть необходимость в выражении бизнес-логики разбора потока данных посредством наследования со сложной структурой типов.

Вам абсолютно верно пояснили, что Вы пытаетесь решать несуществующие задачи. Это плохо, очень плохо. В итоге это приведёт к тому, что Вы получите монструозный код, который нельзя будет модифицировать в том направлении, в котором растёт реальная задача, потому что он будет засорён техническим шумом от несуществующих проблем. Да и поддерживать этот код будет крайне сложно, так как, опираясь на основную задачу, будет чрезвычайно сложно понять предложенное решение, а подробности Вы забудете буквально через полгода.

 

[WMix]

@AnrDaemon, а что это, где работаешь? Журнал, роскосмос,...кому нужно небесными телами заниматься?