Дизайн (практическое руководство) классов, содержащих наборы других классов

Создание хорошего объектно-ориентированного дизайна - это своего рода искусство , но следует помнить о некоторых принципах.

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

Держите вещи простыми, глупыми. То есть сделайте их простыми с точки зрения звонящих. Это относится к инкапсуляции, при которой вы должны раскрывать внутреннюю часть своей реализации только по мере необходимости. Это применимо к созданию последовательного интерфейса, который легко понять. А это означает, что вам следует избегать ловушки создания объекта для каждого мыслимого класса, создания множества атрибутов и максимально возможного обобщения.Последний пункт особенно важен; Что делает нас хорошими разработчиками, так это то, что мы способны рассуждать и абстрагироваться, но из-за этого мы часто попадаем в ловушку, делая системы намного сложнее, чем они должны быть.

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

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

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

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

WorkSpace имеет тип Project + Project ^ 2 + Project ^ 3 ... (то есть все, что true из списка проектов, равно true рабочего пространства)

Аналогично,

Проект имеет тип Ресурс + Ресурс ^ 2 + Ресурс ^ 3 ...

Ресурс имеет тип Файл + Файл ^ 2 + Файл ^ 3 ...

Итак, в таком языке, как C # †, вы можете определить свой класс WorkSpace следующим образом:

public class WorkSpace : IList<Project> //the important thing here is that you're declaring that things that are true for a list of Projects is true for a WorkSpace. The WorkSpace class may in fact do other stuff too...
{

}

и аналогично для других классов.

Затем в своем клиентском коде вы должны использовать это следующим образом:

foreach (var project in WorkSpace)
{
    //do stuff
}

или

Projects.Add(new Resource() { file1, file2, file3, file4, /* etc */});

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

† Из вашей истории публикаций я предполагаю, что вы знакомы с C #, но это применимо к другим языкам.