Нет, про то, что массив реализует IList, при этом кидает исключения на операции Add/Remove

Вверх дизайна же

Что

Что блять

Ага, именно так

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

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

В таких случаях проще сбоку вторую библиотеку написать

Т.е. дублировать функциональность

Так адово костылить как ты написал можно только если все гвоздями прибито к старой либе

Дупликация вообще часто сопровождает наследование на практике

Поэтому я за композицию

я надеюсь, что в итоге ребятам таки выдали добро на написание новой библиотеки, ага.

Так, а в расте реализуема схема общий интерфейс + композиция?

На етом уже можно было бы писать гуй

ну так и написано сколько-то. просто конкретно тем, что есть, пользоваться не слишком приятно

Понятно

А какой конструкцией языка выражается наследование интерфейса без наследования реализации? Я просто не знаю раст

Типа просто общий трейт? Или структ?

типажами, да. типаж это и есть, практически, интерфейс (с нюансами всякими, да, я помню).

Ок, норм. Спасибо