Я могу ошибаться, но вроде как парадигма это совокупность действий, определяющих стиль. Т.е. парадигма в программровании — это семейство нотаций, различающихся по методикам.
Вы правы, так оно и есть.
MVC — это парадигма, в которую вписываются семейство паттернов. Паттерн — это реализация и они различны, как вы сказали ранее (М.Фаулер о MVC)
За 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 код?
Вы правы, так оно и есть.
MVC — это парадигма, в которую вписываются семейство паттернов. Паттерн — это реализация и они различны, как вы сказали ранее (М.Фаулер о MVC)
К тому же нужно разобраться в терминах, что есть шаблон. а что есть парадигма.
Но так как вы выделили, что:
уже говорит о том что вы подразумеваете парадигму.
При 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 код?