Менеджер проекта решил возвращать с округлением.
Обычно округление и форматирование значений с плавающей запятой требуется для отображений в графическом интерфейсе пользователя.
Если вашему менеджеру необходимо именно это, то никакие изменения в класс
Balanceвносить не нужно, т.к. этот класс является бизнес-сущностью и соответственно реализован в бизнес-слое, а логику отображения необходимо править в слое отображения.
Например, вы используете паттерн
Model-ViewModel-View, то эту задачу должен решать класс
ViewModel. Если используете паттерн
Model-View-Presenter или
Model-View-Controller, то соответственно задачу решает
Presenter и
Controller.
Если речь об этом, то в принципе разговор здесь можно закончить, но если это необходимо для решения бизнес-задач, то давайте разберемся по порядку.
1) Добавить округление в с существующий метод getBalance, запустить тесты на getBalance и через 5 мин пойти пить кофе.
На вашем месте я бы сделал именно это, если речь идет не об отображении данных.
2) Добавить в Класс Balance новый метод getAdvancedBalance c округлением а текущий метод не трогать тк у нас банки если что то сломается будет не приятно
Вот здесь очень большую неразбериху в код внесете, у клиента получается два вида баланса что ли? Так какой из них вызывать чтобы узнать баланс? Если вы хотите первый метод оставить, значит он вам нужен... Вообщем нет..
3) Сделать новый класс AdvancedBalance унаследовать от Balance и переопределить метод getBalance, отрефакторить весь проект на использование AdvancedBalance:getBalance вместо Balance:getBalance и молится что ничего не сломалось хоть тесты и есть, но банк и если у когото олигарха что то не то отобразится вам мало не покажется
Можно так делать, но не нужно в вашем случае. Особенно не очень хорошо, как вы сказали чтобы отрефакторить весь проект и произвести замену класса Balance на AdvancedBalance. Вам необходим выполнить маленькую простую задачу, а изменений в этом случае придется сделать очень много, а это большой риск для внесения ошибок.
Вообще для таких решений код проектируют таким образом: класс Balance объявляют абстрактным и у него определяют статический фабричный метод
var balance = Balance.Create(/* агрументы */). Ну и соответственно в зависимости от значений входящих аргументов, вам вернется правильный наследник. Если вы захотите добавить нового наследника, например AdvancedBalance, то внесете изменения только в метод Create. Вот здесь наверное будет соблюден принцип открытости/закрытости.
4) Сделать новый класс AdvancedBalance унаследовать от Balance и создать новый метод getAdvancedBalance, отрефакторить
и снова молится.
Если вы так сделаете, то нарушите принцип Барбары Лисков.
Сложный
