Это хорошая идея создать класс для объекта, идентифицируемого по именам?

Question

У меня есть список услуг, которые можно идентифицировать по именам. Каждый сервис имеет набор параметров (IP-адрес, порт, доступность и т. Д.). Есть также метод, который можно применить к сервисам (закрыть соединение, открыть соединение, отправить сообщение на сервер, проверить, отвечает ли он и т. Д.).

Итак, я подумал, что это естественный подход к созданию класса Server и представлению реальных серверов в качестве объектов этого класса.

Но потом я понял, что это не очень удобно. Например, у меня есть имя сервера (просто строка), и я хотел бы что-то сделать с этим сервером. Тогда мне нужно иметь карту, которая отображает имя сервера на объект, представляющий этот сервер? Это не выглядит элегантным решением.

Я решил создать класс, содержащий набор статических методов. А затем, например, использовать его следующим образом: ServerClass.sendMessage("NameOfServer","MyMessage") или, например, ServerClass.close("NameOfServer") или ServerClass.getIP("NameOfServer").

Это хорошее решение?

Answer 1

Преимущество наличия класса с различными экземплярами состоит в том, что он обеспечивает своего рода безопасность типов. Если у вас есть

Server myServer = ServerRepository.getServer("NameOfServer");
if (myServer != null) myServer.sendMessage("MyMessage");

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

Answer 2

Все ли ваши серверы предоставляют одни и те же сервисы или некоторые из них зависят от сервера. Например, если у вас есть оба FooServers, у которых есть метод doFoo (), и BarServers с методом doBar (), но у Foo нет doBar, а у Bar нет doFoo, то это, вероятно, плохая идея, так как ваш ServerClass потенциально предоставляет методы, которые бессмысленно для потенциальных абонентов. Однако, если вы знаете, что все ваши серверы будут FooServers, то это может быть правильным подходом, поскольку вы можете централизовать общий код. Я бы сказал, что будьте осторожны, чтобы ваш код оставался поддерживаемым, и вы не навязываете обычное поведение там, где его нужно настраивать, или в итоге вы добавляете множество дополнительных аргументов, чтобы указать «особые случаи», когда вам нужно, чтобы поведение слегка изменялось для та или иная причина.