Структура классов для системы управления запасами

Question

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

а. Компания может иметь различные типы элементов, такие как документы (как электронные, так и физические), компьютеры и т. Д., Которые могут также иметь свои собственные подтипы.

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

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

Что такое хорошая (ые) структура (ы) классов, которые можно использовать для моделирования такого рода трекинга? (псевдо-структура класса C # или c ++ были бы полезны) и какие шаблоны проектирования были бы хороши для такой задачи

Answer 1

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

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

Например, если вы создаетеКласс DocumentType в коде, ваши пользователи будут создавать его несколько раз, создавая объекты, такие как Report, Memo или Manual.Затем каждый отдельный отчет, которым управляет ваша система, будет экземпляром Report.И каждая отдельная записка будет экземпляром памятки.И т. Д.

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

Этоочень весело, хотя!

Answer 2

Вот предварительное предложение для начала:

struct Item
{
    // The requirements say everything is an item.
};

struct Document
: public Item
{
    // There are documents
};

struct Document_Physical
: public Document
{
    // Physical documents
};

struct Document_Electronic
: public Document
{
    // Electronic documents
};

struct Computer
: public Item
{
};

Содержание предметов и их методы зависят от толкования документа с требованиями. Это одна схема, могут быть и другие.

Некоторые полезные шаблоны проектирования: Visitor, Factory, Producer-Consumer и многие другие. Также исследуйте тему "рефакторинг".