Сообщение Re: Дополнение чужого функционала от 12.07.2021 20:35
Изменено 12.07.2021 20:41 Shtole
Re: Дополнение чужого функционала
Здравствуйте, velkin, Вы писали:
На главной странице написано, что заметке 4 месяца. В тексте заметки — что она 2017 года. Короче, обвинения в некропостинге не принимаются.
V>Предположим имеется сторонняя библиотека (пусть будет C++), то есть написанная другими людьми, и в ней от 100 до 1000 классов (парадигма ООП). Причём это не столь важно, теоретически может быть 10, а может и 10000. Далее каждый класс содержит некую функциональность, которую хотелось бы расширить. При этом каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки.
V>В этом случае мне на ум приходят два варианта:
V>1) Создаём производный класс и уже в нём проводим нужные изменения
V>2) Изменяем классы в сторонней библиотеке
V>Если подумать, то недостаток первого варианта это само наследование. Речь даже не о скоростных характеристиках, а просто о том, что в сторонней библиотеке могут быть установлены закрытые (private) модификаторы доступа. Опять же происходит полное дублирование классов, в своей программе придётся использовать только производные и тщательно за этим следить.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», наследование приведёт к тому, что структура кода вступит в противоречие с описываемой им реальностью. Лично я считаю, что после этого код становится плохо поддерживаемым, в частности, незнакомый с ним человек будет долго тупить, зачем там класс-родитель и класс-потомок, ответ придётся прописывать в комментариях, конфлюэнсе или передавать изустно и т.п.
V>Изменение же сторонней библиотеки в случае её изменения от версии к версии повлечёт за собой изменения уже изменённых классов, то есть процесс обновления будет не сказать, чтобы очень простым. При этом есть вероятность поломать чужой функционал. И в отличие от первого варианта, чем больше изменений произведено, тем сложнее потом будет обновляться до новых версий, не говоря уже о перекомпиляции чужой библиотеки.
Так делать, разумеется, тоже не стоит — любой будущий багфикс (со стороны автора библиотеки) будет иметь непредсказуемую стоимость интеграции. То есть, такое решение приведёт к росту рисков, а они должны уменьшаться.
V>В принципе и всё, интересно было бы услышать идеи на этот счёт, хотя вопрос скорее теоретический об эволюции ПО и отказа от повторного изобретения велосипедов.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», значит библиотека в текущем виде — сырая. Надо просто подождать новую версию или поискать другую, где уже всё написано.
Хорошо, когда недостаточно имплементированный в текущей версии функционал вынесен в заведомо расширяемое место, например командный DSL. Тогда можно писать плохие раздутые запросы с реализацией недостающего функционала, а после обновления — заменять их на хорошие короткие.
В крайнем случае, пусть будут предусмотрены колбэки, которым предоставлен r/w-доступ ко всем необходимым кишкам.
Если ни того, ни другого не будет — я сто раз подумаю, прежде чем пользоваться такой библиотекой.
Кстати, это причина, по которой у меня аллергия на слово YAGNI.
На главной странице написано, что заметке 4 месяца. В тексте заметки — что она 2017 года. Короче, обвинения в некропостинге не принимаются.
V>Предположим имеется сторонняя библиотека (пусть будет C++), то есть написанная другими людьми, и в ней от 100 до 1000 классов (парадигма ООП). Причём это не столь важно, теоретически может быть 10, а может и 10000. Далее каждый класс содержит некую функциональность, которую хотелось бы расширить. При этом каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки.
V>В этом случае мне на ум приходят два варианта:
V>1) Создаём производный класс и уже в нём проводим нужные изменения
V>2) Изменяем классы в сторонней библиотеке
V>Если подумать, то недостаток первого варианта это само наследование. Речь даже не о скоростных характеристиках, а просто о том, что в сторонней библиотеке могут быть установлены закрытые (private) модификаторы доступа. Опять же происходит полное дублирование классов, в своей программе придётся использовать только производные и тщательно за этим следить.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», наследование приведёт к тому, что структура кода вступит в противоречие с описываемой им реальностью. Лично я считаю, что после этого код становится плохо поддерживаемым, в частности, незнакомый с ним человек будет долго тупить, зачем там класс-родитель и класс-потомок, ответ придётся прописывать в комментариях, конфлюэнсе или передавать изустно и т.п.
V>Изменение же сторонней библиотеки в случае её изменения от версии к версии повлечёт за собой изменения уже изменённых классов, то есть процесс обновления будет не сказать, чтобы очень простым. При этом есть вероятность поломать чужой функционал. И в отличие от первого варианта, чем больше изменений произведено, тем сложнее потом будет обновляться до новых версий, не говоря уже о перекомпиляции чужой библиотеки.
Так делать, разумеется, тоже не стоит — любой будущий багфикс (со стороны автора библиотеки) будет иметь непредсказуемую стоимость интеграции. То есть, такое решение приведёт к росту рисков, а они должны уменьшаться.
V>В принципе и всё, интересно было бы услышать идеи на этот счёт, хотя вопрос скорее теоретический об эволюции ПО и отказа от повторного изобретения велосипедов.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», значит библиотека в текущем виде — сырая. Надо просто подождать новую версию или поискать другую, где уже всё написано.
Хорошо, когда недостаточно имплементированный в текущей версии функционал вынесен в заведомо расширяемое место, например командный DSL. Тогда можно писать плохие раздутые запросы с реализацией недостающего функционала, а после обновления — заменять их на хорошие короткие.
В крайнем случае, пусть будут предусмотрены колбэки, которым предоставлен r/w-доступ ко всем необходимым кишкам.
Если ни того, ни другого не будет — я сто раз подумаю, прежде чем пользоваться такой библиотекой.
Кстати, это причина, по которой у меня аллергия на слово YAGNI.
Re: Дополнение чужого функционала
Здравствуйте, velkin, Вы писали:
На главной странице написано, что заметке 4 месяца. В тексте заметки — что она 2017 года. Короче, обвинения в некропостинге не принимаются.
V>Предположим имеется сторонняя библиотека (пусть будет C++), то есть написанная другими людьми, и в ней от 100 до 1000 классов (парадигма ООП). Причём это не столь важно, теоретически может быть 10, а может и 10000. Далее каждый класс содержит некую функциональность, которую хотелось бы расширить. При этом каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки.
V>В этом случае мне на ум приходят два варианта:
V>1) Создаём производный класс и уже в нём проводим нужные изменения
V>2) Изменяем классы в сторонней библиотеке
V>Если подумать, то недостаток первого варианта это само наследование. Речь даже не о скоростных характеристиках, а просто о том, что в сторонней библиотеке могут быть установлены закрытые (private) модификаторы доступа. Опять же происходит полное дублирование классов, в своей программе придётся использовать только производные и тщательно за этим следить.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», наследование приведёт к тому, что структура кода вступит в противоречие с описываемой им реальностью. Лично я считаю, что после этого код становится плохо поддерживаемым, в частности, незнакомый с ним человек будет долго тупить, зачем там класс-родитель и класс-потомок, ответ придётся прописывать в комментариях, конфлюэнсе или передавать изустно и т.п.
V>Изменение же сторонней библиотеки в случае её изменения от версии к версии повлечёт за собой изменения уже изменённых классов, то есть процесс обновления будет не сказать, чтобы очень простым. При этом есть вероятность поломать чужой функционал. И в отличие от первого варианта, чем больше изменений произведено, тем сложнее потом будет обновляться до новых версий, не говоря уже о перекомпиляции чужой библиотеки.
Так делать, разумеется, тоже не стоит — любой будущий багфикс (со стороны автора библиотеки) будет иметь непредсказуемую стоимость интеграции. То есть, такое решение приведёт к росту рисков, а они должны уменьшаться.
V>В принципе и всё, интересно было бы услышать идеи на этот счёт, хотя вопрос скорее теоретический об эволюции ПО и отказа от повторного изобретения велосипедов.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», значит библиотека в текущем виде — сырая. Надо просто подождать новую версию или поискать другую, где уже всё написано.
Хорошо, когда недостаточно имплементированный в текущей версии функционал вынесен в заведомо расширяемое место, например командный DSL. Тогда можно писать плохие раздутые запросы с реализацией недостающего функционала, а после обновления — заменять их на хорошие короткие.
В крайнем случае, пусть будут предусмотрены колбэки, которым предоставлен r/w-доступ ко всем необходимым кишкам.
Если ни того, ни другого не будет (и при этом налицо нехватка функционала, который, как подразумевается, должен быть без наследования) — я сто раз подумаю, прежде чем пользоваться такой библиотекой.
Кстати, это причина, по которой у меня аллергия на слово YAGNI.
На главной странице написано, что заметке 4 месяца. В тексте заметки — что она 2017 года. Короче, обвинения в некропостинге не принимаются.
V>Предположим имеется сторонняя библиотека (пусть будет C++), то есть написанная другими людьми, и в ней от 100 до 1000 классов (парадигма ООП). Причём это не столь важно, теоретически может быть 10, а может и 10000. Далее каждый класс содержит некую функциональность, которую хотелось бы расширить. При этом каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки.
V>В этом случае мне на ум приходят два варианта:
V>1) Создаём производный класс и уже в нём проводим нужные изменения
V>2) Изменяем классы в сторонней библиотеке
V>Если подумать, то недостаток первого варианта это само наследование. Речь даже не о скоростных характеристиках, а просто о том, что в сторонней библиотеке могут быть установлены закрытые (private) модификаторы доступа. Опять же происходит полное дублирование классов, в своей программе придётся использовать только производные и тщательно за этим следить.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», наследование приведёт к тому, что структура кода вступит в противоречие с описываемой им реальностью. Лично я считаю, что после этого код становится плохо поддерживаемым, в частности, незнакомый с ним человек будет долго тупить, зачем там класс-родитель и класс-потомок, ответ придётся прописывать в комментариях, конфлюэнсе или передавать изустно и т.п.
V>Изменение же сторонней библиотеки в случае её изменения от версии к версии повлечёт за собой изменения уже изменённых классов, то есть процесс обновления будет не сказать, чтобы очень простым. При этом есть вероятность поломать чужой функционал. И в отличие от первого варианта, чем больше изменений произведено, тем сложнее потом будет обновляться до новых версий, не говоря уже о перекомпиляции чужой библиотеки.
Так делать, разумеется, тоже не стоит — любой будущий багфикс (со стороны автора библиотеки) будет иметь непредсказуемую стоимость интеграции. То есть, такое решение приведёт к росту рисков, а они должны уменьшаться.
V>В принципе и всё, интересно было бы услышать идеи на этот счёт, хотя вопрос скорее теоретический об эволюции ПО и отказа от повторного изобретения велосипедов.
Если я правильно понимаю, что значат слова «каждый расширенный класс по функционалу не просто содержит, а именно является тем самым классом из сторонней библиотеки», значит библиотека в текущем виде — сырая. Надо просто подождать новую версию или поискать другую, где уже всё написано.
Хорошо, когда недостаточно имплементированный в текущей версии функционал вынесен в заведомо расширяемое место, например командный DSL. Тогда можно писать плохие раздутые запросы с реализацией недостающего функционала, а после обновления — заменять их на хорошие короткие.
В крайнем случае, пусть будут предусмотрены колбэки, которым предоставлен r/w-доступ ко всем необходимым кишкам.
Если ни того, ни другого не будет (и при этом налицо нехватка функционала, который, как подразумевается, должен быть без наследования) — я сто раз подумаю, прежде чем пользоваться такой библиотекой.
Кстати, это причина, по которой у меня аллергия на слово YAGNI.