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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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