Может кто-нибудь привести лучший пример хрупких проблем базового класса?

Question

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

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

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

Если кто-то хотел бы поделиться своим опытом по этому поводу, это было бы очень полезно.

Вот ссылка на википедию, чтобы понять эту проблему

Хрупкий базовый класс в Википедии

EDIT:

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

Получил хорошую цитату от Джоэла на старом форуме Software. Мысль об этом.

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

Answer 1

Да - java.util. Свойства - это боль, которую можно извлечь.

На данный момент давайте оставим в стороне тот факт, что он является производным от java.util.Hashtable для начала (что означает, что он имеет get(Object) и put(Object, Object), несмотря на тот факт, что свойства всегда являются строками ...

Однажды я создал подкласс java.util.Properties для обеспечения своего рода иерархической структуры - в файле свойств, который у меня был:

x.y.z = 10
a.b.c = 10

и вы можете задать свойства "master" для "x" (с новым вызовом метода), и это даст вам другой объект свойств, который будет эффективно содержать "yz = 10" и т. Д. Это было удобно для подкласса java.util Свойства, как и многие другие части кода, уже знают используемые свойства. Если бы он реализовал интерфейс, я бы не подкласс, и у меня не было бы никаких проблем: (

В любом случае, мне нужно было переопределить getProperty (), чтобы при необходимости вернуться к родительским свойствам. Но есть две перегрузки - что мне переопределить? GetProperty (String) вызывает getProperty (String, String) или наоборот? Может быть, мне нужно только переопределить get ()? Это не задокументировано, и если я переопределю только один из них, реализация может измениться в более поздней версии, чтобы изменить положение вещей, поэтому мне нужно было переопределить оба из них.

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

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