Я хотел бы иметь набор соединений (REST, gRPC, RabbitMQ) для одного или нескольких различных типов служб. Например, с этой конфигурацией:
connections:
http:
- name: connectionA
host: localhost
port: 8081
endpoints:
- name: employees
httpMethod: GET
endpointType: EMPLOYEE
- name: departments
httpMethod: POST
endpointType: DEPARTMENT
grpc:
- name: connectionB
host: localhost
port: 8084
disableTls: true
endpoints:
- name: employees
endpointType: EMPLOYEE
При использовании EmployeeService у меня будут EmployeeHttpClient и EmployeeGrpcClient, а также DepartmentHttpClient в DepartmentService. Эти клиенты будут иметь конкретную реализацию с использованием конкретных сведений о соединении, но службу это не должно волновать.
Что вы думаете об этом подходе?
Как правильно это сделать в Spring Boot?




Похоже, это место, где можно использовать Паттерн стратегии:
Паттерн стратегии — это поведенческий шаблон проектирования программного обеспечения, который позволяет выбор алгоритма во время выполнения. Вместо реализации единого алгоритм напрямую, код получает инструкции во время выполнения относительно того, в каком семейство алгоритмов для использования.
Позвольте мне показать пример через C#. Мне жаль, что я не специалист по Java, однако я предоставил комментарии о том, как код может выглядеть на Java.
Нам нужно иметь какое-то общее поведение, которое будет общим для всех стратегий. В нашем случае это будет всего один метод Get() от разных поставщиков данных:
public interface IDataProvider
{
string Get();
}
И его конкретные реализации. Это обменные стратегии:
public class RabbitMQDataProvider : IDataProvider // implements in Java
{
public string Get()
{
return "I am RabbitMQDataProvider";
}
}
public class RestDataProvider : IDataProvider // implements in Java
{
public string Get()
{
return "I am RestDataProvider";
}
}
public class GrpcDataProvider : IDataProvider // implements in Java
{
public string Get()
{
return "I am GrpcDataProvider";
}
}
Нам нужно место, где можно хранить все стратегии. И мы должны быть в состоянии получить необходимую стратегию из этого магазина. Так что это место, где можно использовать простую фабрику. Простая фабрика — это не Шаблон фабричного метода и не Абстрактная фабрика.
public enum DataProviderType
{
RabbitMq, Rest, Grpc
}
public class DataProviderFactory
{
private Dictionary<DataProviderType, IDataProvider> _dataProviderByType
= new Dictionary<DataProviderType, IDataProvider>()
{
{ DataProviderType.RabbitMq, new RabbitMQDataProvider() },
{ DataProviderType.Rest, new RestDataProvider() },
{ DataProviderType.Grpc, new GrpcDataProvider() },
};
public IDataProvider GetInstanceByType(DataProviderType dataProviderType) =>
_dataProviderByType[dataProviderType];
}
и тогда вы можете проще получить экземпляр желаемого хранилища:
DataProviderFactory dataProviderFactory = new();
IDataProvider dataProvider = dataProviderFactory
.GetInstanceByType(DataProviderType.Grpc);
string data = dataProvider.Get();
Этот дизайн соответствует принципу открытое/закрытое.
Помните, что Википедия, как правило, плохой источник шаблонов проектирования. В прошлом он был наполнен вводящей в заблуждение и откровенно ложной информацией и примерами; и статьи регулярно редактировались нетехническими авторами.
@ jaco0646 jaco0646, не могли бы вы порекомендовать авторитетный интернет-источник шаблонов проектирования?
@ jaco0646 похоже, что нет веб-ресурса, на котором есть информация о шаблонах проектирования от Gang of Four.
Единственным по-настоящему авторитетным источником шаблонов проектирования GoF является сама оригинальная книга. Если вы хотите быть на 100 % уверены, что читаете именно то, что они хотели, единственный вариант — приобрести книгу. Каждый веб-сайт шаблонов проектирования, который я видел (а их много), содержит как минимум несколько противоречий по сравнению с книгой. Мне очень нравится refactoring.guru; но я нашел ошибки и там, если сравнивать с книгой.
Также стоит отметить, что книга GoF не является догмой. В некоторых областях я нахожу саму книгу крайне плохой. Поэтому я приятно удивлен, увидев, что этот ответ не идентифицирует свой фабричный пример как ни один из шаблонов GoF. Где соблюдение книги становится критическим, так это в простой необходимости общения. Независимо от того, обожаю я или презираю конкретный паттерн, нам нужно общее понимание, чтобы обсуждать его.
вы можете использовать
Factory Design Patternдля определения нескольких типов подключения.