Charles WeylandПреимущество древнего подхода путём простого перебора всей коллекции в том, что при нахождении элемента я знаю, не только этот элемент, но и его местонахождение в массиве




Представляешь!?

Monochromatique,

оу, ты уже написал )

skyANAОдин нарушил SRP, другой его подхватил, а сколько скопипастят? :)

А где здесь нарушение SRP?

skyANAУчитель пересчитывает себе зарплату.

А я думал, что времена наивного восприятия ООП: описание объекта и есть объект, уже прошли. Учитель это человек. А Teacher это класс.

Так и не понял, где тут нарушается SRP, и какое отношения семантика имеет к принципу SRP.


skyANAНу и OCP до кучи нарушается :)

А тут вообще непонятно. Где нарушается?

Monochromatique,

Если говорить об паталогическом SRP, класс Teacher вовсе не обязательно должен содержать логику расчёта зарплаты. Но это не мешает ему предоставлять метод вычисления ЗП, это отлично ложится в концепцию DDD и ничего не нарушает.

ЕвгенийВчто есть SRP?

Принцип такой. Каждый должен заниматься своим делом и не лезть в чужие дела. Как-то так.

MonochromatiqueДа мне решительно фиолетово; я на вопрос Charles Weyland отвечал. Про LINQ; думал, что зарплаты учителей в другом форуме обсуждаются)))))))))

Здесь всё обсуждается, и зарплаты учителей тоже. Кстати, ты тоже считаешь, что учителя должны податься в бизнес, если их не устраивают ЗП?

skyANAhVosttЕсли говорить об паталогическом SRP, класс Teacher вовсе не обязательно должен содержать логику расчёта зарплаты. Но это не мешает ему предоставлять метод вычисления ЗП, это отлично ложится в концепцию DDD и ничего не нарушает.
В мемориз! Фраза для защиты говнокода на ревью :)

Бред какой-то несёшь. Если бы мог, ты бы конечно пояснил, но видимо агрументов у тебя по нулям.

Сон Веры ПавловныCharles Weyland,

Ну прочитатйте уже наконец Рихтера, и узнайте о том, как структуры изменяются через boxing/unboxing+интерфейсы.

Ёжики плакали.

skyANAА что тут пояснять? Фраза мне твоя понравилась :)

С чем не согласен?

skyANAДля начала приведи базовые концепции DDD, а то ведь концепцию единого языка действительно не нарушить тем, что метод пересчёта зп в классе Teacher :)

Я так и не услышал с чем конкретно ты не согласен. Чем тебе публичный метод пересчёта ЗП, предоставляемый классом Teacher не угодил? Я уже сказал, что реализация этого расчёта может быть (и по сути должна бы) инкапсулирована в отдельном классе. В чём проблему ты видишь?

skyANAЯ же чёрным по белому написал: нарушает SRP и OCP :)

Ну я так не считаю, и пояснил свою мысль. Почему у тебя чего-то там нарушает, видимо у тебя сугубо своё понимание принципов.

skyANAНе думаю. Какбы я в команде работаю с самого начала своей карьеры и принципы эти не с одним специалистом обсуждал.

Ясно, закрытая секретная информация для узкого круга специалистов

skyANAЕсли ты про S.O.L.I.D., то очень уж широк тот узкий круг :) Печально, что ты не в нём.

Свидетели Иеговы SOLID детектед. Принципы хорошие и при правильном, не слепом применении полезные.

Но когда начинается упоротый бред в виде «учитель не должен считать себе зарплату», становится ясно, что тут уже попахивает дешёвой религией, а не инженерными принципами.

Сон Веры ПавловныНастолько, надо сказать, широк, и с таким широким спектром мнений, что само понятие SOLID сейчас приобрело все черты схоластики.

В некоторых кругах это приобрело все черты религии. Сейчас уже есть все шансы, во время собеседования, на замечание, что слепое следование SOLID может быть вредным, получить в ответ обиженное «всё понятно, спасибо, мы вам перезвоним».

skyANAНачнём с того, что не считать, а пересчитывать. В реальности учителя самостоятельно не пересчитывают себе зарплату :)

Ну так и давай начнём прежде всего с того, что класс Teacher не учитель :) Ведь слово не воробей, и вообще не птица! А если уж обобщать, то учитель это сотрудник, а отдельные сотрудники именно этим и занимаются — пересчитывают зарплату, и себе и другим. В общем тут на лицо, не верный постулат, от которого исходят неверные выводы.

skyANAСчитать какая у них зарплата, они могут хоть каждый день, teacher.RecalculateSalary(2) выглядит как учитель сам себе поднял оклад в два раза.
Ты конечно можешь считать это объективной реальностью, но вот лично я такого не видел :)

Почему Teacher не может предоставлять интерфейс для любых операций, которые касаются объект физического мира, который он представляет? В том числе, пересчёт зарплаты. И уж что-что, а говорить, что дескать учитель может пересчитать себе зарпату, это значит признать, что объект класса сам живёт своей жизнью, сам вызывает свои методы когда ему вздумается. Бред, не правда ли? Пересчитывает зарплату тот, кто вызывает метод RecalculateSalary , смотри где расположен этот вызов и тебе сразу станет ясен виновник.

skyANAПотом надо отметить, что S.O.L.I.D. - это про проектирование классов. И я уверен, что изначально класс Teacher был придуман ТС вполне для определённых задач никак не связанных с пересчётом оклада.

Если речь идёт исключительно про твою уверенность, то спорить сложно. А с точки зрения проектирования, я проблемы не вижу. Касательно сопровождения, чем ближе расположен код реализации к использованию, тем удобнее, проще и вообще это тру гуд. Можно спроектировать всё так, что расчёт/пересчёт зарплаты будет расположен вообще отдельно и независимо. Но часто бывает необходимость запихать всё в фасад, чтобы всё было под рукой, особенно если в команде существует группа прикладных программистов, которые пишут непосредственно бизнес.


skyANAТакже мне категорически не нравится тут 19695513 то, что состояние объекта изменяется в момент запроса этого объекта из хранилища.

Тут согласен на все 100.


skyANAЧто касается нарушения OCP... Глядя на этот код: teacher.RecalculateSalary(2) , - у меня складывается впечатление, что предусмотрен только один метод пересчёта оклада, а именно увеличение оклада в N раз.
А в жизни оклады пересматриваются после окончания испытательного срока, при повышении, при понижении, при смене должности, при смене ставки.

Я думаю, что приводится упрощённый пример в вакууме. Конечно в реале, одного метода явно будет недостаточно. Возможно, Teacher мог бы возвращать объект управления его зарплатой. Или наоборот, принимать стратегию, или это вообще может быть отдельный слой, который можно заменить.


skyANAВ терминах проектирования - это означает, что есть разные стратегии пересчёта оклада. И на мой взгляд метод RecalculateSalary должен принимать не число, а именно стратегию, или некий объект, её описывающую.
Тогда класс, где сей метод будет реализован, действительно будет открыт для расширения, но закрыты для изменения.

Ну это же вообще может быть фасад, не содержащий ни грамма логики.

А вообще, спасибо за детальные разъяснения своей позиции, наконец дождался

skyANAЧто за круги такие? :)

Красные, под глазами