Является ли Наследство правильным подходом?

Question

У нас есть базовый класс TCP Server, который обеспечивает функциональность сервера.Теперь мы хотим обеспечить безопасную функциональность TCP-сервера.Мы обсуждали два подхода:

1. Передать значение конструктору сервера TCP, указав, должно ли оно выступать в качестве TCPServer или защищенного сервера TCP.

2. Создайте класс TCPSecure, унаследованный от класса TCP Server, для этого потребуется переопределить несколько методов базового класса.

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

Второй подход выглядит более правильным с точки зрения дизайна.Но мы не ожидаем, что произойдет больше типов деривации.Так стоит ли вводить новый класс для этого?

Заранее спасибо.

Answer 1

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

Это называется принцип замещения Лискова и является одним из краеугольных камней дизайна ОО.

Answer 2

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

Answer 3

Похоже, что второй подход хорош. Хороший показатель - убедиться, что он не нарушает принцип замены Лискова .

Answer 4

Переключатели поведения не так легко понять, как подклассы, в общем, поэтому я бы предпочел отдать предпочтение подклассам. Я не буду беспокоиться об отсутствии будущих подклассов. Вероятно, лучший способ сделать это - иметь базовый класс Server с подклассами Secure и Insecure (или как вы хотите их называть).

Помните принцип Лискова: TCPSecure должен быть заменой TCPServer, поскольку он будет делать все, что TCPServer будет делать с точки зрения программирования. Он не должен делать это таким же образом, и фактически может блокировать определенное поведение пользователя, но код, вызывающий его, не должен знать, а вызывающие функции не должны давать неожиданные результаты.

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

Answer 5

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