Что лучше?
Так:
Или так:
Для меня лично - "ответ очевиден", а для вас?
К "чему вопрос"? А к тому, что "лучшие производители" делают "часто" не так, как я 2считаю правильным".
И кстати "это всё" тянет за собой "долгое и сложное" обсуждение на тему Mutable и Immutable объектов.
Читаем Барбару Лисков. А именно книгу "Применение абстракций и спецификаций при разработке ПО" (http://padabum.com/d.php?id=34996).
Так очень много внимания уделяется константности и эквивалентности объектов.
Над этим (ИМХО) стоит задуматься... Хотя "людям воспитанным на Delphi" многое может "показаться странным"...
Особенно константность.. И "сопоставление объектов с числами".. Есть атомарное значение - 2 и есть атомарное значение 3. Для того чтобы получить 5 - надо сложить 2 и 3 и получить НОВЫЙ объект. А НЕ ИЗМЕНИТЬ состояние существующих.
На "ту же тему" - http://18delphi.blogspot.ru/2013/10/immutable.html
Ну и ещё...
Сейчас "много тем муссируется" насчёт Функциональных Языков.
В частности "на тему" ДЕТЕРМИНИРОВАННОСТИ состояний.
Так вот - "константность" или ДЕТЕРМИНИРОВАННОСТЬ - ДАВНО придумана Барбарой Лисков... Без всяких "функциональных языков", да и "ООП кстати". Ну если я "правильно читал"..
Так:
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
Ну и ещё...
Сейчас "много тем муссируется" насчёт Функциональных Языков.
В частности "на тему" ДЕТЕРМИНИРОВАННОСТИ состояний.
Так вот - "константность" или ДЕТЕРМИНИРОВАННОСТЬ - ДАВНО придумана Барбарой Лисков... Без всяких "функциональных языков", да и "ООП кстати". Ну если я "правильно читал"..
Как только увидел примеры кода, сразу понял к чему ты клонишь. Абсолютно с тобой согласен, для меня тоже ответ очевиден. Была на эту тему очень хорошая статья, очень хорошо на меня в свое время повлиявшая. Я поищу ссылку.
ОтветитьУдалитьВ одном только тебя поправлю :)
> Так вот - "константность" или ДЕТЕРМИНИРОВАННОСТЬ - ДАВНО придумана Барбарой Лисков... Без всяких "функциональных языков", да и "ООП кстати".
К тому моменту, когда Барбара Лисков закончила ВУЗ, функциональные языки уже существовали :) Ей было 18, когда появился LISP :)
Ром, ну понятное дело, что я СОЗНАТЕЛЬНО "передёрнул", чтобы читатели заинтересовались.
УдалитьВот эта статья. Рекомендую ее, как и весь журнал.
ОтветитьУдалитьhttp://fprog.ru/2009/issue1/eugene-kirpichov-fighting-mutable-state/
лучше "так"
ОтветитьУдалитьно "или так" проще.
вообще я стараюсь, если параметров больше одного (или заранее известно, что их кол-во будет расти), выделять отдельный record (или даже класс, или иногда интерфейс), (что на самом деле тоже не есть хорошо, но так проще)
"или так" - ничуть не проще.. доже СЛОЖНЕЕ как минимум за счёт лишних write. Да и ведёт к "странным" ошибкам. Типа "не задан ОБЯЗАТЕЛЬНЫЙ параметр". И делает объекты - mutable. Что чаще всего - не нужно.
Удалитьпроще - я имел ввиду:
Удалить- что так проще расширять функциональность (например добавлять необязательные параметры)
- легче читать (особенно, когда параметров становится больше 3х-4х)
вобщем, тут много всяких "если"
Да вот речь как раз об ОБЯЗАТЕЛЬНЫХ параметрах. Если их кстати становится БОЛЬШЕ ТРЁХ, то надо делать record или класс.. или интерфейс. В чём Вы ПРАВЫ. И ДАЛЬШЕ получается "матрёшка" из "константных", а не mutable объектов.
УдалитьА что до "проще расширять" - так вот НЕ ПРОЩЕ. СЛОЖНЕЕ, ибо при РАСШИРЕНИИ можно всегда "что-то" забыть. В отличии от случая с конструктором. И матрёшкой.
МАТРЁШКА.. ВАЖНОЕ слово..
УдалитьМАТРЁШКА из Immutable классов..
Не говорю уж о том случае когда порядок задания параметров ВАЖЕН.
ОтветитьУдалить