Когда скрыть иерархию наследования в конкретном классе?

Question

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

Я заметил, что платформа .Net выбралареализовать Socket таким образом (вместо создания DatagramSocket вы передаете SocketType при создании).Каковы некоторые руководящие принципы для принятия решения, когда допустимо упорядочить иерархию в один конкретный класс, подобный этому?

Answer 1

Я думаю, что смысл в следующем: «Как много деталей низкого уровня должен знать клиент?».

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

В противном случае, если клиент уже осведомлен о некоторых деталях реализации низкого уровня (например, клиент знает, что сокет, который он будет использовать, является UDP, и он также ХОЧЕТ знать такую ​​информацию), тогда подход абстрактного базового класса может быть заменен внутренней "фабрикой стратегии".

Answer 2

В духе «предпочитаю композицию наследованию», я всегда выбираю стратегию + фабричный метод, а не наследование. Это дает мне несколько преимуществ: * Большую часть времени каждую стратегию можно тестировать отдельно, не заботясь о классе, который будет ее использовать. * в том же духе, клиентский класс может быть протестирован с помощью фиктивной стратегии * стратегии могут быть спроектированы так, чтобы их можно было составлять, например, с помощью шаблона декоратора, который дает большую гибкость, не вызывая взрыва субклазов.

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