Ограничение входов конструктором при минимальном содержании кода конструктора

Question

Ну, мне сказали, что я должен создать класс денег, который принимает валюту и стоимость. Значение должно храниться в виде 2 целых чисел, одно из которых представляет значение в долларах, а другое - в центах.

* Он должен принимать десятичное значение с точностью до двух (2) десятичных знаков. *

Так что я полагаю, что мне нужно ограничить значение в центах, чтобы оно могло принимать только однозначные целые числа. Теперь моя проблема в том, что мой наставник сказал мне, что делать другие вещи внутри конструктора - плохая практика. Как я могу ограничить ввод, если мне не разрешено ничего делать с конструктором, кроме:

public class Money {
    Currency currency;
    int dollar;
    int cents;

    public Money(Currency currency, int dollar, int cents) {
        super();
        this.currency = currency;
        this.dollar = dollar;
        this.cents = cents;
    }
    ..... other code.....
}

Любые другие идеи о том, как я должен реализовать то, что было от меня указано? Почему это плохая практика и есть ли способ определить ограничения, не будучи виновным в этой плохой практике ???

Answer 1

То, что вы делаете, проверяет входные данные для конструктора. Хотя в целом «другие вещи» в конструкторе не оптимальны, выполнение входного кода проверки, безусловно, оправдано. Примером следующего является шаблон good IMO:

public Money(Currency currency, int dollar, int cents) {
    this.currency = currency;
    this.dollar = dollar;
    // validate that cents is 0 to 99
    if (cents < 0 || cents > 99) {
        throw new IllegalArgumentException("Invalid cents value: " + cents);
    }
    this.cents = cents;
}

Кстати, нет смысла вызывать super() в начале вашего конструктора, если он не расширяет базовый класс.

Answer 2

Прежде всего, я не считаю плохой практикой проверять и выдавать исключение, если вы получаете недопустимый объект с помощью конструктора.Тем не менее, глядя на ваше требование, это может быть достаточно, чтобы округлить центы.Наконец, вы можете посмотреть на другие реализации Money, например this

Answer 3

Я бы бросил ExceptionInInitializerError, если значение центов больше 100. Либо так, либо разделить на 100 и добавить частное к долларам, а остаток к центам.Нормализация и проверка аргументов вашего конструктора - неплохая практика.

Answer 4

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

В вашем случае,простая числовая проверка - это нормально.

Однако, как сказал Марчелло, вы можете рассмотреть возможность написания функций проверки и вызова их из конструктора, чтобы обеспечить согласованность.

Answer 5

Неправильно добавлять код в Конструктор, твой наставник прав.Но добавление вызова метода, это не так.

Таким образом, вы можете просто инкапсулировать операции, которые будут ограничивать ввод в другом методе, и вызывать его сразу после супер.

Но, лучшая практика в моеммнение, это иметь дело с ограничением ввода перед передачей его конструктору.

Разобрать ввод в отдельном классе или в коде за интерфейсным классом.Избегайте использования операции кода в классе, представляющем модель чего-либо, в данном случае, вашу «денежную модель»

Почему это плохая практика?

В объектной ориентации вы должны писать классытак что они не выполняют больше операций, которые они должны знать.В этом случае ваш класс представляет модель объекта, деньги.Зачем модели самостоятельно анализировать значение, передаваемое ее конструктору?Понял ?Лучшая практика - передать значения для конструктора, уже проанализированные и ограниченные, так что классу нужно будет только сохранить эти значения.

Например, допустим, вчера ваши ограничения изменились, все, что у вас было бысделать, это изменить часть анализа, вместо того, чтобы писать код внутри класса Money.

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