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Что за круги такие? :)

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

skyANAИ кого же описывает класс Teacher, если не учителя? Особенно в свете того, что ТС пилит программу для облегчения проведения соревнований в определённой школе? :)

В этом свете следование SOLID вообще бессмысленно

skyANAДа суть не в SOLID :) А в том, что на форуме надо постить грамотный код, чтобы юные падаваны в проекты свои не тащили шлак всякий.

Ну да..