классы для новичков

  • Автор темы Автор темы klax
  • Дата начала Дата начала
Статус
В этой теме нельзя размещать новые ответы.
Есть подозрение что Активист находится в секте черных ООПэшников, порочащих имя белого ООП.
 
x-yuri
Мне понятие "интерфейс" говорит лишь об одном - типизация, или описание.

> Что делает твои классы более взаимосвязанными
Я честно, реально до сих пор не понял, как они могут участвовать в взаимодействии, буду рад послушать ))

Мне очень интересно послушать, когда, например, интерфейсы реально помогали в коде? Реальные истории применения и случаи, когда без них никуда. Я может быть в них чего-нибудь не понимаю, но реальной пользы от них я не увидел.

Можно же описать абстрактным классом. А в случае проверки на принадлежность воткнуть проверку instanceof.

Мой IDE Zend за счет PHPDoc's like комментариев прекрасно понимает что и где, зачем и почему.

-~{}~ 21.01.09 02:24:

HraKK
Вполне возможно, где-то не так излагаю мысль и путаю "определения", но все же это мне не мешает использовать ООП, причем, правильно.
 
но все же это мне не мешает использовать ООП, причем, правильно.
Я честно, реально до сих пор не понял, как они могут участвовать в взаимодействии, буду рад послушать ))
А можно взглянуть на твой фреймворк?;)
 
Мне понятие "интерфейс" говорит лишь об одном - типизация, или описание.
это скорее описание способа взаимодействия, чем типизация

Мне очень интересно послушать, когда, например, интерфейсы реально помогали в коде? Реальные истории применения и случаи, когда без них никуда
что значит никуда? Их надо применять когда в них есть необходимость. А необходимость есть в больших проектах, когда необходимо обеспечить слабую связь между объектами, Т.е. обеспечить более легкую модификацию проекта. А помогают интерфейсы скорее не в коде, а где-нибудь на этапе проектирования

-~{}~ 21.01.09 03:01:

Про ту, что про паттерны на английском - не скажу, ибо не читал, хотя название настораживает, серьёзно про паттерны тебе ещё читать рановато, нужно сначала освоить основные принципы ООП.
Да, она про паттерны. Но автор считает, что паттерны стоит изучать параллельно с изучением ООП, что подтверждается его практикой обучения людей.
Но это не справочник типа книжки банды четырех. Скорее книжка о том, зачем паттерны, как их применять, на каких принципах они построены, как их "выводить" (создавать, приводится логика рассуждений). Есть сравнение проектирования системы методом "выделения существительных (классы) и глаголов (методы)" и с помощью шаблонов проектирования.
Она немного фанатичная: много цитат из "Строительство на века" Кристофера Александра и с этим "на века" авторы немного преувеличивают. Но тем не менее, считаю ее достойной. Мне лично очень понравилось.
В частности, там описывается традиционное представление об ООП и "новый подход"
Не знаю, как она для начинающих. Но, как минимум, она служит хорошим введением в шаблоны проектирования

Котеров мне как-то не понравился, я и не дочитал его

а вот PHP 5 для профессионалов (http://www.ozon.ru/context/detail/id/2847621/) сам читал, хорошая, пытался найти, но в английском издании 2 человека на обложке, а не четыре, поэтому не нашел))) (сначала английскую версию хотел найти)
 
в топку фаулера и банду четырёх, я уже давно пытаюсь дочитать их творения, но читаются они с трудом. лучше как сделал фанат, прочитать описание в двух словах, а дальше посмотреть примеры ООП и паттернов, например, Zend Framework, PEAR. и не забываем мануал http://www.php.net/manual/ru/language.oop5.basic.php
ну а уже разобравшись с этим можно будет понять, что наследование может быть злом, а интерфейсы - не лишняя писанина.

p.s. Всё сказанное относится к новичкам
 
ну а уже разобравшись с этим можно будет понять, что наследование может быть злом, а интерфейсы - не лишняя писанина.
да, только на своих ошибках тоже можно учиться
 
Автор оригинала: AmdY
в топку фаулера и банду четырёх, я уже давно пытаюсь дочитать их творения, но читаются они с трудом
Кому как. Я когда банду четырех прочитал, пусть даже не всю, а только вводную про ооп и те патерны, что в веб можно удачно применить, так сразу все на свои места встало в голове.
лучше как сделал фанат, прочитать описание в двух словах, а дальше посмотреть примеры ООП и паттернов, например, Zend Framework, PEAR. и не забываем мануал http://www.php.net/manual/ru/language.oop5.basic.php
ну а уже разобравшись с этим можно будет понять, что наследование может быть злом, а интерфейсы - не лишняя писанина.
в ZF без хорошей матчасти даже соваться не стоит. По-моему, лучше сначала говноцмс написать и поняв это прийти к ZF, а то можно сразу на нём ее написать и думать, что у тебя крутой ооп :)
 
как только поднимается тема про ООП, то тут сразу же начинается поедание друг-друга: каждый хочет покритиковать предыдущий ответ и доказать собеседнику, что его понимание ООП полностью неправильное.

расслабтесь.

-~{}~ 21.01.09 10:28:

а вот PHP 5 для профессионалов (http://www.ozon.ru/context/detail/id/2847621/) сам читал, хорошая
далеко не хорошая. я бы сказал, не такая хорошая, как хотелось бы для КНИГИ. ОО-пример с музыкальными инструментами (вроде) ничего так, иллюстрирует ООП. А вот остальное понимание у меня вызвало проблемы - огромные листинги и имена методов типа getParamFromDatabaseFromServerNumberOne()

-~{}~ 21.01.09 10:30:

и вообще, основная проблема ООП, ИМХО, это создание ORM. В остальном ООП не представляет никакой сложности.
 
и вообще, основная проблема ООП, ИМХО, это создание ORM.
Это не проблема ООП. Это проблема соединения разнотипных технологий - реляционной и обьектной. Возьми обьектную СУБД — и тебе не нужен будет этот по сути, нелогичный ORM.
 
Это не проблема ООП.
ну да, ну да :)

Возьми обьектную СУБД — и тебе не нужен будет этот по сути, нелогичный ORM.
я ещё с реляционной толком то не умею работать.. хотя надо как-нибудь попробовать. дя. ня.
 
далеко не хорошая. я бы сказал, не такая хорошая, как хотелось бы для КНИГИ. ОО-пример с музыкальными инструментами (вроде) ничего так, иллюстрирует ООП. А вот остальное понимание у меня вызвало проблемы - огромные листинги и имена методов типа getParamFromDatabaseFromServerNumberOne()
что-то я не увидел тут аргументов против, ты просто придираешься. А по поводу огромных листингов, я видел книжку, в которой листинг создавался пошагово, причем приводились все промежуточные варианты))))
кстати, я сказал хорошая, а не плохая, и не отличная
 
в топку фаулера и банду четырёх, я уже давно пытаюсь дочитать их творения, но читаются они с трудом
Т.е. ты не осилил - значит в топку? Я начал вкуривать в ООП именно с "Архитектуры корпоративных программных приложений" Фаулера.. Только потом были все остальные труды по ООП, но Фаулер - да бест, имхо.
У меня где-то дома валяется книжка "Введение в ООП для начинающих", так там все примеры даны на псевдоязыке "Черепашка" :)
 
Т.е. ты не осилил - значит в топку?
конечно, я всё меряю по себе. я осилил ООП по справочнику, уже не помню точного названия, достаточно было 1 страницы текста, тем более там была книга только по PHP. а вот целую книгу неподготовленному было бы прочитать тяжело. И я рад что не пытался освоить всё сразу.
 
конечно, я всё меряю по себе. я осилил ООП по справочнику, уже не помню точного названия, достаточно было 1 страницы текста, тем более там была книга только по PHP. а вот целую книгу неподготовленному было бы прочитать тяжело. И я рад что не пытался освоить всё сразу
просто ты так сказал, как будто Фаулера и "банду четырех" не стоит читать не только начинающим. "Банду четырех" ТС никто не советовал, а про Фаулера уже высказались
 
что-то я не увидел тут аргументов против
тема сисек в этой книге раскрыта не более, чем в других учебниках по пхп. :P

действительно тяжело читается. Это больше справочник, чем руководство по ООП. Начиня рассказывать про один паттерн, он упоминает сотню других, читателю ещё не знакомых. Вот и приходится перечитывать.
 
Ребят, а ООП и типовые решения — вообще-то соооовсем разные вещи.

Типовые решения нужны для подготовки(поддержания в состоянии) приложения для его расширения, изменения и улучшения. Кроме того, есть архитектурные типовые решения — эти должны применятся ДО разработки приложения, для подготовки(поддержания в состоянии) приложения для его расширения, изменения и улучшения.

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

И все.

А ООП — это всего лишь ООП.
 
Завязываем бросанием какашек в песочнице друг в друга.
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху