Дополнение чужого функционала

velkin velkin
Предположим имеется сторонняя библиотека (пусть будет C++), то есть написанная другими людьми, и в ней от 100 до 1000 классов (парадигма ООП). Причём это не столь важно, теоретически может быть 10, а может и 10000. Далее каждый класс содержит некую функциональность, которую хотелось бы расширить. При этом каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки.

В этом случае мне на ум приходят два варианта:
1) Создаём производный класс и уже в нём проводим нужные изменения
2) Изменяем классы в сторонней библиотеке

Если подумать, то недостаток первого варианта это само наследование. Речь даже не о скоростных характеристиках, а просто о том, что в сторонней библиотеке могут быть установлены закрытые (private) модификаторы доступа. Опять же происходит полное дублирование классов, в своей программе придётся использовать только производные и тщательно за этим следить.

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

В принципе и всё, интересно было бы услышать идеи на этот счёт, хотя вопрос скорее теоретический об эволюции ПО и отказа от повторного изобретения велосипедов.
LaptevVV
LaptevVV
08.01.2017 06:39
Композицию и агрегацию можно вместо наследования.
velkin
velkin
08.01.2017 09:17
Здравствуйте, LaptevVV, Вы писали:

LVV>Композицию и агрегацию можно вместо наследования.


V>Предположим имеется сторонняя библиотека (пусть будет C++), то есть написанная другими людьми, и в ней от 100 до 1000 классов (парадигма ООП). Причём это не столь важно, теоретически может быть 10, а может и 10000. Далее каждый класс содержит некую функциональность, которую хотелось бы расширить. При этом каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки.


Написал чтобы не возникало вопросов про отношение содержит, коим является агрегирование. А вот является это именно наследование. C моей точки зрения агрегирование в данном случае гораздо хуже, чем открытое наследование, так как проблему модификаторов доступа чужих классов не решает, но накладывает ограничение на использование членов класса. Собственно говоря с агрегированием получится ещё более сложная архитектура. Но если есть какие-то мысли, то интересно было бы послушать.
LaptevVV
LaptevVV
08.01.2017 01:42
LVV>>Композицию и агрегацию можно вместо наследования.
V>>Предположим имеется сторонняя библиотека (пусть будет C++), то есть написанная другими людьми, и в ней от 100 до 1000 классов (парадигма ООП). Причём это не столь важно, теоретически может быть 10, а может и 10000. Далее каждый класс содержит некую функциональность, которую хотелось бы расширить. При этом каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки.
V>Написал чтобы не возникало вопросов про отношение содержит, коим является агрегирование. А вот является это именно наследование. C моей точки зрения агрегирование в данном случае гораздо хуже, чем открытое наследование, так как проблему модификаторов доступа чужих классов не решает, но накладывает ограничение на использование членов класса. Собственно говоря с агрегированием получится ещё более сложная архитектура. Но если есть какие-то мысли, то интересно было бы послушать.
Собственно, я подумал, что ОБЫЧНО библиотечные классы не предназначены для наследования.
Если они разрабатывались именно с учетом будущего наследования, то вопросов нет — надо наследовать.
А если нет?
Вот жеж STL никак для наследования не предназначена.
А написать обертку при необходимости с использованием композиции — как 2 байта переслать.
Кроме того, вопросы вызывает потребность изменения модификаторов доступа.
Ведь разработчик не от былды расставил модификаторы.
А вы хотите его модель доступа порушить?
Нафига это нужно?
Sharov
Sharov
08.01.2017 11:35
Здравствуйте, LaptevVV, Вы писали:

LVV>Композицию и агрегацию можно вместо наследования.


Паттерн decorator наше всё.
ylem
ylem
08.01.2017 01:44
Наследование тоже много не даст, если классы изначально для этого не были предназначены. Фактически получите не многим больше, чем то, что в C# можно получить extension-методами.
То, чего ими нельзя получить ("расширить состояние" объектов), не уверен, что вообще стоит делать.