Это пока.
У программиста будет аврал при починке бага на проме, и он быстро поменяет код, даже не взглянув на комментарий — всё, ваша документация врёт.
Не обязательно аврал: просто может быть невнимательный человек; конец десятичасового рабочего дня; просто пофигист и т.д.
Проблема такой «документации» в том, что она человекозависима, а значит — ненадёжна, а значит — ей нельзя доверять и мало кто её будет читать, а значит — и писать её не стоит.
Есть, конечно, исключения, когда комментарии писать нужно: если изменения в данном месте могут аукнуться совсем в другом (читатель кода может не знать этого) и если разработчик выбрал какой-то нестандартный/нелогичный подход: надо объяснить будущим поколениям — почему (Ваш пример, как я понимаю, как раз про это).
Всё, других резонов написания комментариев/документации нет.
Почему же только в C++? У нас в команде (C#) тоже действует правило: «Переменная должна объявляться максимально близко к месту первого использования». И множественные return приветствуются.
В 90-е (до Windows 95) подрабатывал написанием небольших бизнес-программ (складской учёт, кадровый и т.д.), использовал Turbo Pascal + Turbo Vision. Но вот однажды в руки попала книга Григория Зельднера по QuickBasic 4.5, и так мне этот Бейсик в душу запал, что следующую программу (расчёт зарплаты для госучреждения) я на на нём и написал )))).
С окнами, менюшками и прочими интерфейсностями в текстовом режиме.
Эх, жаль, хороший был язык…
Прощу прощения за долгую задержку, на работе аврал :(
Тогда у меня вопрос что вы называете анемичной моделью, потому что в текущем контексте я ей зову просто структуру кладущуюся в базу в виде полей+геттеров+сеттеров
Анемичная модель предметной области — это классы-модели без поведения и классы-сервисы без состояния. Если сильно огрублять, то в богатой модели каждой бизнес-сущности соответствует один класс, а в анемичной — два, модель и сервис.
Так ведь в том и дело что контроллировать состояние приходится клиентскому коду,
Состояние контролируют сервисы, которые являются частью модели предметной области и, соответственно, не являются клиентским кодом.
Почему не контролирует? То, что поведение и состояние хранятся в разных классах, не означает, что поведение не может контролировать состояние.
Клиентский код вообще не должен заниматься такими вещами, как консистентность бизнес-данных, вся работа с предметной областью собрана в одном месте и доступна наружу через контракты/API. А как уж она там внутри устроена — богатая модель или анемичная — это вопрос другой, как я уже говорил выше — ортогональный «размазанности» или «скучкованности».
Повторюсь ещё раз — в моём текущем проекте используется анемичная модель предметной области (такая архитектура от предков досталась), но при этом вся бизнес-логика собрана в одном месте, а не размазана по всей системе.
Да я вообще не об этом. Я о том, что анемичная модель, это обязательно «размазано по всему приложению» — это неправда. Можно размазать и анемичную модель, и богатую; и ту, и другую можно собрать в одном месте. Так что включать данное утверждение в определение анемичной модели не стоит.
И это никак не зависит от того, что понимается под моделью предметной области — только данные, только поведение или их совокупность.
“Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению
В моём текущем проекте используется анемичная модель предметной области, но при этом вся бизнес-логика собрана в одном слое. Так что «модель предметной области размазана по всему приложению» — это не про анемичную модель, вещи ортогональные.
И во фразе Фаулера, которую Вы как бы перевели, об этом ни слова.
Меня раз и навсегда отучили не блокировать компьютер, когда я, вернувшись на рабочее место, обнаружил фото болгарского блондина-пед… ста на весь рабочий стол. До сих пор как вспомню, так вздрогну…
Почему-то Вы сравниваете время жизни версии ОС, коей является Windows XP, и ОС (Linux). Корректнее тогда уж сравнивать Linux со всей линейкой Windows, которой, даже если не считать 3.X и всё, что было до неё, исполнилось уже 21 год, и угасания этой «вспышки» в обозримом будущем не предвидится.
У программиста будет аврал при починке бага на проме, и он быстро поменяет код, даже не взглянув на комментарий — всё, ваша документация врёт.
Не обязательно аврал: просто может быть невнимательный человек; конец десятичасового рабочего дня; просто пофигист и т.д.
Проблема такой «документации» в том, что она человекозависима, а значит — ненадёжна, а значит — ей нельзя доверять и мало кто её будет читать, а значит — и писать её не стоит.
Есть, конечно, исключения, когда комментарии писать нужно: если изменения в данном месте могут аукнуться совсем в другом (читатель кода может не знать этого) и если разработчик выбрал какой-то нестандартный/нелогичный подход: надо объяснить будущим поколениям — почему (Ваш пример, как я понимаю, как раз про это).
Всё, других резонов написания комментариев/документации нет.
С окнами, менюшками и прочими интерфейсностями в текстовом режиме.
Эх, жаль, хороший был язык…
Анемичная модель предметной области — это классы-модели без поведения и классы-сервисы без состояния. Если сильно огрублять, то в богатой модели каждой бизнес-сущности соответствует один класс, а в анемичной — два, модель и сервис.
Состояние контролируют сервисы, которые являются частью модели предметной области и, соответственно, не являются клиентским кодом.
Клиентский код вообще не должен заниматься такими вещами, как консистентность бизнес-данных, вся работа с предметной областью собрана в одном месте и доступна наружу через контракты/API. А как уж она там внутри устроена — богатая модель или анемичная — это вопрос другой, как я уже говорил выше — ортогональный «размазанности» или «скучкованности».
Повторюсь ещё раз — в моём текущем проекте используется анемичная модель предметной области (такая архитектура от предков досталась), но при этом вся бизнес-логика собрана в одном месте, а не размазана по всей системе.
И это никак не зависит от того, что понимается под моделью предметной области — только данные, только поведение или их совокупность.
В моём текущем проекте используется анемичная модель предметной области, но при этом вся бизнес-логика собрана в одном слое. Так что «модель предметной области размазана по всему приложению» — это не про анемичную модель, вещи ортогональные.
И во фразе Фаулера, которую Вы как бы перевели, об этом ни слова.
«Не большой кусок грязи». Чтобы программистам было понятнее: «не (большой кусок грязи (big ball of mud))». :-)