Классы, которых следует избегать (код завершен)

Question

Я несколько смущен о абзаце в полной книге кода.

В разделе «Классы, чтобы избежать» гласит:.

«Избегайте классов с именем после глаголов класса, который имеет только поведение, но нет данных, как правило, на самом деле не класс Рассмотрим поворота класс как DatabaseInitialization() или StringBuilder() в подпрограмму в каком-то другом классе «

Мой код в основном состоит из классов глаголов без данных. Есть invoicereaders, pricecalculators, messagebuilders и т. Д. Я делаю это, чтобы сосредоточить классы на одной задаче каждый. Затем я добавляю зависимости к другим классам для других функций.

Если я понимаю, этот пункт правильно, я должен использовать код, как

class Webservice : IInvoiceReader, IArticleReader { 
    public IList<Invoice> GetInvoices(); 
    public IList<Article> GetArticles(); 
} 

вместо

class InvoiceReader : IInvoiceReader { 
    public InvoiceReader(IDataProvider dataProvider); 
    public IList<Invoice> GetInvoices(); 
} 

class ArticleReader : IArticleReader { 
    public ArticleReader(IDataProvider dataProvider); 
    public IList<Article> GetArticles(); 
} 

Изменить Спасибо за все ответы.

Мое заключение состоит в том, что мой текущий код больше SRP, чем OO, но он также страдает от «модели анемичного домена».

Я уверен, что эти идеи помогут мне в будущем.

Answer 1

Названия классов, такие как InvoiceReader, PriceCalculator, MessageBuilder, ArticleReader, InvoiceReader, на самом деле не являются именами глаголов. Они действительно являются именами имен существительных-существительных-существительных. См. agent nouns.

Имя класса глагола было бы чем-то вроде Validate, Operate, Manage и т. Д. Очевидно, что они лучше используются в качестве методов и будут довольно неудобными в качестве имен классов.

Самая большая проблема с именами классов «существительное-существительное» заключается в том, что они могут дать очень мало смысла в отношении того, что действительно делает класс (например, UserManager, DataProcessor и т. Д.). В результате они с большей вероятностью раздуваются и теряют внутреннюю сплоченность. (См. Single Responsibility Principle).

Поэтому класс WebService с интерфейсами IInvoiceReader и IArticleReader, вероятно, является более четким и содержательным дизайном OO.

Это дает вам простое, очевидное имя существительного «WebService», наряду с именами интерфейса «существительное-существительное», которые четко рекламируют, что класс WebService может сделать для вызывающих.

Возможно, вы также можете придать больше смысла фактическому классу, добавив другое существительное, например PaymentWebService.

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

Answer 2

Фокус меньше на имя. Правило о названии - это просто индикатор правила для плохой практики. Важный момент заключается в следующем:

Класс, который имеет только поведение, но нет данных, как правило, на самом деле не класс

В вашем случае, это выглядит, как если бы ваши классы как данные, так и поведение, и что их также можно назвать «Счет-фактура» и «Статья».

Answer 3

Это зависит. Многие классы существуют с именем после чтения и написания глаголов, потому что классы также создают, поддерживают и представляют соединение с источником данных, который они читают или пишут. Если ваши классы это делают, вероятно, лучше оставить их отдельными.

Если объекты Reader просто содержат логическую синтаксическую разборку, то поворот классов в методы утилиты - это путь. Однако я бы назвал более подробное имя, чем Webservice.

Answer 4

В сущности, речь идет о том, что OO-проект касается извлечения объектов (существительных) и определения операций (глаголов), которые происходят на этих объектах и ​​между ними.

Существительные становятся объектами, глаголы становятся методами, которые действуют на этих объектах.

Идея заключается в том, что

ближе программа моделирует реальный мир проблема, тем лучше программа будет.

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

В случае InvoiceReader класса

• вы только собираетесь создать один экземпляр
• единственное состояние, которое он представляет, что из содержащий DataProvider
• содержит только один метод

нецелесообразно размещать его в объекте.

Answer 5

Я думаю, что книга предлагает дизайн, как следующее:

class Article : IIArticleReader 
{ 
    // Article data... 

    public IList<Article> GetArticles(); 
} 

Answer 6

Я игнорировать это «правило», лично. .NET Framework сама полна "глагол" классы: TextReader, BinaryWriter, XmlSerializer, CodeGenerator, StringEnumerator, HttpListener, TraceListener, ConfigurationManager, TypeConverter, RoleProvider ... если вы считаете, что рамочный плохо разработаны, а затем всеми средствами, не используйте имена, подобные этим.

Цель Стива понятна. Если вы обнаружите, что десятки классов создаете десятки классов только для выполнения конкретной задачи, это, скорее всего, признак anemic domain model, где объекты, которые должны, могут сделать это сами по себе. Но в какой-то момент вам нужно сделать выбор между «чистым» ООП и SRP.

Мое предложение было бы так: если вы обнаружите, что создаете класс «глагол», который действует на одном классе «существительное», честно подумайте о том, может ли класс «существительное» выполнять действие самостоятельно. Но не начинайте создавать God Objects или придумывайте бессмысленные/вводящие в заблуждение имена с единственной целью - избегать глагольного класса.

Answer 7

Обратите внимание на использование слова «Избегайте». Это не устранить, не искоренить или не сжечь в аду, если вы когда-нибудь их используете.

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

Однако существует ситуация, когда создание классов для реализации действия - это хорошая вещь, например, когда у вас разные стратегии для одного и того же действия. Очень хорошим примером является IComparer <>. Все, что он делает, это сравнить две вещи, но есть несколько способов сравнения вещей.

Как автор предложил в таких случаях хороший способ сделать это путем создания интерфейса и его реализации. IComparer <> снова приходит на ум.

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

Answer 8

Не следуйте советам вслепую. Это всего лишь рекомендации.

Это говорит, Существительные делают очень хорошие имена классов, если они моделируют логические объекты. Поскольку класс «Личность» является планом для всех объектов «Человек», вызов его «Лицо» очень удобен, потому что он позволяет вам рассуждать так: «Я создам Лица из ввода пользователя, но сначала мне нужно для его проверки ... »

Answer 9

Заявление Класс, который имеет только поведение, но не содержит данных, как правило, не является классом. - это просто неправильно.

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

Кроме того, классы без гражданства отлично подходят для расчетов, которые вам нужны только на короткий период времени. Вы создаете экземпляр (или запрашиваете фабрику, чтобы получить их), делайте необходимые вычисления и затем бросайте их в мусор. Вы можете иметь соответствующую «версию» вашего поведения в любом месте и в любое время.

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

Например:

public interface IExporter 
{ 
    /// <summary> 
    /// Transforms the specified export data into a text stream. 
    /// </summary> 
    /// <param name="exportData">The export data.</param> 
    /// <param name="outputFile">The output file.</param> 
    void Transform(IExportData exportData, string outputFile); 
} 

может быть реализован как

class TabDelimitedExporter : IExporter { ... } 
class CsvExporter : IExporter { ... } 
class ExcelExporter : IExporter { ... } 

Для осуществления экспорта из IExportData (независимо от того, что может быть) в файл CSV, вы, вероятно, не нужны состояние вообще. С другой стороны, ExcelExporter может иметь различные свойства для опций экспорта, но также может быть апатридом.

[Редактировать]

Перемещение GetInvoices и GetArticles в WebService класса означает, что вы будете связывать их реализацию к типу WebService. Наличие их в отдельных классах позволит вам иметь разные реализации как для счетов-фактур, так и для статей. В целом, кажется, лучше иметь их отдельно.

Answer 10

Вот классический взять на себя «глагол против существительного» в ОО:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html