пятница, 14 марта 2014 г.

Коротко. Про конструкторы и свойства...

Что лучше?

Так:

MyObj := TMyObj.Create(aParam1, aParam2, aParam3);

Или так:

MyObj := TMyObj.Create;
MyObj.Param1 := aParam1;
MyObj.Param2 := aParam2;
MyObj.Param3 := aParam3;

Для меня лично - "ответ очевиден", а для вас?

К "чему вопрос"? А к тому, что "лучшие производители" делают "часто" не так, как я 2считаю правильным".

И кстати "это всё" тянет за собой "долгое и сложное" обсуждение на тему Mutable и Immutable объектов.

Читаем Барбару Лисков. А именно книгу "Применение абстракций и спецификаций при разработке ПО" (http://padabum.com/d.php?id=34996).

Так очень много внимания уделяется константности и эквивалентности объектов.

Над этим (ИМХО) стоит задуматься... Хотя "людям воспитанным на Delphi" многое может "показаться странным"...

Особенно константность.. И "сопоставление объектов с числами".. Есть атомарное значение - 2 и есть атомарное значение 3. Для того чтобы получить 5 - надо сложить 2 и 3 и получить НОВЫЙ объект. А НЕ ИЗМЕНИТЬ состояние существующих.

На "ту же тему" - http://18delphi.blogspot.ru/2013/10/immutable.html

Ну и ещё...

Сейчас "много тем муссируется" насчёт Функциональных Языков.

В частности "на тему" ДЕТЕРМИНИРОВАННОСТИ состояний.

Так вот - "константность" или ДЕТЕРМИНИРОВАННОСТЬ - ДАВНО придумана Барбарой Лисков... Без всяких "функциональных языков", да и "ООП кстати". Ну если я "правильно читал"..

9 комментариев:

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

    В одном только тебя поправлю :)

    > Так вот - "константность" или ДЕТЕРМИНИРОВАННОСТЬ - ДАВНО придумана Барбарой Лисков... Без всяких "функциональных языков", да и "ООП кстати".

    К тому моменту, когда Барбара Лисков закончила ВУЗ, функциональные языки уже существовали :) Ей было 18, когда появился LISP :)

    ОтветитьУдалить
    Ответы
    1. Ром, ну понятное дело, что я СОЗНАТЕЛЬНО "передёрнул", чтобы читатели заинтересовались.

      Удалить
  2. Вот эта статья. Рекомендую ее, как и весь журнал.
    http://fprog.ru/2009/issue1/eugene-kirpichov-fighting-mutable-state/

    ОтветитьУдалить
  3. лучше "так"
    но "или так" проще.
    вообще я стараюсь, если параметров больше одного (или заранее известно, что их кол-во будет расти), выделять отдельный record (или даже класс, или иногда интерфейс), (что на самом деле тоже не есть хорошо, но так проще)

    ОтветитьУдалить
    Ответы
    1. "или так" - ничуть не проще.. доже СЛОЖНЕЕ как минимум за счёт лишних write. Да и ведёт к "странным" ошибкам. Типа "не задан ОБЯЗАТЕЛЬНЫЙ параметр". И делает объекты - mutable. Что чаще всего - не нужно.

      Удалить
    2. проще - я имел ввиду:
      - что так проще расширять функциональность (например добавлять необязательные параметры)
      - легче читать (особенно, когда параметров становится больше 3х-4х)
      вобщем, тут много всяких "если"

      Удалить
    3. Да вот речь как раз об ОБЯЗАТЕЛЬНЫХ параметрах. Если их кстати становится БОЛЬШЕ ТРЁХ, то надо делать record или класс.. или интерфейс. В чём Вы ПРАВЫ. И ДАЛЬШЕ получается "матрёшка" из "константных", а не mutable объектов.

      А что до "проще расширять" - так вот НЕ ПРОЩЕ. СЛОЖНЕЕ, ибо при РАСШИРЕНИИ можно всегда "что-то" забыть. В отличии от случая с конструктором. И матрёшкой.

      Удалить
    4. МАТРЁШКА.. ВАЖНОЕ слово..

      МАТРЁШКА из Immutable классов..

      Удалить
  4. Не говорю уж о том случае когда порядок задания параметров ВАЖЕН.

    ОтветитьУдалить