За YouTube можете сказать спасибо корпорации «добра». Они заблокировали самое лучшее приложение Youtube как было вообще за всю время на любой из платформы на Windows Phone. Любые попытка MS договориться были отклонены.
class A
{
protected $data;
public function add($item)
{
$this->data[] = $item;
}
}
class B extends A
{
public function add($item)
{
if ($item < 52) {
throw new Exception("Итем не может быть меньше 52");
}
$this->data[] = $item;
}
}
Вот тут идет нарушение. Класс наследник в методе add бросает исключение, которое не бросает класс родитель. Это нарушение LSP.
Вообще SOLID стараются как можно больше перенести в язык(на сколько это возможно), т.к тогда можно контролировать на уровне компилятора(интерпретатора). Но естественно, это не всегда возможно.
Где вы этого бреда нахватались. Что ещё за пост-условие контракта?
В контракте у вас описано, что возвращается итератор. Он как возвращался, так и возвращается. Беда PHP в том что списки и словари объединены, но это отдельная тема. У вас же концептуальное не понимание, что такое свойство контракта.
Контракт это не мифические вещи, которые программист придумал и описал в юнит-тесте, как ему вздумалось, а условия переданные путем языковых конструкций.
Если грубо, то при замене класса его наследником программа должна дальше работать без ошибок. Либо выбрасывать ошибки такого же типа, что кидала и с родительским классом. Всё остальное — это не понимание LSP.
Если бы я создал класс, такой как пример ниже, то что-то принципиально бы изменилось?
Да, тут явно видны две ошибки.
1. Нарушен Принцип единственной обязанности (класс изменяет объект и что-то вычисляет, используя его как параметр)
2. Нельзя менять входящие параметры в методе.
Дело не в правильности или неправильности вычисления площади квадрата, дело в замене поведения методов класса
Принцип гласит — «Объекты в программе могут быть заменены их наследниками без изменения свойств программы»
Принцип гласит:
Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
То что вы понимаете под свойством им не является. Поведение методов не изменено. Оно изменено в следующих случаях, при перегрузке:
— бросает исключение, которые не бросает перегружаемый метод
— количество обязательных параметров контракта методов изменен
— тип обязательных параметров не соответствует типу перегруженного метода
Что это делает на Хабре?!
Чему может обучить данная статья:
— как правильно оформлять расширения?
— как правильно структурировать JS расширения?
— «красивый» JS код?
Ваш пример абсолютно не показал нарушения LSP. Ваш объект Square успешно используется и более того, он вычисляется правильно.
Дальше, почему вы используете функцию, которая изменяет объект, а потом вычисляет некоторое значение? Это вообще не попадает не под одну парадигму, ни под функциональную ни под Объектно ориентированную.
И если мы уж говорим о ООП, то давайте не смешивать два подхода и удивляться, что что-то пошло не так, по вашему мнению
К чему я веду, да к тому что принцип подстановки Барбары Лисков не раскрыт чуть больше чем полностью. Вы говорите вообще не о том. Весь принцип сводится к интерфейсу класса.
P.S.
По поводу сеттеров, я бы советовал поменьше их использовать в принципе, если все свойства объекта имеют сеттеры, то скорее всего это не должно быть объектом, а должно быть набором данных, которые используются для создания объектов. Т.к. если можно менять всё, то о какой бизнес-логике можно вести речь?
class Rectangle
{
protected $width;
protected $height;
public function __construct($width, $height ) {
$this->width = $width;
$this->height = $height;
}
public function getWidth()
{
return $this->width;
}
public function getHeight()
{
return $this->height;
}
public function calculateSquare()
{
return $this->height * $this->width;
}
}
class Square extends Rectangle
{
public function __construct($size) {
parent::__construct($size, $size);
}
}
class TwoPointsData
{
private $width;
private $height;
public function getWidth()
{
return $this->width;
}
public function setWidth($width)
{
$this->width = $width;
}
public function getHeight()
{
return $this->height;
}
public function setHeight($height)
{
$this->height = $height;
}
}
class Rectangle
{
public function __construct(TwoPointsData $data)
{
...
}
public function calculateSquare()
{
return $this->height * $this->width;
}
}
class Square extends Rectangle
{
public function __construct(TwoPointsData $data)
{
...
}
}
К тому же нужно разобраться в терминах, что есть шаблон. а что есть парадигма.
Но так как вы выделили, что:
уже говорит о том что вы подразумеваете парадигму.
При MVC пользователь взаимодействует с Controller а не со View
Да, не совсем удачное решение с кнопкой назад, но блин, браузер страницы открывает отлично.
p.s.
извините за некрокомментинг :)
По одному методу то, когда принцип касается правила использования классов.
Вот тут идет нарушение. Класс наследник в методе add бросает исключение, которое не бросает класс родитель. Это нарушение LSP.
Вообще SOLID стараются как можно больше перенести в язык(на сколько это возможно), т.к тогда можно контролировать на уровне компилятора(интерпретатора). Но естественно, это не всегда возможно.
В контракте у вас описано, что возвращается итератор. Он как возвращался, так и возвращается. Беда PHP в том что списки и словари объединены, но это отдельная тема. У вас же концептуальное не понимание, что такое свойство контракта.
Контракт это не мифические вещи, которые программист придумал и описал в юнит-тесте, как ему вздумалось, а условия переданные путем языковых конструкций.
Если грубо, то при замене класса его наследником программа должна дальше работать без ошибок. Либо выбрасывать ошибки такого же типа, что кидала и с родительским классом. Всё остальное — это не понимание LSP.
Советую почитать Б.Мэйера «Объектно-ориентированное конструирование программных систем»
Подставьте вместо DataCollector AnotherDataCollector, поведение программы не изменится. Изменится результат.
Вопрос, что результат будет вас не удовлетворять — лежит совершенно в другой плоскости.
Да, тут явно видны две ошибки.
1. Нарушен Принцип единственной обязанности (класс изменяет объект и что-то вычисляет, используя его как параметр)
2. Нельзя менять входящие параметры в методе.
Принцип гласит:
То что вы понимаете под свойством им не является. Поведение методов не изменено. Оно изменено в следующих случаях, при перегрузке:
— бросает исключение, которые не бросает перегружаемый метод
— количество обязательных параметров контракта методов изменен
— тип обязательных параметров не соответствует типу перегруженного метода
Извините, но вы не понимаете LSP
Что это за ананизм, мы JavaScript не знаем?
es5.javascript.ru/x15.5.html#x15.5.4.20
Я боюсь вас удивить, но то что вы написали укладывается в 1 строчку:
ЗАЧЕМ?! Вы же в манифесте всё описали:
developer.chrome.com/extensions/content_scripts
Чему может обучить данная статья:
— как правильно оформлять расширения?
— как правильно структурировать JS расширения?
— «красивый» JS код?
Ваш пример абсолютно не показал нарушения LSP. Ваш объект Square успешно используется и более того, он вычисляется правильно.
Дальше, почему вы используете функцию, которая изменяет объект, а потом вычисляет некоторое значение? Это вообще не попадает не под одну парадигму, ни под функциональную ни под Объектно ориентированную.
И если мы уж говорим о ООП, то давайте не смешивать два подхода и удивляться, что что-то пошло не так, по вашему мнению
К чему я веду, да к тому что принцип подстановки Барбары Лисков не раскрыт чуть больше чем полностью. Вы говорите вообще не о том. Весь принцип сводится к интерфейсу класса.
P.S.
По поводу сеттеров, я бы советовал поменьше их использовать в принципе, если все свойства объекта имеют сеттеры, то скорее всего это не должно быть объектом, а должно быть набором данных, которые используются для создания объектов. Т.к. если можно менять всё, то о какой бизнес-логике можно вести речь?