Набор как метафора для контейнеров реального мира
Я нахожу моделирующие физические контейнеры с помощью очень интуитивных наборов. Я переопределяю/делегирую, добавляют методы с добавленными полными ограничениями на основе физических атрибутов, таких как объем добавленных элементов, вида на основе физических атрибутов, определяют местоположение элементов при помощи карт положения к элементу и так далее.
Однако, когда я прочитал документацию классов набора, я получаю впечатление, что это не надлежащее использование, что это - просто математическая конструкция, и ограниченная очередь просто предназначена, чтобы быть ограниченной числом элементов и т.д.
Действительно я думаю, что я, если я не могу смоделировать этот набор когерентно, я не должен, возможно, выставлять этот класс как набор, но только делегировать к нему внутренне. Мнения?
3 ответа
Не совсем уверен, что правильно вас понял. Я так понимаю, вы хотите знать, следует ли вам предоставлять коллекцию (создание подклассов) или обертывать ее (иметь частное поле). Как говорит Роберт, это действительно зависит от случая. Это в значительной степени ваш выбор. Тем не менее, я бы сказал, что во многих случаях лучше не раскрывать коллекцию, потому что ограничения определяют объект, который вы моделируете, и не полностью соответствуют базовой коллекции. Вкратце: пользователям вашего объекта не нужно знать, что они имеют дело с коллекцией, если только она не на самом деле коллекция с какой-то специализацией, например. имеет все свойства коллекции, но допускает только определенное количество объектов.
Многие структуры в разработке программного обеспечения не имеют физического аналога. Фактически, некоторые структуры и алгоритмы довольно абстрактны и не моделируют объекты непосредственно в физическом мире. Поэтому то, что объект не служит подходящей моделью для физических объектов в реальном мире, не обязательно означает, что его нельзя эффективно использовать для решения проблем в компьютерной программе.
Действительно, я думаю, что пока я не смогу связно смоделировать эту коллекцию, мне, возможно, не следует раскрывать этот класс как коллекцию, а только делегировать ему внутренние функции. Мнения?
Во-первых, не стоит слишком зацикливаться на моделировании в программной инженерии. Модели в стиле UML (обычно) служат в первую очередь как способ организации и выражения высокоуровневых идей разработчика о том, как должно быть реализовано приложение. Нет необходимости в строгой связи один к одному между классами в модели и классами реализации в коде приложения.
Во-вторых, не стоит слишком зацикливаться на моделировании объектов "реального мира" (т.е. физических) и их поведения. Большинство "объектов", которые используются в типичных приложениях, не имеют реальной связи с реальным миром. Например, "папка" или "каталог" на самом деле не более чем аналогия физических объектов с теми же именами. Как правило, нет необходимости в том, чтобы компьютерная концепция была ограничена физическим поведением объектов реального мира.
Наконец, существует ряд причин в области программной инженерии, по которым плохой идеей является расширение стандартных типов коллекций классами домена Java. Например:
Коллекции имеют общее поведение, которое обычно не следует отображать в доменном объекте. Например, обычно вы не хотите, чтобы компоненты доменного объекта добавлялись и удалялись произвольно.
Расширяя тип коллекции, вы неявно даете разрешение некоторой части вашего приложения рассматривать доменные объекты как просто списки, наборы или что-то еще.
Расширяя классы коллекций, вы будете жестко привязывать детали реализации к API вашего домена. Например, вам придется выбирать между расширением
ArrayListиLinkedList, и изменение вашего решения приведет (как минимум) к бинарной несовместимости API... а возможно, и к худшему.