Хотейки и вопросы по проектированию классов?

Question

[Stadinov Denis]

Всем дрям, я с новой порцией глупостей.

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

1. Сейчас я обращаюсь к атрибуту класса так class->arr["name"], а хочется class->arr->name и это спокойно делается через магический метод __get, но что делать если у меня многомерный массив (class->arr->name["attr"])? Какую конструкцию использовать? Как лучше всё это упаковать, что бы потом так же красиво забрать от туда.

2. Как стоит поступить в таком случае:
У меня есть параметры материалов которые не меняются например материал и его габариты.
Лучше сделать массив с названием материала бревно(длина 3, ширина 5, высота 50) или лучше создавать отдельные массивы БревноДлина 3; БревноШирина 5; БревноВысота 50; и наверное стоит такие параметры вынести в отдельный ini-файл?

Спасибо!

Answer 1

[Алексей Яхненко]

1. не трогай свойства напрямую, используй методы.
$obj->getProperty($propertyName); //class->arr["name"]
$obj->getPropertyAttribute($propertyName, $attributeName); // class->arr->name["attr"]

если уж совсем невмоготу - сделай json_decode(json_encode($a)) - получишь объекты заместо массивов. но это патология.

2. лучше сделать массив с названием материала бревно(длина 3, ширина 5, высота 50).
разбирать потом названия вида БревноШиринаДверьСобакаТелеграф это обратно патология.

хранить данные в ини-файлах это сцуко оригинально, но лучше так не делать.

Comments

[Алексей Яхненко]

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

[Stadinov Denis]

Бро, спасибо! Начну с конца.
- Я как-то читал, что низкоуровневые параметры для производительности выгоднее хранить в ini файлах (писали это в комментах на php.net)

- Делать массивы с материалами конечно круче, но обращаться к ним как то уже не очень красиво выходит. $this->БревноРакета vs $this->Бревно[Ракета].
А хочется что бы было так $this->Бревно->Ракета

- Про геттер/сеттер зачем мне они если я делаю вызов атрибута из класса в котором этот атрибут существует?

ещё раз спасибо.

[Алексей Яхненко]

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

про матералы - если уж мы работаем с ооп, я бы завел вообще класс Material и у него свойство "parameters" в виде массива, и т.д. Ну тут надо предметную область понять, по твоим примерам не очень понятно что там и как.

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

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

а если в дальнейшем у тебя банально поменяется название свойства "arr" - достаточно будет поправить его в геттерах и сеттерах вместо того чтобы лазить по всему проекту рискуя где-то что-то пропустить. конечно, с учетом современных ide оно не так страшно, тем не менее, идея именно в этом.

Answer 2

[Ivan Velichko]

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

По поводу второго пункта. PHP и так вполне себе DDL язык. Если нужно хранить данные, то можно спокойно их хранить в специальных PHP файлах, содержащих один массив, например. И инклюдить их в нужном месте. Все эти замесы с ini-файлами (и еще того хуже xml-файлами) пошли от компилируемых языков, особенно из Java, когда описать конфиги непосредственно в Java-коде с возможностью их изменения без перекомпиляции всей программы достаточно проблематично.

Comments

[Stadinov Denis]

Иван, спасибо!
Про ini писал чуть выше, комментаторы с php.net утверждают, что такой механизм работает быстрее + удобство для обычного пользователя.

[Ivan Velichko]

Stadinov Denis: как что-то, требующее парсинга, может работать быстрее непосредственно хранения данных в самом PHP? Результаты профилирования в студию!) Обычный пользователь - понятие растяжимое. У кода на PHP обычный пользователь скорее всего и сам программист. И как программист могу сказать, что удобнее читать код, чем ini-файлы )

Answer 3

[Дмитрий Энтелис]

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

class car 
{
  public $manufacturer;
  public $engine;
  function __construct ()
  {
   $this->engine = new carEngine();
  }
}
$car = new car();
$car->manufacturer = 'bmw';
$car->engine->type = 'v6';

итд

Comments

[Алексей Яхненко]

публичные свойства это не к добру

[Stadinov Denis]

Спасибо, Дмитрий.

[Дмитрий Энтелис]

Алексей Яхненко: городить лишние геттеры-сеттеры - вот это не к добру)

[Алексей Яхненко]

$car->engine = new car(); - вот где истинная гибкость, вот мощь ООП.

[Ivan Velichko]

Дмитрий Энтелис: видел я пару проектов, где из-за таких рассуждений потом все классы обросли __get и __set, которые оборачивали свойства, которые раньше были публичными и пытались хоть как-то решить проблему полного отсутствия инкапсуляции. Хоть уже и ценой падения производительности из-за постоянных вызовов магических методов.