Коллекция как метафора для контейнеров реального мира

Question

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

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

Действительно, я думаю, что если я не смогу смоделировать эту коллекцию согласованно, я, возможно, не должен представлять этот класс как коллекцию, а только делегировать ее внутри. Мнения?

Answer 1

Не совсем уверен, что я вас правильно понял. Я понимаю, что вы хотите знать, следует ли выставлять коллекцию (подклассирование) или обертывать ее (иметь личное поле). Как говорит Роберт, это действительно зависит от дела. Это в значительной степени ваш выбор. Тем не менее, я бы сказал, что во многих случаях лучшим выбором является не выставлять коллекцию, потому что ограничения определяют объект, который вы моделируете, и не полностью сопоставимы с базовым набором. Короче: пользователям вашего объекта не нужно знать, что они имеют дело с коллекцией, если это не действительно коллекция с некоторой специальностью, например. имеет все свойства коллекции, но допускает только определенное количество объектов.

Answer 2

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

Answer 3

Действительно, я думаю, что если я не смогу смоделировать эту коллекцию согласованно, я должен, возможно, не выставлять этот класс как коллекцию, а только делегировать ее внутренне. Мнения?

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

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

И, наконец, существует ряд причин, по которым требуется разработка программного обеспечения, потому что это плохая идея, чтобы ваши классы домена Java расширяли стандартные типы коллекций. Например:

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

• Расширяя тип коллекции, вы неявно разрешаете какой-либо части вашего приложения обрабатывать объекты домена как только списков или наборов или что-то еще.

• Расширяя классы коллекций, вы были бы подробными сведениями о сложной проводке в своих API-интерфейсах домена. Например, вам нужно будет решить, между расширением ArrayList или LinkedList, и изменение вашего ума приведет (по крайней мере) к несовместимости двоичного API ... и, возможно, к худшему.