Задать вопрос
@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();
	}
}


Есть ли у такого паттерна устоявшееся название и какие у него могут быть альтернативы?
  • Вопрос задан
  • 120 просмотров
Подписаться 1 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 2
@mvv-rus
Настоящий админ AD и ненастоящий программист
IMHO это - вариант шаблона "Абстрактная фабрика"
Первая приходящая на ум альтернтатива - та, в которой этот шаблон используется традиционно: реализации наследуются от абстрактного класса фабрики (см. пример для C# в статье по ссылке), а не получаются аггрегированием фактичекой реализации со статическим классом, предостатвляющим интерфейс, как у вас.
Ответ написан
Комментировать
@Shavadrius
Возможно я не совсем правильно вас понял, но вам нужны паттерны "Абстрактная фабрика" и, если не хотите (или не можете) менять классы в UI-библиотеках, паттерн "Декоратор" (Wrapper). В чем суть:
1. Создаете интерфейс IForm, в котором описываете что и как должно создаваться (например, классы CreateForm, DrawForm, RefreshFormData, GetFormData, SetFormData, etc...);
2. Оборачиваете свои UI-библиотеки в декоратор, который реализует интерфейс IForm;
3. Создаете абстрактную фабрику, которая возвращает объект, реализующий IForm. Для создания и выбора нужного класса передаете все необходимые параметры: например, "название формы", массив "элементы" и прочее.

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

Войдите, чтобы написать ответ

Похожие вопросы