ладно, примерно понял.. Только не видят проблем те, кто это умеет  делать  

Тогда вопрос в развитие темы.. Я разбирался в разных готовых скриптах и вижу что все спользуют классы. Я почему-то обхожусь одими функциями. Есть ли вообще смысл в классах (немного не так спросил  ) , т.е. как сильно это облегчает или ускоряет работу?

Это сообщение отредактировал(а) Gold Dragon - 28.12.2006, 07:24

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

ЗЫ. Могу посоветовать почтитать на досуге Гради Буч-а "Объектно-ориентированный анализ и проектирование". Занимательная весч 

Добавлено @ 10:35 
Тем более что в пятом PHP полностью переработана объектная модель 

Gold Dragon, разницы в подходе - никакой. Реализация просто несколько более запутанная и менее структурированная получается.

Т.е.?! Можешь пояснить?

-=Ustas=-, когда ты пишешь на ООП, ты в нужном месте делаешь $obj = new MyModulClass(), где MyModulClass - класс подключаемого модуля. Получается универсализм. Дальше работает уже сам модуль, через конструктор.
Тоже самое с функцями. Ты вызовешь какую-ть MainMyModulFunction, которая примет управление на себя и дальше будет вызывать те функции модуля, которые ей надо. Т.е. ядро только вызывает главную функцию модуля. Все. Ядру плевать что будет делать сам модуль.

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


Ладно, Mal Hack, я прекращаю, ибо пахнет "ПОП vs ООП"  

-=Ustas=-, это все так, ты прав, но моей ключевой мыслью было то, что:


Уж как это будет представлено - другой вопрос, ООП так ООП, СП, так СП.



Давай будем реалистами. Применительно к PHP, объекты все равно несут лишь информационную модель скрипта, событиыйности-то нету 

Ну объектной модели PHP еще ползти  Хотя в 5-ой значительные измения.

Ну это уже парадигма, сложенная на протяжении нескольких тысячилетий ) Если же ядро будет контролировать еще и модули, то это не будет являться модульной архитектурой  Высказался немного утрировано, но думаю понятно 

Но событийности, без изменения концепции языка, в нем все равно не будет.

а если взять конкретно OOП и PHP?
ведь по сути обьекта удобно это когда он существует "лопатя" запросы и т.д.
а в PHP важно в тоже время скорость обработки запроса 
кстати давно задумывался над PHPшными демонами 

Это уже надо смотреть на конкретной реализацией.



Все-таки это не PHP'шное дело.

 если есть в электронном виде, с удовольствием почитаю..

Так народ, что такое ПОП и ООП? 

всё равно не могу понять... Вот как я делаю.. Просто создаю разные функции: одна подключает бызу, другая получает данные, третья запихивает в базу. На сколько я понимаю, класс это тоже самое, только подключается чуть по другому и помоему код больше получается

ООП - объектно ориентированное программирование.
ПОП - процедурно-ориентированное, если я правильно понял. Мы его просто структурным называли.


Да тоже самое. Только при ООП у тебя все эти функции как бы в одной переменной лежат. Ну плюс добавляются разные вкусности типа уровней доступа, свойств, что делает процесс кодинга удобнее.

давайте на примере если не трудно.. вот пример моих функций


как это заменить на класс?


ps
кто-то обещал доку про классы.   

Gold Dragon, а что это? 

я там малость ошибся... первая функция називается fConnect 

Mal Hack, т.е. я тупо все свои функции загоняю в класс и получаю к ним доступ через $obj -> что-то??

Тогда нет никакой разницы между

и

Наверное это самое примитивное использование классов и там есть что-то такое, чего я ещё не понимаю..  Но согласен, что класс - это всё же один объект, а не набор разных функций, что уже удобнее чисто для восприятия



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

Угу

  
Потести смарти и сразу поймешь, что такое целостый класс...
 
Недавно с другом готовились сдавать Удаленные базы данных, ну он вообшем ламер полный, спросил че такое класс, я подумал подумал и ответил, что это коллекция методов (функций)... Хотя ответ не раскрывает все сути, но в целом становиться яснее...
Кроме того все методы связанны между собой=) 

Вот примерчик юзанья класса.. может не самый удачный... но я именно с этого момента понял, что классы лучше функций (когда писал код)

http://www.firststeps.ru/theory/oop/r.php?2

Mal Hack, очень вредный пример. только отпугивать от применения ООП годится 

В продолжение начатого Opikом: OOP Concept explained: Polymorphism (Technology) -- простое и ясное объяснение полиморфизма

Opik, без обид, но статья ни о чем 
Точнее она о основах ООП, как о его возможностях при реализации тех или иных вещей, но нет ни слова, относительно того, что такое ООП для проектирования... К сожалению, инет кишит такими статьями, а сути, которая не в реализации и возможностях, а в теории проектирования нигде нет... ИМХО, конечно.


Интересно чем? Что я показал базовый синтаксис описания класса и создания объекта?
Да и вашего "не вредного" примера я тут что-то не видел.

А может кто нибудь даст почитать по теме? А то никак не могу найти. Нужно что бы было применимо именно к PHP. И что бы на русском. 

Из того, что видел я (и писал сам), могу предложить:
http://phpclub.ru/detail/article/oop-vs-proc
http://phpclub.ru/detail/article/intro_php5
http://vingrad.ru/PHP-ART-002848

 

Я плакал, новички теперь будут счастливы писать на ООП )))

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

Mal Hack, 
Ну как не как новичок врядли решит программироваться на том примере, где 7 строк, когда есть пример в 1 строку=))

Еще раз объясняю для тех кто на подлодке.
Ты будешь новичку показывать основы синтаксиса и применения ООП в PHP на модуле из 1000 строк? Нет.
Я говорю о том, как показать основы. Чтобы человек решил использовать ООП, он должен до этого дорасти, тобишь осознать ТЕОРЕТИЧЕСКИЕ аспекты ООП, а не код на 1000 строк.

Mal Hack, 


  Верно... 

тока получается новичку вообше нет смысла показывать плюсы ООП+))

Скорее тем, что после такого примера кроме усложнения синтаксиса преимуществ не ощущается..



Мне тоже лень что-то обильное писать, но ща поднатужусь..

Я не так не считаю, там на явном примере поясняется смысл.
Читайте тогда здесь: http://www.intuit.ru/department/se/tppobj/

Что-то вроде этого..
Опять таки упрощенно и "на коленке" в блокноте написанное. Может и не запуститься

Вот честно, перечитал еще раз... Уже зная что такое ООП не могу ну никак соединить этот пример с ООП. Да, отдалено суть показывает, но отдаленно. Но, ИМХО, конечно же.



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


Тогда какого черта надо сюда это постить !!


Почитай внимательнее о чем я с BuShaRt'ом дискутировал... Тоже самое и в твоем случае.

Многоуважаемый Мал Хак.
Грубите, пожалуйста, своей бабушке! Вы же модератор..




Любые основы должны демонстрировать преимущества. Например уменьшение количества строк кода, функциональность и удобство в применении.

Я считаю неуважение к участникам форума выкладывать код, который: "Может и не запуститься".

http://forum.vingrad.ru/index.php?showtopi...st&p=979753

Вопросов больше не имею

Gold Dragon, я тебе говорил за эту литературу, на мой взгляз неплохие труды в плане теории. Объектно-ориентированный анализ и проектирование. Потом можно заодно и Страуструпа почитать.

Это сообщение отредактировал(а) -=Ustas=- - 3.1.2007, 23:55

Вообще каждой цели свои методы.
Там где надо написать hello world я буду писать hello world
А там где пахнет модулем - class hello { functuion message(){print(__CLASS__.' world'); } }

Думаю так )

Так, народ, я хоть и новичок, но создать class hello в состоянии. Меня больше интересует не элементарное использование, а именно то, что другими способами сделать труднее.



PS 
кстати, тему лучше переименовать с Философия class 

Добавлено @ 10:44 

кстати, очень понравилась статья
http://vmk.ugatu.ac.ru/book/buch/index.htm

правда пока только начал читать

Gold Dragon, потом как ты ознакомишься с теорией ООП, советую прочитать Обзор паттернов проектирования, чтобы ты имел представление где и как строить архитектуру классов и самого приложения ;)

Большая задача. Большое кол-во переменных. При структурном подходе ты был вынужден каждую через global подключать или через параметры передавать, а при объектом тебе достаточно ее один раз в конструкторе в свойство записать и затем с ним работать.

вот! это уже интересно. Если честно, то для меня это уже стоновится проблемой.

 Как это нету? Когда нто лишь недостаток реализации определенной программы, в которой ее нету.

Если хочется понять ООП в PHP - имхо нужно читать литературу по ООП, в которой все примеры демонстрируются на PHP, а не на других языках...

Вообще, я смотрю ООП мало кому дается так легко  Буквально год назад я вообще не понимал зачем это нужно, какой из этого толк и вообще "функции рулят". Когда перечитал несколько статей о ООП в PHP от разных авторов и понял основы, все равно не примеял его. Но постепенно начал сталкиваться с задачами и вспоминая основы ООП задумывалвася "А ведь это можно написать с использование классов, получится проще и красивее". Сейчас время от времени применяю.

Ну тут ты в корне не прав, и я могу тебе это доказать и даже убедить тебя. ООП - это Объектно-Ориентированный Подход, а на каких языках - это уже по-барабану. Да, я согласен, в некоторых языках такая объектная модель, в других такая-то, но теоретическая основа везде аналогична, и ОБЪЕКТ он и в африке объект. Поэтому прежде - МАТ-чать!

Если будет выбор книг: ООП, ООП в (Visual Basic || Delphi || C++), ООП в PHP. Объем книг одинаковый, автор у всех вменяемый. Я бы выбрал ООП в PHP. Теория подкрепляется примерами на самом PHP. Если мне нужно понять ООП вообще и использовать его в PHP, этот выбор будет разумнее чем книга про просто ООП, и тем более про ООП в других языках.

А что, много книг про ООП в ПХП?   
Насколько я знаю, это не так ;)

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

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

- 3 группы текстов
- по 50 в каждом
- нестандартная верстка

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

ООП там где много повторного кода.

ООП - как стиль программирования. Кто-то его придерживается, а кто-то - нет. Каждый выбирает сам для себя. ООП - структурированная модель. Удобно в больших приложениях. Функция - для маленьких приложений или старых версий языка. Переносить, например, приложение с PHP5 на PHP4 удобнее, если использовать функции.

Слушайте, подобная тема "объектное vs процедурное" уже далеко не актуальна, по интернету подобных обсуждей как грязи. Чтоб понять ху из ху, нужно взять любую книгу какого-нить ООриентированного языка, пусть тот же C++ или Java (есть и просто теория) , там в первых главах обзательно эта тема затрагивается, после прочтения которых вопросы у вас сами отпадут.

Добавлено через 4 минуты и 20 секунд
Ну... не все вопросы конечно, сразу отпадут, но часть эт точно, а после практической реализации точно все.

Каждый подход применим к своей задаче.
Хороший программист должен писать хороший не только ОО код, но и функциональный и структурный.

CMS Drupal - пример, где модули пишутся исключительно с использованием функционального подхода. И я почему-то совершенно не видел каши, рутины или грязи. В тоже время встречал исключительно объектные проекты, в которых было разобьраться почти не реально. ПРограммируя на php использовать ооп нужно там где это нужно, а не везде, как мне кажется. Ибо это не Java и не C# (и не руби..), где ооп есть основа всего и вся.
Моё ИМХО - пытаться писать на пхп исключительно объектно - это будет лишь пародия на системы написанные на исключительно объектных языках.

А я видел 


Мотивируйте, пожалуйста. А так же поясните, что такое "исключительно объектно".

"Исключительно объектно" - это значит что нельзя сложить 2 числа не создав класса. А "ИМХО", на сколько я знаю в мотивациях не нуждается...


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

koreshX, абсолютно объектно-ориентированным языком можно назвать разве-что руби, да и то с натяжкой, по этому не надо гиперболизировать.
очевидно, что автор подразумевал разумное использование возможностей ооп, которыми наделен php

Это сообщение отредактировал(а) WolfON - 24.5.2007, 00:40

На мой взгляд ООП более приемлем, чем ПОП хотябы потому, что окружающий мир состоит из объектов (экземплятов классов, если угодно), а не из функций (читай действий) и имеет след. преимущества:

 1. Повышается понимаемость кода. Возьмем, напр., ф-ю __стрелять(). Снайпер стреляет по мишени, бомж стреляет сигареты, девушка стреляет глазками. Используя ПОП необходимо либо передавать доп. параметр "кто_стреляет", либо использовать префиксное именование ф-ций, а отсюда вторая выгода:
 2. Отчасти решается проблема именования. 
 3. Пусть у девушки есть ещё методы кроме __стрелять(), напр. __могу_ли_охмурить(), __могу_ли_съесть_пирожное(), __надо_ли_худеть() и пр.. Все они зависят от огромного числа параметров (рост, вес, объем груди, талии и бедер, харизма, наличие косметики и т.п.). В ООП достаточно задать эти параметры единожды для объекта, а в ПОП вам каждый раз придется описывать девушку передавая кучу её параметров в каждую ф-ю пусть даже и массивом.
 4. Мы можем заставить всю нашу компанию (снайпер, бомж и девушка) стрелять по одной команде (__стрелять()), т.к. все они имеют таковой интерфейс. 
 5. Так же легче добавлять новых членов в нашу компанию (спина напр. тоже может __стрелять()).
 6. Наша компания может состоять и из нескольких девушек (объектов одного класса), кот. тоже можно заставить стрелять по одной команде. Все будут делать это примерно одинаково, но каждая немножко по своему в зависимости от параметров (см. п. 3).

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

Процедурный подход хорош для чисто вычислительных задач, т.к. так же далек от реальности как и "чисто вычислительные задачи".

Р.S. А понимать ООП проще все же вообще в отрыве от языка. Главное - понять концепцию. А ее реализация в каждом конкретном случае (читай - ЯП), это лишь вопрос синтаксиса и наличия/отсутсвия некоторых возможностей.

P.Р.S. Все вышесказанное - мое ИМХО.

Перехожу на ООП... постепенно. Преписывать старые проекты не буду. Но новые начну с ООП.

WIPS,
Он не изучен даже до конца, не то чтобы сделаны однозначные выводы и построена четкая модель  Сходство, конечно больше, но все равно это сомнительный довод.


Но никуда не денешься от реализации всех функций "стреляния" т.е. именно кода который за них отвечает и реализации огромного кол-ва классов. Но их избыточность это совсем не хорошо.

Это сообщение отредактировал(а) Sergey912 - 26.7.2007, 02:22

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

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

Вот ты не понимаешь, ты не видел абстрактную сторону

Кто это "он"? Который не изучен до конца?


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


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


Полностью согласен. Это то, что я пытался сказать в своем посте.


В чем же заключается это самое "понимание программирования"?

Насколько я знаю класы нужны только для того чтобы секономить время!

То есть можешь написать ту же програму без класов, но получится в 3 раза длинее и медленее!

Не совсем. Класс позволяет поделить программу на конкретные модули, которые ты можешь переиспользувать. Самый большой плюс сановит удобство

Не говори глупостей, пожалуйста. Модули это модули. Классы это классы. Никакой связи между собой они не имеют...
На функциях теже самые модули так же совершенно спокойно делаются.

Разве? Кто еще со мной несогласен на счет модулей в форме классов?

модули не обязательно классы и наоборот.

Daevaorn, а я не говорил что обязательно, и это все образно. Каждый понимает модуль по своему.

Еще плюс - возможность задания способов обработки данных, скрытых в классе. Функциями этого никак не добьешься.


Что в вашем понимании модуль?

Diesel Draft, модуль это не образно....

Модуль - это программная единица, куда вынесены куски программного кода, разделенные по смысловой и модульной нагрузке.