Признак хорошего тона — не делать ничего в конструкторе кроме того, что необходимо. А все, что необходимо, — это проверять предоставленные аргументы, а затем присваивать их в качестве значения для свойств сервиса.
Короче говоря, всегда избегайте создания методов-запросов, которые будут раскрывать внутренние данные объекта: • Создавайте эффективные методы, адаптируйтесь к потребностям клиентов. • Переместите вызов метода в объект, это позволит объекту самому решать, что делать.
Метод-модификатор — это командный метод или метод-запрос? Метод-модификатор не возвращает информацию. Он возвращает копию всего объекта, и после получения этой копии уже нельзя запросить о ней информацию, поэтому методы-модификаторы не являются методами-запросами. Но они также и не похожи на традиционные командные методы. Появление командного метода у неизменяемого объекта подразумевает изменение состояния объекта, чего быть не должно. И метод-модификатор создает новый объект, что напоминает метод-запрос.
Если бы Counter был реализован как неизменяемый объект, то метод increment() был бы методом-модификатором, а его имя было бы более декларативным и звучало бы как incremented().
Соблюдайте правило: метод должен быть либо командным, либо запросом. Это правило называют принципом разделения методов-команд и методов-запросов (command/query separation principle — CQS)7. Мы уже применяли его в начальной реализации объекта Counter (листинг 6.1): метод increment() был командным, а currentCount() — методом-запросом, и ни один не был одновременно командой и запросом.