Абстрактный дизайн / вопрос моделей

Question

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

Код стал действительно раздутым и запутанным, когда я начал добавлять условия для управления алгоритмом построения, поэтому я решил разделить алгоритм на класс "Builder", который, по сути, получает свойства объекта, решает, что нужно будет сделано, а затем применяет изменения к объекту.

Преимущество отдельного алгоритма компоновщика состоит в том, что я могу обернуть / украсить его или полностью переопределить. Самому объекту не нужно беспокоиться о том, как он построен, он просто создает builder и «украшает» builder дополнительными функциями, необходимыми для выполнения работы.

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

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

Я знаю, что объекты должны заботиться о себе, и в идеальном мире мой объект (дом) будет строиться сам, но я рефакторину только часть этого объекта build, и мне нужен способ применить алгоритмы построения динамически, и я ненавижу открывать свои объекты с помощью геттеров и сеттеров только ради Builder.

Я должен отметить, что я работаю в Obj-C ++, поэтому мне не хватает friend классов или внутренних классов. Если бы объяснение было слишком абстрактным, я был бы рад уточнить кое-что более конкретное. В основном просто ищу идеи или советы о том, что делать в такой ситуации.

Приветствия, ребята, Sam

РЕДАКТИРОВАТЬ: это хороший способ объявить

interface House(StuffTheBuilderNeedsAccessTo)

категория внутри Builder.h? Таким образом, я полагаю, что могу объявить свойства, которые нужны строителю, и поместить синтезаторы в House.mm Никто не будет иметь доступ к свойствам, если они не включают заголовок Builder ....

Это все, что я могу придумать!

Answer 1

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

Answer 2

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

Но основная проблема все еще существует; у застройщика должен быть доступ к свойствам объекта, который он строит.

Answer 3

Я бы предложил использовать шаблон Factory для построения объекта.
Вы можете искать "Фабрика" на SO, и вы получите нет. вопросов, связанных с этим.

Также см. Шаблон Builder .

Answer 4

Я не знаю Obj-C ++, поэтому я не знаю, возможно ли это, но это звучит как проблема для Категории . Предоставьте только необходимые методы вашему house в объявлении самого house, создайте категорию, которая содержит все частные методы, которые вы хотите скрыть.

Answer 5

А как же наоборот, используя множественное наследование, поэтому ваш класс также является Builder? Это будет означать, что основная масса алгоритмов может быть в базовом классе и расширена, чтобы соответствовать потребностям вашего конкретного Хауса. Это не очень красиво, но оно должно позволить вам абстрагировать большую часть функциональности.