SOLID.LSP + ООП.Полиморфизм = противоречиe?

Question

[Вячеслав]

После изучения разных источников о Liskov Substitutioin Principle , так и не нашел ответа на вопрос:
Как LSP сочетается с полиморфизмом в ООП?
Ведь судя по определению, LSP предписывает наследникам сохранять поведение (контракт) базового класса.
Тогда как полиморфизм - это способность изменять поведение методов базового класса в наследниках. Если трактовать LSP буквально, то я вижу в этих подходах однозначное противоречие.
Собственно, как его разрешить?

Comments

[Adamos]

Элементарно: изменение методов в наследниках уточняет специализацию класса, а не противоречит контракту базового класса.
Если у вас наследники делают совершенно не то, на что подписан родитель - это у вас противоречие, а не у Лисков ;)

[Вячеслав]

Пример:
Базовый класс, реализует метод MakeReport(). Метод возвращает html с отчетом в виде таблицы. UnitTest ожидает и проверяет наличие определенных тегов в тексте.
Появилось требование - изменить формат некоторых отчетов на CSV. Согласно OCP создаем наследника, который перекрывает MakeReport() новым методом (полиморфизм).
Внезапно - UnitTest для наследника не проходит.
LSP нарушен?

[Adamos]

vpman, нарушена инкапсуляция - внешний код слишком много знает о внутреннем.
Таким образом, в контракт базового класса неявно вписано требование возвращать этим методом именно HTML, причем с определенными тегами. Как следствие - переделка нарушает LSP.
А вот если вы часть теста завернете в сам класс, создав у него изменяемый метод проверки корректности отчета, то потроха родителя перестанут торчать наружу, ваши тесты будут только вызывать child->IsValidReport(child->MakeReport()), и вы не будете нарушать LSP никакими переделками форматов.

[serginhold]

vpman, тут твое не понимание в том, что ты завязываешься на html в своем примере.
И тут как раз у тебя нарушение принципа единственной ответственности.
Все что должен делать твой метод, возвращать данные (массив например).
А другие классы уже занимаются форматированием данных твоего метода, html|csv, эти два класса будут всегда возвращать string, тогда ты принцип этой бабы не нарушаешь

[ThunderCat]

vpman,

MakeReport(). Метод возвращает html с отчетом в виде таблицы.

а должен возвращать ДАННЫЕ, а не ПРЕДСТАВЛЕНИЕ. Оформлять данные в представление задача другого класса, иначе это уже вообще не ооп, а каша.

[Adamos]

ThunderCat, внезапно, его класс может как раз и быть тем единственно ответственным, которому скармливают данные и получают сформатированный отчет в HTML. Не вижу, что в тексте противоречит этой версии. Разве что желание унаследовать от него класс, делающий совсем другую работу ;)

[ThunderCat]

Adamos, ну или таки это класс обработки, чего гадать то, суть не меняется. И судя по

Появилось требование - изменить формат некоторых отчетов на CSV.

разделением между данными и представлением там и не пахнет. Иначе с наследованием бы не было проблем.

[xfg]

vpman, LSP это о том, что если метод базового класса например возвращает площадь фигуры, то не нужно в наследнике пытаться возвращать например диаметр окружности, это приведет к некорректной работе клиента, который зависит от данного базового класса. Все наследники базового класса должны продолжать возвращать именно площадь фигуры, а не что-то иное. Принцип никаким образом не противоречит ни одному из видов полиморфизма.

Ваш пример, про юнит-тест, html/csv и lsp изначально не корректен. Вы не в состоянии в одном юнит-тесте проверить генерацию двух различных видов отчета. Хотя бы потому, что ваш юнит-тест проверет наличие тегов в сгенерированном отчете, которых впринципе не существует в csv. Эта задача решается написанием двух разных юнит-тестов, для html отчетов и для csv отчетов. Вы же пытаетесь смешивать не смешиваемое. LSP не имеет никакого отношения к тестированию вообще. Тесты должны быть простыми, краткими и очевидными.

Создавать child::IsValidReport исключительно для целей тестирования как тут советуют не корректно и излишне. Если подобный метод никем не используется в самой программе, то он лишний и очевидно не должен создаваться, а для разных отчетов нужно просто написать разные тесты.

Answer 1

[Mercury13]

LSP предписывает наследникам сохранять поведение (контракт) базового класса.

Не поведение, а ограничения. LSP разрешает только усиливать требования к себе, и только ослаблять — требования к другим. Поведение же может меняться как хочешь в рамках этих ограничений.

Например, интерфейс Stream позволяет мультиплексированные потоки (то есть потоки, где мы не можем считать записанное, чтение и запись идёт по разным каналам и никак не связаны друг с другом — например, COM-порты), а какой-нибудь BufferedStream ограничивается только потоками, где мы пишем в какую-нибудь цепочку байтов (например, файл), и читаем из неё же, без мультиплексирования.

Comments

[Adamos]

Мне кажется, что это все-таки больше про O, чем про L.
Фактически, LSP здесь выворачивается наизнанку: чтобы обеспечить вариативность наследников, создается максимально абстрактный класс, описывающий все, что может понадобиться наследникам, в самой обобщенной форме.

[Mercury13]

Adamos,

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

Это верно, и это можно сделать двумя способами.
1) Написать минимум кода.
2) Учесть всё, что только можно учесть.

Answer 2

[Станислав Макаров]

Появилось требование - изменить формат некоторых отчетов на CSV.

А кто сказал, что может появиться такое требование? Вернее, что вы сможете его удовлетворить без изменения контракта?

Ведь у вас какой контракт? Что метод MakeReport возвращает html-отчёт? Так как же вы вообще сможете реализовать возврат CSV, не поменяв контракт?

А вот если вы таки поменяете контракт, например скажете что "MakeReport возвращает поток (текстовый или двоичный) конечного размера", то тогда генерация и возврат CSV вполне себе лягут в такой контракт. Конечно, такой контракт уже будет куда более общим - даже тестировать в нём будет особого нечего (кроме того что отчёт вообще сгенерировался и имеет ненулевую длину).

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

Всё просто, не так ли?

Принцип подстановки говорит - я поставлю рамки, ограничения (т.е. контракт), и все экземпляры подклассов должны ему удовлетворять. Полиморфизм говорит - отлично, значит у нас возможность определить СПЕЦИФИЧНОЕ поведение, которое может отличаться от других специфичных поведений, но при этом все они будут делать что-то вполне ожидаемое и ЗАРАНЕЕ ОГОВОРЕННОЕ.

Сам факт того, что вы составляете СОГЛАШЕНИЯ, выполнения которых ожидают клиенты класса, даёт вам право ВО ВСЕХ ОСТАЛЬНЫХ аспектах вести себя КАК ВАМ ВЗДУМАЕТСЯ (ну я немного преувеличил, но суть такова) в каждом из подклассов.

Answer 3

[Михаил]

Тогда как полиморфизм - это способность изменять поведение методов базового класса в наследниках

Довольно странное утверждение. Полиморфизм - это скорее способность взаимозаменяемости типов. То есть в метод можно передать и класс А, и класс В : А.

Принцип LSP же как раз о том, как лучше этого достигнуть

Comments

[Вячеслав]

makarychev13,

То есть в метод можно передать и класс А, и класс В : А.

А виртуальные функции это что? Не полиморфизм?
Полиморфизм (Руководство по программированию на C#)

[Михаил]

vpman, Иногда полиморфизма можно добиться с помощью virtual, да. Но наличие virtual/override не означает, что это полиморфизм. И отсутствие virtual/override не означает, что полиморфизма нет.

[Вячеслав]

makarychev13

Но наличие virtual/override не означает, что это полиморфизм

Довольно странное утверждение.

[Михаил]

vpman, если есть класс В : А, в котором есть override, то при сигнатуре метода Foo(B bar), это не будет полиморфизмом. Более того, если есть абстрактный класс, у которого вы заоверайдили методы, то это тоже не полиморфизм

[Вячеслав]

makarychev13, абстрактные классы нужны, чтобы можно было создать более 1го варианта реализации, с разным поведением, иначе зачем дублировать функционал, так? Но оставим их в стороне.

Вот тут:

если есть класс В : А, в котором есть override, то при сигнатуре метода Foo(B bar), это не будет полиморфизмом

я не уловил суть кейза. Можете объяснить с примером кода?