Разве информация не Компетентна и Говорит, не Спрашивают противоречащий Единственному Принципу Ответственности?

Question

Разве информация не Компетентна и Говорит, не Спрашивают противоречащий Единственному Принципу Ответственности?

Тернарный, условный; помидор, помидор. Для этого важна переменная инициализация. Если (как и я) вы любите инициализировать переменные, где они определены, условный тернарный оператор (для этого и тот и другой) позволяет вам сделать это в тех случаях, когда существует условность относительно его значения. Особенно примечателен в конечных полях, но полезен и в других местах.

например:

public class Foo {
    final double    value;

    public Foo(boolean positive, double value) {
        this.value = positive ? value : -value;
    }
}

Без этого оператора - по какому-либо имени - вам нужно будет сделать поле не -финал или написать функцию просто для ее инициализации. На самом деле, это неправильно - ее можно инициализировать, используя if / else, по крайней мере, на Java. Но я нахожу этого чище.

24

tell-dont-ask single-responsibility-principle solid-principles oop

задан jaco0646 20 February 2019 в 16:02

3 ответа

Другие вопросы по тегам:

tell-dont-ask single-responsibility-principle solid-principles oop

Похожие вопросы:

score 8 · Answer 1

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

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

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

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

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

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

score 2 · Answer 2

Те классы не противоречат. DTO просто служит кабелепроводом данных из устройства хранения данных, которое предназначается, чтобы использоваться в качестве немого контейнера. Это, конечно, не нарушает SRP.

, С другой стороны, .toDTO метод сомнителен - почему Клиент должен нести эту ответственность? Для пользы "чистоты" у меня был бы другой класс, кто задание, это должно было создать DTOs из бизнес-объектов как Клиент.

не забывают, что эти принципы являются принципами, и когда Вы можете и далеко с простыми решениями, пока изменяющиеся требования не вызывают проблему, затем делают так. Бесполезная сложность - определенно что-то для предотвращения.

я настоятельно рекомендую, BTW, Гибкие Шаблоны Robert C. Martin, Методы и принципы для намного больше подробно обработок этого предмета.

score 5 · Answer 3

Можно говорить о "Tell Don't Ask", когда вы запрашиваете состояние объекта, чтобы сказать объекту сделать что-то.

В вашем первом примере TransferObjectFactory.createFrom просто конвертер. Он не говорит объекту Customer что-то делать после проверки его состояния.

Я думаю, что первый пример правильный.