Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: ООП
 
 автор: chip   (03.11.2004 в 04:32)
 
 

Помогите понять сущность Объектно-Ориентированного програмирования
Привидите простые примеры применения .
Где стоит применять ООП а где лучше обойтись лучше без него!

   
 
 автор: cheops   (03.11.2004 в 10:45)   письмо автору
 
   для: chip   (03.11.2004 в 04:32)
 

Примеры по ООП можно найти по ссылке
http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=161
Если у вас будут вопросы задавайте - постараемся ответить на все.

1)Использование ООП в PHP вопрос достаточно дискуссионный. Эта технология создавалась для того, чтобы перейти рубеж в программе в 100 000 строк кода - это программный комплекс, который можно без труда модифицировать и сопровождать используя процедурный подход. Например огромные библиотеки пишутся с использованием ООП - это позволяет здорово упростить их разработку так как строится "вертикаль" :) полномочий и более новые классы "помнят", то что делают старые. Модифицировать такие библиотеки очень просто - достаточно отнаследовать класс. Но в PHP с областью видимости один файл, и небольшими скриптами такие размеры кода не очень актуальны, так как задачи необходимо решать в пределах одного файла, размер которого менее 1000 строк. Даже phpMyAdmin написан с использованием процедурного подхода.

2) Чистая ООП программа всегда медленее и менее эффективна чем процедурныая - это везде, даже в С++, где нет накладных расходов на использование классов. Под чистой я имеею ввиду, когда класс можно взять из программы и использовать в другом месте, а не когда они сплетаются таким образом, что один без другого работать не может - создать чистые классы - это тяжёлая работа, требующая тщательного проектирования - при создании Web-приложений, часто с очень малыми сроками реализации на это нет времени и вся мощь ООП сводится на нет тем, что код просто не возможно читать. Соблазн срезать на повороте для того, чтобы увеличить эффективность очень велик - программа получается запутанным клубком.

PS Это вовсе не значит, что ООП не следует использовать в PHP, но лично я не видел задач, где бы ООП был эффективнее, чем процедурный подход. Хотя я сам очень люблю OOП и применяю его при программировании на С++, в PHP предпочитаю использовать процедурный подход - код проще, эффективнее, время разработки меньше, а до PHP 5 средства ООП были реализованы не полностью.
PPS ООП позволяет ещё более структурировать программу по сравнению с процедурным подходом, либо за счёт времени разработки, либо за счёт эффективности программирования (это как системы реального времени, которые медленее обычных операционных систем, так как остаток времени до реперной точки машина просто бездействует :), здесь цель тоже достигается за счёт эффективности). Наделать архитектурных ляпов в ООП так же просто как и в процедурном подходе.

   
 
 автор: chip   (04.11.2004 в 01:43)
 
   для: cheops   (03.11.2004 в 10:45)
 

ну вот к примеру есть классы для отправки почты
Зачем они нужны когда можно обойтись и без них
и строк там все же менее даже 1000 ?
Ну вот к примеру как можно применить ООП для форума или гостевой книги(тут уж янаверно загнул) :) ?

   
 
 автор: cheops   (04.11.2004 в 09:58)   письмо автору
 
   для: chip   (04.11.2004 в 01:43)
 

Классы хороши в том случае если они готовы и в их код не нужно лезть, т.е. при использовании их как библиотеки. Для меня идеальный класс для отправки почты следующий:
-он сам проверяет корректность ввода почтового адреса
-может отправить письмо как с вложением так и без.
-если первый аргумент массив e-mail - проверить и отослать письмо по ним
<?php
  
include "mailclass.php";
  try
  {
    
$ml = new mailclass("softtime@softtime.ru","Здравствуйте","тест","/path/to/file");
    
$ml->send();
  }
  catch (
Exception $e)
  {
    echo 
$e->getMessage();
  }
?>

массив
<?php
  
include "mailclass.php";
  try
  {
    
$email = array("softtime@softtime.ru","cheops@softtime.ru","simdyanov@softtime.ru");
    
$ml = new mailclass($email,"Здравствуйте","тест");
    
$ml->send();
  }
  catch (
Exception $e)
  {
    echo 
$e->getMessage();
  }
?>

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

   
 
 автор: chip   (05.11.2004 в 01:27)
 
   для: cheops   (04.11.2004 в 09:58)
 

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

   
 
 автор: cheops   (05.11.2004 в 01:38)   письмо автору
 
   для: chip   (05.11.2004 в 01:27)
 

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

   
 
 автор: chip   (05.11.2004 в 02:16)
 
   для: cheops   (05.11.2004 в 01:38)
 

ну я так разницу и не уловил а чем проще то будет ведь
функцию тоже дописал и все.
сколько книг перелопатил везде пишутся как и что но а зачем ... про это мало пишут :(

   
 
 автор: glsv (Дизайнер)   (05.11.2004 в 11:06)   письмо автору
 
   для: chip   (05.11.2004 в 02:16)
 

>ну я так разницу и не уловил а чем проще то будет ведь
функцию тоже дописал и все.

Как и говорил cheops, если у Вас будет более 100000 строк кода, то при процедурном подходе вы уже не сможете обеспечить нормальный процесс внесения изменений. Слишком много кода и слишком запутанные взаимосвязи…
Вы не сможете просто так найти эту самую функцию и просто так внести в нее изменения

А при ООП – это уже не будет ограничением.

   
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования