Байт тоже иностранное слово. Впервые появилось в английском языке. Вы уж тогда и его переименуйте, раз уж так увлеклись. В языке постоянно появляются новые слова, большинство из них — это заимствования. Особенно их много среди профессиональных терминов, их трогать уж точно не стоит.
В ИТ всё меняется, конечно, быстро по сравнению с другими отраслями, но не настолько же, чтобы совсем нельзя было обучать студентов программированию. Стабилизация основных парадигм и принципов уже произошла. Программирование в сегодняшнем виде будет существовать ещё по крайней мере пару десятков лет. Умение писать хороший, понятный код не перестанет быть ценным через 10 лет. Общие понятия об архитектуре приложений, принципах ООП и т.д. тоже быстро не устареют. Те же паттерны проектирования широко известны уже лет 15 и они не устареют пока ООП ведущая парадигма в программировании.
При обучении просто не следует делать упор на технологии, конкретный язык программирования или платформа это скорее пример на котором изучаются более общие принципы. Надо изучать архитектуру веб-ориентированных систем, а не программирование на php, ruby или java. Надо изучать не синтаксис потоков в любимом языке преподавателя, а курс конкурентного программирования и т.д. Надо не писать бесполезные скрипты на 1000 строк, а учится работать в команде.
В общем основы несомненно нужны, но кроме них программа обучения многих наших вузом могла бы быть несколько обновлена. Не дело когда человек получивший диплом программиста никогда не слышал о рефакторинге или блочном тестировании.
Это кажется необычным или неправильным только тем, кто привык программировать на языках со строгой типизацией. В языках с динамической типизацией немного различное поведение функции в зависимости от типа переданного параметра это обычное дело. Такое можно часто встретить и в Zend Framework на php и в javascript (функция $ в jquery), и даже в ядре ruby (функции меняют своё поведение при передачи им опционального раби блока) Конечно, это усложняет саму функцию (некрасивой логикой) и снижает очевидность её интерфейса. Но если это даёт значительное удобство для клиентского кода, то вполне можно осторожно применять. К тому же, в таких случаях возможные входные параметры часто имеют одинаковое смысловое значение: например, можно передать или сам объект или его идентификатор.
В Zend Framework для подобных целей есть экшен хелпер ContextSwitch.
А мысли об изменении чего либо в ядре фреймворка сразу отбросьте. Кому нужны эти проблемы с отладкой и обновлением :). Да это и не нужно. Zend Framework в плане изменения поведения очень гибок.
Да иногда Ext действительно не очень быстрый. Например, окошки в 7-ом эксплорере заметно тормозят. Тем не менее библиотека отличная, ничего лучшего пока просто нет. Фактически полноценный фреймворк для создания интерфейсов, а не просто набор виджетов, как в других библиотеках.
А вы вообще знаете что такое ORM? AdoDB или SimpleDB - это не ORM. ORM расшифровывается Object-relational mapping. Технология носит такое название, поскольку позволяет поставить соответсвие между реляционной БД и объектами домена вашего приложения (это совершенно необходимо при использовании модели предметной области). Это, как раз для улучшения кода в первую очередь и нужно. Вы просто попробуйте попользоваться такой системой для php: Doctrine, например, или Zend_Db_Table. Вы сразу почувствуете преимущества.
Прочитал. Это всё несеръёзно. Не верьте ему :). Эти проблемы не делают ООП в php неполноценным. Некоторые из них так и вообще отношения к ООП не имеют (перегрузка то причём). Рассматривайте статью лишь как частное мнение автора о том каким бы он хотел видеть язык. Если брать в расчёт только пятую версию с ооп всё хорошо в пхп, да кое что неудобно, но принципы соблюдены.
Ну я и говорю делегирование.
Кстати инверсия зависимостей это гораздо более широкое понятие, чем паттерн стратегия. Инъекция зависимостей тоже, она конечно тесно с ним связана, но не тоже самое.
Я вот не могу понять, откуда берётся мнение, что в php (пятая версия, конечно) неполноценное ООП? Инкапсуляция присутствует, наследование имеется, паттерны GOF реализуемы. Что же ещё надо? :)
Или вас смущает, что в языке изначально ориентированном на duck typing появились интерфейсы и type hinting?
Вы говорите о примерах про геометрические фигуры в целом. Это да, полная классика: наглядно и сильно :). А вот спор прямоугольник-квадрат как раз и родился, чтобы показать, что даже в примере про фигуры, который есть в половине учебников, могут быть маленькие подводные камни. Ведь чуть-чуть скептицизма никогда не помешает.
Насчёт дублирования кода есть ведь разные варианты его устранения можно использовать делегирование, можно использовать миксины (если позволяет язык)
Находить абстракции и выделять из них наиболее общие это главная задача скорее объектного анализа. А при переходе от анализа к кодированию иерархий, как раз и вылезают всяческие проблемы. В начале девяностых бытовало такое мнение: давайте переносить объекты в домен приложения один к одному, так мы решим всё проблемы с проектированием архитектуры. Примеры типа прямоугольника как раз и приводились, чтобы показать, что тут тоже есть свои сложности, и все решения надо принимать индивидуально.
Вы правы абстракция дело относительное. И если рассматривать объект с точки зрения всех его свойств, то действительно уникальные объекты сложно найти. Но мы то рассматриваем объекты с точки зрения набора конкретных их применений (интересующего нас поведения), а не во всём многообразии. Поэтому не всё так плохо :).
В том то и дело, что в данном случае логическая суть фигуры не важна. Важно только её поведение. Квадрат ведёт себя не так, как прямоугольник, поэтому квадрат не должен наследовать от прямоугольника. Этот момент сложен для понимания, поскольку противоречит общепринятым понятиям. Но с точки зрения правильной иерархии наследования квадрат это не прямоугольник. Определения из геометрии не важны, в программировании далеко не всегда можно переносить существующие в реальном мире связи в модель домена нашей программы.
Возможно, пример с setWidth не самый лучший. Скажем, есть класс прямоугольника и у него есть функция setDimensions(int width, int height).Этот метод вполне хорош для прямоугольника. Для квадрата он не имеет смысла, потому что квадрат ведёт себя не так как прямоугольник. Клиентский код, вызывая эту функцию ждёт, что изменится и то и другое на заданные им величины. Что же делать квадрату? Если он изменит и то и другое это может нарушить работу клиентского кода. Значит, классы прямоугольник и квадрат нельзя свободно заменить друг на друга в программе и это нарушает принцип подстановки.
Надо отметить, что всё это верно только с чисто концептуальной точки зрения. В реальном коде можно и на компромисс пойти, если это сделает код лучше, например уберёт избыточность.
Smalltalk использует подход основанный на duck typing (как в ruby, например). Вызов метода рассматривается, как сообщение посылаемое объекту. Соответсвенно, вы можете вызывать любой метод у любого объекта лишь бы он ответил на него. Интерфейсы, как особые конструкции языка не совсем сочетаются с таким принципом.
Правило, которое говорит, что наследование моделирует взаимоотношение "является", определяет это самое "является" с точки зрения поведения объекта. Это называется принцип подстановки Лисков. Объект в иерархии наследования должен соблюдать контракт своего суперкласса. То есть в частном случае с прямоугольником контракт предлагаемый суперклассом “прямоугольник” утверждает, что, вызывая метод setWidth(), вы измените ширину фигуры и только её. Квадрат нарушает этот контракт, изменяя также и высоту, поэтому ему не место в этой иерархии. В обще случа,е все объекты иерархии должны свободно заменяться друг на друга без нарушения работоспособности системы, потому что они все "являются" объектом их суперкласса, поскольку носят его тип. Квадрат это классический пример этой проблемы. Так же в книгах очень популярен пингвин. Хотя все мы знаем, что он птица, он не умеет летать, поэтому наследовать пингвина от птицы неправильно. Он нарушает поведение, которое должно быть у класса имеющего тип птицы.
Наследование никто не отменял. Просто иерархии должны строится правильно. Лучше всего если по принципу подстановки Лисков.
А вообще мы все в любом случае думаем в терминах интерфейсов. В ооп, не разрушая инкапсуляцию по другому невозможно. Любой класс задаёт так же и интерфейс (интерфейс в общем смысле, а не конструкция языка), который он сам и реализует. Используя любой объект, вы делаете это через его интерфейс. Если объект наследует от кого-то, то мы программируем, используя интерфейс задаваемый этим самым суперклассом.
Интерфейсы, кстати, по определению не могут нарушать инкапсуляцию, поскольку в них нет реализации. Если при программировании с использованием интерфейсов нарушается инкапсуляция, то это не их вина.
Байт тоже иностранное слово. Впервые появилось в английском языке. Вы уж тогда и его переименуйте, раз уж так увлеклись. В языке постоянно появляются новые слова, большинство из них — это заимствования. Особенно их много среди профессиональных терминов, их трогать уж точно не стоит.
Вообще, мне это казахскую инициативу напомнило
habrahabr.ru/blogs/i_am_clever/21302/
При обучении просто не следует делать упор на технологии, конкретный язык программирования или платформа это скорее пример на котором изучаются более общие принципы. Надо изучать архитектуру веб-ориентированных систем, а не программирование на php, ruby или java. Надо изучать не синтаксис потоков в любимом языке преподавателя, а курс конкурентного программирования и т.д. Надо не писать бесполезные скрипты на 1000 строк, а учится работать в команде.
В общем основы несомненно нужны, но кроме них программа обучения многих наших вузом могла бы быть несколько обновлена. Не дело когда человек получивший диплом программиста никогда не слышал о рефакторинге или блочном тестировании.
А мысли об изменении чего либо в ядре фреймворка сразу отбросьте. Кому нужны эти проблемы с отладкой и обновлением :). Да это и не нужно. Zend Framework в плане изменения поведения очень гибок.
www.virginconnect.ru/
Кстати инверсия зависимостей это гораздо более широкое понятие, чем паттерн стратегия. Инъекция зависимостей тоже, она конечно тесно с ним связана, но не тоже самое.
Или вас смущает, что в языке изначально ориентированном на duck typing появились интерфейсы и type hinting?
Насчёт дублирования кода есть ведь разные варианты его устранения можно использовать делегирование, можно использовать миксины (если позволяет язык)
Вы правы абстракция дело относительное. И если рассматривать объект с точки зрения всех его свойств, то действительно уникальные объекты сложно найти. Но мы то рассматриваем объекты с точки зрения набора конкретных их применений (интересующего нас поведения), а не во всём многообразии. Поэтому не всё так плохо :).
Я как то пропустил слово "полностью".
Возможно, пример с setWidth не самый лучший. Скажем, есть класс прямоугольника и у него есть функция setDimensions(int width, int height).Этот метод вполне хорош для прямоугольника. Для квадрата он не имеет смысла, потому что квадрат ведёт себя не так как прямоугольник. Клиентский код, вызывая эту функцию ждёт, что изменится и то и другое на заданные им величины. Что же делать квадрату? Если он изменит и то и другое это может нарушить работу клиентского кода. Значит, классы прямоугольник и квадрат нельзя свободно заменить друг на друга в программе и это нарушает принцип подстановки.
Надо отметить, что всё это верно только с чисто концептуальной точки зрения. В реальном коде можно и на компромисс пойти, если это сделает код лучше, например уберёт избыточность.
А вообще мы все в любом случае думаем в терминах интерфейсов. В ооп, не разрушая инкапсуляцию по другому невозможно. Любой класс задаёт так же и интерфейс (интерфейс в общем смысле, а не конструкция языка), который он сам и реализует. Используя любой объект, вы делаете это через его интерфейс. Если объект наследует от кого-то, то мы программируем, используя интерфейс задаваемый этим самым суперклассом.
Интерфейсы, кстати, по определению не могут нарушать инкапсуляцию, поскольку в них нет реализации. Если при программировании с использованием интерфейсов нарушается инкапсуляция, то это не их вина.