Пример того, как наш продукт использует смешанные классы, - для сохранения и восстановления конфигурации. Существует абстрактный класс mixin, который определяет набор чисто виртуальных методов. Любой класс, который можно сохранить, наследуется от класса mixin для сохранения / восстановления, который автоматически предоставляет им соответствующие функции сохранения / восстановления.
Этот пример на самом деле не иллюстрирует полезность множественного наследования. То, что здесь определяется, это ИНТЕРФЕЙС. Множественное наследование также позволяет наследовать поведение. Какой смысл в миксинах.
Пример; из-за необходимости сохранения обратной совместимости я должен реализовать свои собственные методы сериализации.
Таким образом, каждый объект получает метод Read and Store, подобный этому.
Public Sub Store(ByVal File As IBinaryWriter)
Public Sub Read(ByVal File As IBinaryReader)
Я также хочу иметь возможность назначать и клонировать объект. Так что я хотел бы это на каждом объекте.
Public Sub Assign(ByVal tObject As <Class_Name>)
Public Function Clone() As <Class_Name>
Теперь в VB6 этот код повторяется снова и снова.
Public Assign(ByVal tObject As ObjectClass)
Me.State = tObject.State
End Sub
Public Function Clone() As ObjectClass
Dim O As ObjectClass
Set O = New ObjectClass
O.State = Me.State
Set Clone = 0
End Function
Public Property Get State() As Variant
StateManager.Clear
Me.Store StateManager
State = StateManager.Data
End Property
Public Property Let State(ByVal RHS As Variant)
StateManager.Data = RHS
Me.Read StateManager
End Property
Обратите внимание, что Statemanager - это поток, который читает и хранит байтовые массивы.
Этот код повторяется десятки раз.
Теперь в .NET я могу обойти это, используя комбинацию обобщений и наследования. Мой объект в версии .NET получает Assign, Clone и State, когда они наследуются от MyAppBaseObject. Но мне не нравится тот факт, что каждый объект наследуется от MyAppBaseObject.
Я просто смешиваю в интерфейсе Assign Clone И ПОВЕДЕНИИ. Еще лучше смешивать отдельно интерфейс Read и Store, а затем смешивать в Assign и Clone. На мой взгляд, это был бы более чистый код.
Но время, когда я повторно использую поведение, увеличивается во времени при использовании интерфейса. Это потому, что цель большинства иерархий объектов не в том, чтобы повторно использовать поведение, а в том, чтобы точно определить отношения между различными объектами. Для каких интерфейсов предназначены. Так что, хотя было бы неплохо, чтобы C # (или VB.NET) имел такую возможность, на мой взгляд, это не ограничитель показа.
Вся причина в том, что это даже проблема в том, что C ++ сначала шарил, когда дело дошло до интерфейса с проблемой наследования. Когда ООП дебютировал, все думали, что повторное использование поведения было приоритетом. Но это оказалось химерой и полезно только для конкретных обстоятельств, таких как создание структуры пользовательского интерфейса.
Позже была разработана идея миксинов (и других связанных концепций в аспектно-ориентированном программировании). Множественное наследование оказалось полезным при создании дополнений. Но C # был разработан как раз перед тем, как это было широко признано. Вероятно, для этого будет разработан альтернативный синтаксис.