Мне давно не даёт покоя следующий вопрос. Чем объектно-ориентированный проект отличается от процедурного? Дьявол, как мы все знаем, кроется в деталях. Понятно, что ООП - это не просто использование классов и объектов в своём коде. Читая четвёртое издание Зандстры, этот вопрос всплыл для меня на поверхность. Вот что пишет Мэтт: Буду благодарен любому кто сможет на пальцах и с простым примером объяснить сабж. Добавлено спустя 6 минут 54 секунды: Про этот момент поподробнее. По сути объекты - это ведь сгруппированные функции и ассоциированные с ними переменные. Почему нельзя минимизировать зависимости в процедурном коде путём передачи ответственности за управление задачами функциям ?
Вот бы кто-нибудь сделал простой наглядный пример, как выглядит ООП в коде, а то миллион умных слов, а понимание то все дальше и дальше.
Объектный подход - эта работа с абстракциями. Самое важное в ООП - это полиморфизм объектов, когда вы можете написать метод c(), который ожидает объекты класса A, а передать в него объект класса B, унаследованного от A - и всё будет работать. Т.е. методу c() всё равно, что вы в него засунете, лишь бы в интерфейсной части содержала то, что содержится в A - таким образом и минимизируется зависимость. На этом и основаны методы минимизации связей
machetero, если у тебя есть много времени и желания, попробуй сам сделать CRUID форму на ООП, и просто на функциях (; половина вопросов сами отпадут (
p@R@dox 55RU, ушёл в поисках того что значит CRUID. Время благо пока есть. Буду пробовать. Добавлено спустя 6 минут 5 секунд: p@R@dox 55RU, не CRUID я уже делал, вопросы не отпали. Вообщем я понял что надо копать в сторону связности и зависимости функций/методов. Я про это уже слышал в книге "Совершенный код". Но у меня ещё не тот уровень чтоб это понять.
Я же писал, вопрос в том был чем ООП отличается от процедурного подхода концептуально. Концептуально Карл !
само название говорит о концепции (; хороший пример на сегодня, это когда в твоем проекте есть, например, папка( модуль), пусть назовем его USER. Название класса будет таким же уникальным, как и название самой папки, соответственно class USER. При процедурном подходе, ты можешь создать названия функций, которые уже раннее были определены, и тут начинается геморрой, при работе приложения ((
Ооп это инкапсуляция. Т.е. два экземпляра класса хранят каждый свои данные и могут иметь отличающиеся, хотя и называющиеся одинаково методы. Т.е. они сами как бы контролируют правильность применяемых алгоритмов.
да это инфы по интернету как окурков в курилке, а вот хотя бы один конкретный пример, приложение в качестве примера.
VLK конкретный пример, смотри абстрактные классы, интерфейсы которые так же рассматриваются в книге того же автора который приведен выше.
http://framework.zend.com/manual/current/en/user-guide/overview.html там и ООП и MVC, плюс еще куча интересных полезностей ((