Форумы портала PHP.SU » Разное » Обсуждение статей » ООП с самого начала

Страниц (4): [1] 2 3 4 »
 

1. DeepVarvar - 12 Ноября, 2011 - 19:30:53 - перейти к сообщению
Вторая попытка написать что-то полезное.
Надеюсь что не последняя Закатив глазки

---

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

PHP и ООП

Что же это такое? Кому и зачем оно нужно?

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

Так собственно не откладывая далее саму суть, начнем.

1. Функции

Небольшой откат назад нужен для того, чтобы освежить память о пользовательских функциях. Собственно типичная пользовательская функция выглядит так:
PHP:
скопировать код в буфер обмена
  1. function userFunction() {
  2.         // TODO что-то делаем
  3.         }

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

2. Абстракции

Как правило "в жизни" требуется писать не мало кода для какого либо функционала. Однако каждое действие можно разбить на самостоятельные завершенные "события". Если задуматься, то функции решают эту проблему с головой, если каждую описать как завершенное "событие". Да, в общем это неплохо. Написать с десяток функций которые будут работать с базой данных. Действительно, а зачем каждый раз повторять одни и те же действия на разных страницах сайта, или по нескольку раз на одной странице. Например:
CODE (htmlphp):
скопировать код в буфер обмена
  1. <?php
  2.  
  3. $result = mysql_query("SELECT name1, name2 FROM supertable");
  4. if (mysql_num_rows($result) > 0) {
  5.  while ($row = mysql_fetch_assoc($result)) {
  6.    echo '<div>'.$row['name1'].' --- '.$row['name2'].'</div>'."\n";
  7.    }
  8.  }
  9.  
  10. ?>
  11.  
  12. <div>
  13. ... какое-то хтмл-***** ...
  14. </div>
  15.  
  16. <?php
  17.  
  18. $result2 = mysql_query("SELECT name45, name56 FROM supertable2");
  19. if (mysql_num_rows($result2) > 0) {
  20.  while ($row2 = mysql_fetch_assoc($result2)) {
  21.    echo '<div>'.$row2['name45'].' --- '.$row['name56'].'</div>'."\n";
  22.    }
  23.  }
  24.  
  25. ?>
  26.  
  27. <div>
  28. ... опять какое-то хтмл-***** ...
  29. </div>


и т.д...

Гораздо удобнее будет отписать все повторяющиеся действия в функциях заранее и просто вызывать их по коду дела, когда будет нужно:
CODE (htmlphp):
скопировать код в буфер обмена
  1. <?php
  2.  
  3. // в этом коде нужно описать вообще всю логику страницы
  4.  
  5. function query($query_string) {
  6.  $result = mysql_query("$query_string") or die(mysql_error());
  7.  $arr = array();
  8.  if (mysql_num_rows($result) == 0) return null;
  9.  while ($row = mysql_fetch_assoc($result)) $arr[] = $row;
  10.  return $arr;
  11.  }
  12.  
  13.  
  14. $result1 = query("SELECT name1, name2 FROM supertable");
  15. $result2 = query("SELECT name45, name56 FROM supertable2");
  16.  
  17.  
  18. // вот сейчас закроем тег и все, дальше только хтмл с пхп-циклами вывода
  19. // Никаких расчетов! Только вывод!
  20.  
  21. ?>
  22.  
  23. <DOCTYPE ...
  24.  
  25. тут вокруг теперь везде ***** и мы к нему готовы и обули болотные сапоги ...
  26.  
  27. <?php if ($result1 !== null) {
  28.  foreach ($result1 as $item) { ?>
  29.  
  30.   <div><?php echo $item['name1']; ?> --- <?php echo $item['name2']; ?></div>
  31.  
  32. <?php } } else { ?>
  33.   <h1>Первый запрос ничего не вернул</h1>
  34. <?php } ?>
  35.  
  36. <div>
  37. ... шлёп, шлёп, хлюп, хлюп ...
  38. </div>
  39.  
  40. <?php if ($result2 !== null) {
  41.  foreach ($result2 as $item) { ?>
  42.  
  43.   <div><?php echo $item['name45']; ?> --- <?php echo $item['name56']; ?></div>
  44.  
  45. <?php } } else { ?>
  46.   <h1>Второй запрос ничего не вернул</h1>
  47. <?php } ?>
  48.  
  49. </html>

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

Собственно в примере я обернул в удобный "метод" только одно действие - запрос к БД, который возвращает либо результат, либо null. На деле же естественно можно и даже нужно обернуть в такие вот "методы" все необходимые действия с базой данных: подключение, закрытие соединения, запрос на запись или апдейт в таблицах БД и пр..

3. Классы

Теперь же если взглянуть на этот набор "методов", можно увидеть, что совершают они один тип действий - работа с БД. И как вы думаете, разве не стОит их объеденить в один общий пласт? ну конечно же стОит Улыбка
Объединение (не процесс объединения, а содружество функций) нескольких методов, которые выполняют один некий тип действий, это и есть - класс.

На самом деле использовать слово "метод" я стал не с проста, ведь функции находящиеся в классах именно так и называются - методы.

Итак, теперь вы уже знаете что такое метод класса Улыбка Существуют еще и свойства объекта (вон как все запущено). Но об этом немногим позже.

4. Объекты

Для того чтобы вызвать функцию, её сперва нужно определить и описать выше по коду. Так и с объектами. Объект, это то что мы описали в классе. Т.е. класс это прототип будущего объекта. Сперва мы описываем класс с его методами и свойствами, а затем создаем объект на основе описанного класса:
PHP:
скопировать код в буфер обмена
  1. <?PHP
  2.  
  3. class MyFirstClass {
  4.  
  5.   // вот оно свойство будущего объекта
  6.   var $name = null;
  7.  
  8.   // а вот метод который меняет это свойство
  9.   function setMyName($str) {
  10.     // зарезервированное "имя" $this
  11.     // означает что мы будем обращаться внутри самого объекта,
  12.     // а вот этот значок -> говорит ЧТО именно мы будем изменять
  13.     // вот и получается, что меняем мы ТУТ ВНУТРИ ОБЪЕКТА ($this) свойство $name
  14.     // на значение, которое пришло в аргументе в наш метод $str
  15.     $this->name = $str;
  16.     }
  17.  
  18.   function getMyName() {
  19.     // а тут мы просим вернуть нам значение внутреннего свойства нашего объекта
  20.     return $this->name;
  21.     }
  22.  
  23.   }
  24.  
  25. // создаем наш объект на основе описанного класса
  26. $object = MyFirstClass;
  27.  
  28. // устанавливаем значение свойства нашего объекта
  29. // нужно заметить, что тут у нас есть волшебный значок ->,
  30. // однако мы обращаемся к методу извне, поэтому $this использовать нельзя,
  31. // нужно обращаться к самому объекту
  32. $object->setMyName("Вася");
  33.  
  34. // теперь проверим установилось ли значение?
  35. echo $object->getMyName();
  36.  
  37. // выведет "Вася"
  38.  
  39. ?>

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

Однако самое интересное, это то, что внутри класса можно обращаться через $this не только к свойствам, но и к методам. Более того, любое свойство может содержать в своем значении число, строку, массив, объект и даже массив объектов. Методы могут манипулировать всеми этими свойствами. Например вот такая интересная запись:
PHP:
скопировать код в буфер обмена
  1. <?PHP
  2.  
  3. $object->property->methodOfProperty();
  4.  
  5. ?>

... запись говорит о том что мы обращаемся к методу methodOfProperty() объекта $property который лежит в объекте $object в качестве его свойства. Не понял
Вложенность не ограничена.
Но самый главный плюс использования ООП в написании web-приложений это то, что единожды написав класс для работы с чем либо, больше НЕ придется писать еще, еще и еще раз одно и то же в каждом новом проекте. Кроме того если вдруг захочется какой либо класс переделать внутри, то совершенно не придется перелопачивать код приложения ВНЕ этого класса.



Продолжение следует...


P.S. Хотелось бы узнать от новичков насколько понятным языком я изъясняюсь и стОит ли продолжать в таком же духе далее.

P.P.S. Хотел бы сказать профессионалам, а именно модераторам, что если что-то стоит изменить/добавить, то, конечно, всегда пожалуйста.

P.P.P.S. Ну и с богом в общем Радость
2. tuareg - 12 Ноября, 2011 - 20:03:46 - перейти к сообщению
Это интересно, написано понятно. Хотелось бы только услышать мнение когда нужно использовать ООП, а когда не стоит.
3. DeepVarvar - 12 Ноября, 2011 - 20:10:22 - перейти к сообщению
tuareg пишет:
когда нужно использовать ООП, а когда не стоит
Хм...
Вобще, если уж начали писать объектами, то иначе и не выйдет продолжить.
Дело в том, что, да, ходит такая "утка" типа "ну сколько уже можно пихать это ООП".
Однако если посмотреть в исходники фреймворков - там только ООП.
На самом деле в статейке не раскрылось и одной десятой доли преимуществ ООП против "макарон".
Не все сразу.
Могу сказать на вскидку, что проекты с сложной логикой нужно делать на ООП, иначе дебажить не передебажить...
4. ALEN - 12 Ноября, 2011 - 20:21:34 - перейти к сообщению
Классы помогают разбить вашу программу на логические и независимые блоки, которые можно в любой момент заменить или изменить, что сказывается на качестве программы, оптимизации, возможности в будущем легко разобраться в коде и исправить нужные детали.
Со стороны новичка сразу будет заметно, что теперь если размер кода в файле будет составлять более 100кб - его все равно будет легко читать и проследить, что происходит.
5. tuareg - 12 Ноября, 2011 - 20:43:53 - перейти к сообщению
Спасибо, тогда буду ждать новых статей
6. caballero - 12 Ноября, 2011 - 20:49:41 - перейти к сообщению
Цитата:
Хотелось бы только услышать мнение когда нужно использовать ООП, а когда не стоит.


Это примерно как спросить мнение когда нужно использовать функции или массивы. Когда есть смысл и необходимость для решения конкретной задачи тогда и нужно.
Или ты думал будет четкий ответ типа - используем ООП после 126 строки кода?
7. DeepVarvar - 12 Ноября, 2011 - 20:52:58 - перейти к сообщению
Stierus пишет:
из этой статьи не возникает понимания, чем ООП отличается от функционального программирования, в чем его суть и сила.

DeepVarvar пишет:
На самом деле в статейке не раскрылось и одной десятой доли преимуществ ООП против "макарон".

К тому же мое мнение - не стоит перегружать не понимающий мозг лишней информацией.
Всю картину в одной статье не впихнёшь.
caballero пишет:
используем ООП после 126 строки кода
Радость Радость Радость
8. Stierus - 12 Ноября, 2011 - 20:57:15 - перейти к сообщению
Цитата:
К тому же мое мнение - не стоит перегружать не понимающий мозг лишней информацией.

Когда тебе про что-то рассказывают, даже у недоразвитых первым возникает вопрос: "Зачем мне это?" В любой книге первой главой идет "ля кого эта книга, зачем вам это нужно" ... вы сами понимаете, чем ООП отличается от процедурного программирования, АОП и тд ?
9. caballero - 12 Ноября, 2011 - 20:58:10 - перейти к сообщению
Цитата:
написано на си - чистый функциональный язык

С - процедурный язык а не функциональный

Цитата:
преимуществ ООП против "макарон"


Если человек пишет по китайски никакое ООП не поможет
можно и без ООП написать акуратный код и наоборот
10. tuareg - 12 Ноября, 2011 - 20:59:21 - перейти к сообщению
Я не об этом. Я использую на сайте jQeury.
Допустим вывод новостей. Я понимаю, что этот вывод можно сделать через плагин или виджет. Оцениваю возможность(+/-) пишу плагин или виджет.
Используя MySQL, я вижу что мне нужно будет сделать от 2 до N запросов. Я не думая сразу же пишу процедуру. Вот к чему я это и спрашивал
11. caballero - 12 Ноября, 2011 - 21:02:24 - перейти к сообщению
Цитата:
Я понимаю, что этот вывод можно сделать через плагин или виджет. Оцениваю возможность(+/-) пишу плагин или виджет.
Используя MySQL, я вижу что мне нужно будет сделать от 2 до N запросов. Я не думая сразу же пишу процедуру. Вот к чему я это и спрашивал


Точно так же и с ООП. Я пишу код.
я "понимаю" или "вижу" что тут нужен класс и я его делаю
нет никаких критериев где использовать ООП а где нет кроме опыта приобретенного практикой
12. Stierus - 12 Ноября, 2011 - 21:03:44 - перейти к сообщению
Цитата:
С - процедурный язык а не функциональный
Блин , меня не в ту степь понесло, сори. В общем - надо объяснить, чем одно отличается от остального и зачем оно нужно, в чем преимущества Улыбка
13. DeepVarvar - 12 Ноября, 2011 - 21:06:28 - перейти к сообщению
Stierus пишет:
чем ООП отличается от процедурного программирования
Ыыыы....
Вот этим: -> Радость

Конечно понимаю. Но я и слова не сказал о том, зачем это надо кому-то там.
Если читают, значит надо. Мне в свое время было очень сложно понять что же имел виду автор. Когда я читал начало, то самое "зачем мне это надо", я понимал о чем речь.
Вах, вах, вот мол так и так и все такое расписное да красивое...
А вот когда автор переходил к объяснению реализации, все - ступор от того, что автор бросается не понятными терминами, которые ему, конечно понятны, а мне - нет.
Да и как они могут быть мне понятными то?
----
Здесь же, напротив, я преднамеренно отказался от описания "зачем им это надо".
И попытался объяснить реализацию.
И даже задал в окончании вопрос к ним: понятно ли я излагаю?

Stierus пишет:
В любой книге
Да, я тоже подумал о книгах, когда писал что в одну статейку это не влезет всеравно.
(Добавление)
Stierus если хотите, дополните, я даже не то что не возражаю, я даже хотел бы чтобы вы добавили туда описание "зачем оно надо и чем отличается".
(Добавление)
Могу даже выделить ключевые пункты всей статьи.
Большего я в ней и не преследовал.
А именно, медленно, но верно двигаться по пути осознания:
1) функции
2) "сообщество" функций
3) сначала логика, затем вывод
4) классы и методы
5) немного информации о возможностях

Все остальные плюшки, такие как приват, паблик, статик, синглтон, область видимости, наследование, интерфейсы - это слишком много для начала.
14. tuareg - 12 Ноября, 2011 - 21:54:58 - перейти к сообщению
Мне кажется, что идеальным вариантом для того чтобы проникнуться ООП.
Взять какой-то пример(сам не знаю какой Радость )
И расписать его в стиле процедурного и ООП программирования. Тогда сразу были бы видны все +/- указанных подходов(легкость изменения и т.д)
15. DeepVarvar - 12 Ноября, 2011 - 21:58:39 - перейти к сообщению
tuareg это не возможно.
Дело в том что как уже сказали выше, реализовать конечно можно и так и так.
Но это не будет верным..
Слишком разные принципы..
(Добавление)
Я постараюсь найти "живой" пример и выполнить вашу просьбу.

 

Powered by ExBB FM 1.0 RC1