vitaly_74

Поли - много, морф - форма. (поправьте если что)
представь у тебя есть бэк и фронт.
фронт общается с бэком посредством апи.
а теперь представь вместо бэка на php подставить бэк на ruby (или на чем нибудь другом).
а фронт останется таким же. Так вот чтобы обеспечить четкую работу фронта, при смене языка программирования, фронт и бэк должны общаться по некоторому "контракту", т.е. если я запрашиваю с фронта на бэке корзину товаров, то ответ всегда должен содержать одни и теже поля (но например могут быть разные значения).
Полиморфизм связан с таким понятием как "контракт" в программирование - это интерфейсы.
Перейдем к примеру из программирования.
Представим что бизнес требует сегодня подключить платежную систему например эпл пей, для проведения оплаты например методом makePay()
Далее через неделю бизнес решает перейти на google и ты делаешь также реализацию makePay() для гугла.
А затем к тебе еще раз приходит бизнес и говорит "нам нужно снова работать с эплом. Тогда Ты просто меняешь в клиентском коде объект GooglePay() на ApplePay() и у тебя все работает.
Это и называется полиморфизм.
У тебя 2 класса, работают по одному контракту (интерфейсу) в котором записано, что объект который исплементирует данный интерфейс должен уметь выполнять makePay();
и вот через 3 месяца к тебе еще раз приходит бизнес и говорит давайка поменяй нам платежную систему на binanePay(). ну собственно, ты создаешь одноименный класс, имплементируешь туда интерфейс с makePay() и в клиенстком коде просто меняешь ApplePay на BinancePay и теперь бизнес уже работает не с эплом а с бинанс.
т.е. Полиморфизм дает возможность заменить один объект на другой.

К сожалению вы уже отошли от концепции ООП, ООП - это не прямое описание объектов, т.е. это не прямое моделирование объектов. Говоря об ооп мы говорим об объекте. Объект, с технической точки зрения - это сущность которая имеет свое поведение и состояние (по другому это называется инкапсуляция). Чтобы правильно спроектировать объект нужно понять что он должен делать, какие обязанности выполнять, или например мы должны понять что мы хотим, чтобы объект для нас сделал. Заметьте я не говорю что мы хотим узнать от объекта, или что то от него получить, а говорю, что мы хотим чтобы сделал объект (т.е не отдавал нам данные, а что либо сделал).
следовательно, если ваша планета ничего не делает. и вам от нее ничего не требуется, а нужен ли вам такой объект в коде? Но если она что то делает - значит можно подумать о конструкторе, эмпирически есть правило (негласное) если конструктор принимает более 4-5 аргументов значит вы делаете что то не так.
моделировать сам мир и сами объекты (имею ввиду описание) нужно, на мой взгляд в реляционной или иной бд.

object thinking
elegant objects

метод call насколько я помню нужен, чтобы вызывать "специфические функции" по сути его иногда можно использовать как фабрику:

__call($name, $params){
   if($name === 'createTest'){
      return $this->createTest();
   }
   if($name === 'createProduction'){
      return $this->otherMethod();
   }
}

Обычно в фабриках используются конструкции switch case но мне было лень ее писать.
также в методе call можно возвращать новые объекты например:

__call($name, $params){
   if($name === 'createTest'){
     $storage = [];
    $count = $params['count'];
     while ($count--) {
     $storage[] = new Test();
     }
      return  $storage;
   }
}

Проблемы которые вы можете получить используя второй вариант описал Михаил
Предложил бы реализовать второй вариант таким способом:
messages:
to | from | date | is_read
а в модельку добавить метод:
makeARead(): void;
в конструктор модельки можно передать id сообщения.
тогда если использовать ваш код то можно сделать так:

$message = new Message ($messageID)
$message->makeARead();

а создавать сообщение так:
$messages->addMessage(From, To);
если нужно сделать список сообщений прочитанными сделайте декоратор для $messages, например:

$messages = new MakedARead(
   new Messages(
      $conditionOfMessages
   )
)
return $messages->list(); //Здесь в цикле делаем все сообщения прочитанными.

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

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