@tym32167 чем проще-то тестирование станет? Если кода стало больше, а следовательно увеличилась кодовая база проекта и его сложность(работали с одним классом, теперь нужно учитывать интерфейс и 4 класса, а может и больше в будущем). Так же снизилась удобочитаемость, появились дополнительные сущности. То, что ты предлагаешь - это скорее процедурный стиль, нежели ООП. Принцип инкапсуляции нарушен.

и это не один и тот же алгоритм, для одинаковых алгоритмов с разными типами данных используют дженерики, а здесь они не помогут. Это 4 разные задачи, которые относятся к одной сущности.

ну вот допустим вычисление упало, ок: смотрим к каком классе, в каком методе, в каком подметоде и оказываемся ровно в такой же, по объёму, области видимости в которой произошла ошибка хоть в одном классе, хоть в 4х. И уже в этой области(в конкретном методе) мы ищем баг. Если стоит условие, что методы расчёта будут добавляться, а вот класс Integral менять будет нельзя, то тогда метод Calculate должен принимать делегат, но это исходя из ситуации и точно не для лабораторки - ибо усложнять, это нарушение принципов KISS и YAGNI

тяп ляп - это как раз раздувание кода. Гибкость определяется задачей, чрезмерная гибкость - признак "умного кода", который нужен только для того, чтобы показать какой умный автор этого кода и больше ничего. Создавать класс на каждый метод - это не ООП, т.к. нарушается принцип инкапсуляции и SRP(SOLID). Если ТЗ изменилось и нужно добавить ещё один метод, то изменять классы - это не всегда нарушение OCP(SOLID).

Теперь понятно, откуда ветер дует)) "Чистый код" Роберта Мартина - это та штука, которая противоречит сама себе от издания к изданию. И это не пилюля от всех проблем. Роберт Мартин может и 4 действия калькулятора на тысячу строк написать, соблюдая все свои "каноны". Кто-то вообще отвергает его теорию. Про это лучше почитать на хабре: habr.com/ru/post/508876

Ок, забыли про SOLID. Ну нас ООП. В вашем решении идёт целенаправленное нарушение принципа инкапсуляции в угоду спорного облегчения труда тестировщика.

@tym32167 Ещё одно распространённое заблуждение, что инкапсуляция - это только сокрытие. Инкапсуляция в ООП - это и сокрытие и объединение атрибутов и методов класса. От слова капсула. Капсула и защищает от внешнего мира и хранит внутри себя всё содержимое. А если разбросать всё по классам, то объединение нарушается. На заре ООП не было модификаторов доступа, а вот инкапсуляция была всегда. Как так?)

ох, почитал я этот ответ. Это же нужно так интересно понимать ООП. Для проверки гипотез просто представьте, что нужно сделать ещё один алгоритм расчёта. В Вашем случае нужно будет добавить ещё один метод, расширить енум и добавить обработку этого энума в Calculate. Также, тем, кто использует это все, нужно будет знать о том, что класс поменялся (спорно, но нужно). В случае, если один класс заведует одним методом расчета + интерфейс - добавили новый класс, нужном месте создали его и все. все. шанс сделать ошибку и подсунуть не тот енум - минимальный (енума нет).

@KoVadim ладно, допусти нам нужно добавить ещё один способ расчёта. Добавляем в Enum ещё одну строчку - старый код не ломается, добавляем новый закрытый метод в класс Integral - старый код не ломается, добавляем обработчик нового Enum в метод Calculate - старый код не ломается. Не вижу проблем, одни плюсы от инкапсуляции.

ломается. ещё как. Добавили новый енум, а остальной код пока нет. И если кто то будет использовать новый енум - упс, а что возвратит Calculate ? none? исключение? Такого не может быть в реальной жизни? может. может. Например, решили удалить какой то старый код расчета и все - нужно по всему коду вычищать.

@KoVadim обычно все доработки(Enum, Calculate и новый метод) идут в одном релизе после кодревью и тестирования. Никто(в здравом уме или серьёзной организации) не будет сначала Enum расширять, а потом.....когда-нибудь.... допиливать всё остальное. Есть ТЗ: добавить новый метод расчёта - это будет сделано одним накатом, комплексно.

да, в идеальном мире это хорошо. Но в реальности - тут бывает по разному. Вполне могут быть случаи, когда один добавляет новый метод, а другой - убирает. и потом это дело мержат... да... Но пока есть такие программисты, которые делают вот так через пень-колоду, у меня будет работа и к хлебушку:)

@KoVadim вы сводите обсуждение к не совершенной модели управления проектом, мы же обсуждаем правильность с точки зрения ООП. Неопытных менеджеров проекта и слабых тестировщиков лучше оставить за скобками этого обсуждения. Коллега задал вопрос, я предложил вариант. Кстати мы и командную разработку не обсуждаем, автор вопроса, скорее всего, лично разрабатывает свою лабораторку.

я понял. когда у Вас окончились аргументы, то Вы решили, что я просто тему перевожу.

@KoVadim Какие аргументы нужны, если никто не может сказать, почему нарушение инкапсуляции - это хорошо? Вы начинаете отвлекаться на какие-то гипотетические ситуации, в которых кто-то создаст Enum, а кто-то другой забудет реализовать метод. Другой коллега переживает за тестировщиков больше, чем за разработку. Вопрос по ООП - давайте обсуждать ООП, не отвлекаясь на Ваш "хлебушек", менеджеров, тестировщиков и программистов которые делают "через пень-колоду"?

давайте так, Ваш способ с енумами - это не совсем ООП. И он нарушает SOLID. Прям начиная с первой буквы. А ситуации не гипотетические.

Енум - это просто удобный сахар для ограничения возможных вариантов, он играет последнюю роль в моём решении. Без объяснений минусов моего подхода - это просто слова. Предлагаю не стесняться и публиковать своё решение. А коллеги посмотрят на все точки зрения и проголосуют. И ещё раз, мы обсуждаем ООП, а не прод в Энтерпрайз и не то, как у вас привыкли делать, просьба учесть..