научите меня программировать на php oO

[tf]

научите меня программировать на php oO

точнее на ooп php
чо то я его не очень понимаю

 

[Духовность™]

я тоже не умею (
из-за того, что у меня нет фреймворка, я не могу себе сайт сделать. а планов куча (

 

[Lightning]

triumvirat
возьми mzz

 

[Long]

приходи к нам работать

 

[Духовность™]

возьми mzz

я смотрю mzz, но у меня чисто спортивный интерес к программированию.

 

[Alexandre]

точнее на ooп php
чо то я его не очень понимаю

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

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

так же есть принцип Открытия-Закрытия: программные объекты (классы) - должны быть открыты для расширения и закрыты для модификации. Определивши единожды контракт (интерфейс) должны быть веские причины для его изменения.

есть еще Принцип инверсии зависимостей: "модули более высоких уровней не должны зависить от модулей более низких уровней", или ближе к жизни - если ты определил класс AbstractDB, то используя его интерфейс не должено быть каких либо зависимостей от производных классов ( MySQL , PgSQL, MsSQL etc )

ну и напоследок хотел бы сразу дать совет - осваивай паралельно Unit тестирование. Очень полезно, я использую SimpleTest
Написал класс и сразу к нему тест, вернее теория предполагает - написал тест, и начал писать класс.
1) по тестам понятно как пользоваться классами
2) если в процессе рефакторинга стал изменять какие-то классы - то быстро по тестам найдешь те упущенные связи, где ты забыл что-то пропатчить под новые интерфейсы (контракты).

вообще я не считаю себя большим специалистом ООП, мои рекомендации через час титаны ООП раскритикуют в пух и прах...

-~{}~ 04.07.09 00:42:

но у меня чисто спортивный интерес к программированию.

что-то по вопросам не похоже... новичком прикидываешься????

-~{}~ 04.07.09 00:44:

я тоже не умею (
из-за того, что у меня нет фреймворка, я не могу себе сайт сделать.

у меня тоже нет фреймворка, но я не плачу и тоже давно собираюсь сделать себе сайт.

 

[AmdY]

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

 

[Lightning]

Вообще PHP не самый лучший язык для изучения ООП.
ИМХО, чтобы лучше понять ООП нужно попрограммировать на более объектно-ориентированных ЯП.
"Рефакторинг" и "паттерны проектирования" действительно хорошие книги для понимания техник ООП. Тут еще рекомендуют "Архитектуру корпоративных приложений", но, ИМХО, далеко не все, что написано в этой книге, применимо для web.

 

[Krishna]

чтобы лучше понять ООП нужно попрограммировать на более объектно-ориентированных ЯП

Можно примеры более ОО языков с пояснениями, чем именно они более ОО?

 

[Lightning]

Krishna
Конечно.
Java - реализация почти классического ООП, за исключением некоторых мелочей.
Smalltalk - классический ОО ЯП.

Подробные пояснения найдешь сам, ок?

 

[nerezus]

Lightning
с пояснениями, чем именно они более ОО?

 

[Krishna]

Подробные пояснения найдешь сам, ок?

Не, не "окэ".
Либо ты приводишь пояснения, либо я делаю вывод, что ты не в теме.

Smalltalk - классический ОО ЯП.

Да, я тоже в курсе, что дядя Фаулер так думает
Только, боюсь, ты сам не владеешь Smalltalk и пояснений по нему от тебя не дождаться.

Походу, и Явой тоже. Иначе, наверное, был бы в курсе, что ООП-составляющую пыха с неё практически срисовывали

 

[HEm]

Меня больше всего напрягает вопрос - КАК выбирать сущности? Чтобы не зарыться в слишком низкоуровневые вещи или наоборот. Есть какие то правила для этого или это приходит только с опытом? Оно, зараза, еще и от задачи зависит ведь.

 

[zerkms]

Lightning
озвучь пожалуйста, необходимые и достаточные признаки ОО языка.
а заодно - техники количественного или качественного (абсурд?) анализа, позволяющие выделять более и менее ОО языки.

 

[Krishna]

Меня больше всего напрягает вопрос - КАК выбирать сущности? Чтобы не зарыться в слишком низкоуровневые вещи или наоборот.

Классический подход - сущности должны соответствовать объектам реального мира. А для зарывания или выкапывания из низкого уровня на крайний случай существует рефакторинг. С первого раза идеального проектирования для более или менее серьёзной задачи всё равно не бывает.

 

[grigori]

я учился по мануалу джавы

 

[HEm]

Krishna
вот и беда - то ли сущность "мебель", то ли "стол", то ли "ножка"
впрочем

существует рефакторинг. С первого раза идеального проектирования для более или менее серьёзной задачи всё равно не бывает.

это ответ, который я хотел услышать
идеальных методик нет

 

[x-yuri]

My mistake had been in trying to create the classes in my problem domain and then stitch them together to make a final system, a process that Alexander calls a particularly bad idea. I had never asked whether I had the right classes because they just seemed so right, so obvious; they were the classes that immediately came to mind as I started my analysis, the "nouns" in the description of the system that we had been taught to look for. But I had struggled trying to piece them together.

When I stepped back and used design patterns and Alexander's approach to guide me in the creation of my classes, a far superior solution unfolded in only a matter of minutes. It was a good design, and we put it into production. I was excitedexcited to have designed a good solution and excited about the power of design patterns. It was then that I started incorporating design patterns into my development work and my teaching.

Christopher Alexander's approach is to focus on the high-level relationshipsin a sense, working from the top down. Before making any design decision, he feels it is essential to understand the context of the problem we are solving. He uses patterns to define these relationships. However, more than just presenting a collection of patterns, he offers us an entire approach to design

Design Patterns Explained - A New Perspective on Object-Oriented Design, Second Edition, Alan Shalloway, James R. Trott
ну это так, в качестве другого подхода

 

[Lightning]

Krishna

Либо ты приводишь пояснения, либо я делаю вывод, что ты не в теме.

А если приведу, то ты успокоишься или будешь и дальше продолжать провоцировать никому не нужный спор?

 

[nerezus]

Lightning попробуй привести. В пхп все с джавы слизано в плане синтаксиса.
Ну кроме анонимных классов и неймспейсов.