Принцип замены Лисков применяется к подтипу, который наследовался абстрактному классу?

свободно разговор, принцип замены Лисков указывает, что производный класс может быть заменой вместо базового класса, не влияя на пользователя. В случае, когда базовый класс является абстрактным классом, который означает, никакой пользователь не использует экземпляр базового класса, ограничения наследования Liskov все еще относится к производному классу?

12
задан Georg Fritzsche 21 May 2010 в 23:21
поделиться

5 ответов

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

Однако я подозреваю, что реальная проблема заключается в том, что у вас нет установленных VS2008 SP1, так как они исправили это обновление. К сожалению, Центр обновления Windows не сообщает вам, что SP1 существует, даже меню VS2008 "Справка > Проверить наличие обновлений" не сообщает о том, что он доступен. Вам придется перейти к;

http://www.microsoft.com/downloads/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E & displaylang = en

, чтобы получить его самостоятельно. После установки Tab Control работает так, как вы ожидали.

PS: Не забывайте о 3 обновлениях безопасности для SP1, всех 500MB. Центр обновления Windows находит их в порядке.

-121--5108244-

Да, потому что вызывающий всегда может сделать это:

BaseAbstractClass instance = new DerivedClass();
-121--285861-

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

7
ответ дан 2 December 2019 в 22:51
поделиться

Да, потому что вызывающий всегда может сделать это:

BaseAbstractClass instance = new DerivedClass();
1
ответ дан 2 December 2019 в 22:51
поделиться

Короче, да. LSP применяется по существу ко всем общедоступному наследованию. Тот факт, что базовый класс является абстрактным, этого не меняет. Базовый класс определяет интерфейс, и все законные производные должны удовлетворять всем требованиям этого интерфейса.

0
ответ дан 2 December 2019 в 22:51
поделиться

Я бы выделил информацию о версии из файлов AssemblyInfo.cs и * .rc . Создайте файл AssemblyVersion.cs и Version.rc , которые содержат (общие) сведения об управлении версиями для всех сборок. Вы создадите их в начале вашей сборки. Поскольку они содержат только сведения об управлении версиями, для которых не требуется использовать регулярные выражения, каждый раз можно перезаписать весь файл.

-121--3909720-

Абстрактные классы вообще не конфликтуют с LSP. Многие считают использование «нового» непосредственно из клиентского кода нарушением духа LSP. Если вы оба создаете экземпляр и используете объект, вы тесно связаны с этой реализацией, и вы не можете «подставить» его вообще.

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

-121--2858862-

Да.

См. раздел «Реальный пример» (стр. 7-8) в статье «Принцип замещения дяди Боба» .

0
ответ дан 2 December 2019 в 22:51
поделиться

Абстрактные классы вообще не конфликтуют с LSP. Многие считают использование "new" непосредственно из клиентского кода нарушением духа LSP. Если вы и инстанцируете, и используете объект, вы жестко привязаны к этой реализации, и вы не можете "подменить" его вообще.

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

0
ответ дан 2 December 2019 в 22:51
поделиться