Как правильно называть такую композицию классов?

Question

[romaro]

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

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

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

Вот абстрактный пример:

internal class Program
{
	static void Main()
	{
		IEngine engine = new Engine("Beep!");
		Factory.SetEngine(engine);
		Factory.DoWork();
	}
	
	/// Всю полезную работу выполняет этот класс, который должен быть создан
	/// на уровне приложения и помещен в статический класс библиотеки
	private sealed class Engine : IEngine
	{
		string _signal;
		internal Engine(string signal)
		{
			_signal = signal;
		}
	
		public void DoWork()
		{
			Console.Write(_signal);
		}
	}
}

// Lib classes

public interface IEngine
{
	void DoWork();
}

public static class Factory
{
	static IEngine _engine;
	
	public static void SetEngine(IEngine engine)
	{
		if (_engine != null)
			throw new Exception("The engine has been already setted");
		
		_engine = engine;
	}
	
	public static void DoWork()
	{
		if (_engine == null)
			throw new Exception("The Factory haven't engine to do this");
		
		_engine.DoWork();
	}
}

Есть ли у такого паттерна устоявшееся название и какие у него могут быть альтернативы?

Answer 1

[MVV]

IMHO это - вариант шаблона "Абстрактная фабрика"
Первая приходящая на ум альтернтатива - та, в которой этот шаблон используется традиционно: реализации наследуются от абстрактного класса фабрики (см. пример для C# в статье по ссылке), а не получаются аггрегированием фактичекой реализации со статическим классом, предостатвляющим интерфейс, как у вас.

Answer 2

[Shavadrius]

Возможно я не совсем правильно вас понял, но вам нужны паттерны "Абстрактная фабрика" и, если не хотите (или не можете) менять классы в UI-библиотеках, паттерн "Декоратор" (Wrapper). В чем суть:
1. Создаете интерфейс IForm, в котором описываете что и как должно создаваться (например, классы CreateForm, DrawForm, RefreshFormData, GetFormData, SetFormData, etc...);
2. Оборачиваете свои UI-библиотеки в декоратор, который реализует интерфейс IForm;
3. Создаете абстрактную фабрику, которая возвращает объект, реализующий IForm. Для создания и выбора нужного класса передаете все необходимые параметры: например, "название формы", массив "элементы" и прочее.

По итогу вы не будете работать напрямую с классами, а будете оперировать методами декоратора.

Comments

[romaro]

Наверное, тут нужно пояснить, что я работаю с фреймворком WinForms. Давайте на конкретном примере. У меня в UI-библиотеке есть компонент, который выглядит следующим образом:

По кнопке [+] должен открываться другая форма для создания конкретного объекта. Но класс этой формы, естественно, описан в самом приложении, библиотека о нем ничего не знает. Поэтому мне кажется, что приемлемым был бы такой код для контрола:

void BtnCreate_Click(object? sender, EventArgs e)
        {
            /// Получаю интерфейсную ссылку на экземпляр формы. Для этого передаю
            /// в метод ссылку на вью-модель (_ctx). Конечно, я мог бы во все вью-
            /// модели запихнуть логику получения форм, но это бы грубо нарушило
            /// принцип единой ответственности для вью-моделей.
            using IDependableForm form = FormsFactory.GetCreateForm(_ctx);
            /// Подписываюсь на событие закрытия формы, чтобы определенным
            /// образом изменить состояние компонента.
            form.OnFormClosing += DependableForm_Closing;
            /// Показываю форму модально, чтобы не усложнять приложение попыткой
            /// отследить родителя.
            form.ShowAsModal();
        }

То есть это действительно напоминает абстрактную фабрику, только в каком-то реверсивном варианте. И я бы даже сказал, что похоже на максимально прозрачный декоратор с фабричными методами. В пользу декоратора говорит и то, что "фабрика" и "движок" реализуют один и тот же интерфейс.

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

Или более правильным будет "реверсивный декоратор", поскольку суть его в том, что часть приложения фактически передается в управление библиотеке.