Это это пример Единственного Принципа Ответственности?
Поля ссылочного типа возвращаются в запросе как объекты типа DocumentReference на всех платформах. Вы можете использовать его так же, как любой DocumentReference, который вы создаете сами. Это означает, что, конечно, вы можете вызвать get () для получения содержимого упомянутого документа.
5 ответов
Мне нравится думать о Единственном Принципе Ответственности как о реализации разделения обязанностей. Прежде чем я начну разделять свои классы, как Вы имеете, я пытаюсь думать о том, за что каждый класс должен быть ответственен.
Ваши классы довольно просты и предоставляют себя хорошо абстрактному классу с реализованным Print() и Save() функции, поскольку Вы упомянули. Я был бы склонен сохранять тот дизайн по Вашему текущему.
Однако, если печать и сохранение были более сложными задачами, которые могли бы быть выполнены по-разному затем специализированное Printer или Saver класс был бы гарантирован, так как та ответственность теперь более сложна. Порог 'сложности' для того, чтобы сделать новый класс очень субъективен и будет зависеть от точной ситуации, но в конце, код является просто абстракцией для нас непритязательные люди для понимания, поэтому сделайте это таким образом, что это является самым интуитивным.
Вы Container класс немного вводит в заблуждение. Это ничего на самом деле 'не содержит'. Это на самом деле реализует Шаблон "фабричный метод" и извлекло бы выгоду из того, чтобы быть названным фабрикой.
Кроме того, Ваш PersonDisplayer никогда не инстанцируется и может обеспечить всю его функциональность через статические методы, итак, почему бы не сделать это статическим классом? Служебным классам, таким как Принтеры или средства сохранения весьма свойственно быть статичным. Если у Вас нет потребности иметь отдельные экземпляры принтера с различными свойствами, сохраните это статичным.
Я думаю, что Вы на правильном пути. Я не совсем уверен в Контейнерном классе все же. Я обычно придерживался бы простого решения просто использования "нового" для этих объектов, если у Вас нет некоторой управляемой бизнесом потребности в том интерфейсе. (Я не считаю "аккуратными", чтобы быть бизнес-требованием в этом смысле),
Но разделение того, "чтобы быть" клиентской ответственностью от "отображения клиента" хорошо. Палка с этим, это - хорошая интерпретация ТВЕРДЫХ принципов.
Лично я теперь полностью остановился, использовал любой вид статических методов в этом виде кода, и я полагаюсь на DI для получения всех правильных объектов службы в правильном месте и время. После того как Вы начинаете уточнять далее ТВЕРДЫЕ принципы, Вы найдете создание намного большего количества классов. Попытайтесь работать над теми соглашениями о присвоении имен остаться последовательными.
Ну, я никогда не слышал об этом 'единственном принципе ответственности' прежде, но что кажется мне что, что Вы делаете при наличии этих CustomerPrinter, классы класса и CustomerSaver просто преобразовывают классы назад в структуры и de-object-orienting все.
Например, это означало бы, что различным клиентским типам были бы нужны различные случаи в классе CustomerPrinter, если бы они должны были быть распечатаны по-другому. Но насколько я понимаю, одна из точки организации OO, и использования деревьев наследования и всего этого, должна покончить с потребностью этого CustomerPrinter знать, как распечатать все: Клиенты знают, как распечатать себя.
Я не верю в следующем этим парадигмам твердо в любом случае. Например, я не уверен, что различие между Интерфейсом и Абстрактным классом находится в Вашем случае. Но с другой стороны я - программист на C++ не программист C#...
Несколько примечаний:
- Вообще говоря, SRP является всей пользой, как разделение форматирования дисплея от данных.
- Рассмотрение дисплея и т.д. Я думал бы с точки зрения сервисов, т.е. PersonDisplayer является единственным, не сохраняющим состояние и предлагает строковый Дисплей (IPerson) функция. По моему скромному мнению, специальная обертка класса только для обеспечения дисплея не обеспечивает преимущества.
- Однако при использовании привязки данных для wpf у Вас мог бы быть класс DisplayablePerson, который распространил бы PropertyChanged если измененный Человек. Вы поместили бы объекты DisplayablePerson в ObservableCollection и служили бы ему в качестве ItemsSource некоторого управления списком.
То, для чего Вы нуждаетесь в Контейнере, является им только для инстанцирования и конфигурирования экземпляра? Судите затем Клиента customer1 = новый Клиент {FirstName = "Jim", LastName = "Smith"};
На ноте стороны я попробовал объект. Метод <SomeType> (...) вызов несколько раз, поскольку это казалось самым быстрым и простым решением. Однако через какое-то время я всегда сталкивался с проблемами с той и заканчивал с объектом. Метод (Вводят someTypeType...),
Вы могли бы взглянуть на IFormattable и IFormatProvider.
Платформа имеет классы форматирования для поддержки.