Классы. Какой смысл?

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

Лучший пример, который я могу привести сейчас, это соединение с базой данных.

Вместо того, чтобы иметь отдельные функции, которые соединяются, посылают запрос, получают результаты и закрывают соединение, вы можете обернуть все эти функции в класс . Это позволило бы многократно обмениваться данными с БД, используя одни и те же функции, без необходимости загружать переменные, адаптированные для конкретного использования на странице.

Все приведенные выше плакаты имеют действительно хорошие баллы. Я бы настоятельно рекомендовал следующие книги:

• The OO Thought Process: http://www.amazon.com/Object-Oriented-Thought-Process-3rd/dp/0672330164/ref=sr_1_5?ie=UTF8&s=books&qid=1262547120&sr=8-5

• PHP5 Objects, Patterns & Practice: http://www.amazon.com/PHP-Objects-Patterns-Practice-Second/dp/1590599098/ref=sr_1_3?ie=UTF8&s=books&qid=1262546817&sr=8-3

• OO Design Heuristics: http://www.amazon.com/Object-Oriented-Design-Heuristics-Arthur-Riel/dp/020163385X/ref=sr_1_1?ie=UTF8&s=books&qid=1262546869&sr=8-1

Если вы просто пишете функции в процедурном стиле, то, объединив их в класс, вы не получите многих преимуществ ООП. Я думаю, что Open Closed Principle и Dependency Inversion Principle описывают некоторые из самых больших преимуществ ООП, которые вы не получите, если намеренно не спроектируете их в своем коде.

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

Большим преимуществом ООП является повторное использование кода. Пример: Скажем, вы разрабатываете общий класс "Socket", который взаимодействует с сервером на очень низком уровне. Затем, я могу прийти и решить, что я хочу написать класс FTP, который позволяет пользователю загружать файлы при подключении к FTP-серверу. Я могу "подклассифицировать" ваш класс Socket и расширить его функциональность для поддержки FTP, не переписывая ваш код.

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

Заметьте, как в этом примере не было дублирования кода сокета; и я, и Джон поделились им. Дублирование кода плохо, потому что если в дублирующемся коде есть ошибка, то точно такая же ошибка может произойти где-то еще в вашем коде, и вы можете этого не осознавать.

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

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

Вот отредактированный пример из php.net

<?php
$item_name = 'Widget 22';
$item_price = 4.90;
$item_qty = 2;
$item_total = ($item_price * $item_qty);
echo "You ordered $item_qty $item_name @ \$$item_price for a total of: \$$item_total.";
?>

v.s:

<?php
class Item {
  protected $name, $price, $qty, $total;

  function __construct($name, $price) {
    $this->name = $name;
    $this->price = $price;
  }

  function calculate($qty) {
    $this->total = number_format(($this->price * $qty), 2);
  }

  public function __toString() {
    return "You ordered ($this->qty) '$this->name'" . ($this->qty == 1 ? "" : "s") .
    " at \$$this->price, for a total of: \$$this->total.";
  }
}

$widget22 = new Item("Widget 22", 4.90);

$widget22->calculate(2);

echo $widget22;
?>

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

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

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

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

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

Я подумал точно так же.

Я прочитал несколько книг об OO-PHP, моей любимой из которых является PHP In Action.

Хотя когда я читал книги, я подумал: "Эй, это очень полезная и интересная информация", мне еще предстоит использовать значительное количество OO-PHP.

Простые потребности, такие как получение информации с сервера и JSON-в обратном направлении, действительно не нуждаются в OOP. Я уверен, что это "Лучшая практика", но для многих это не практично. Несколько классов, таких как подключение к базе данных, и подобная обработка данных могут быть сэкономлены в реальном времени, но PHP иногда проще и быстрее используется только частично OO.

Определенно было бы легко кодировать в процедурном программировании (так называется ваш простой процесс), если бы ваш сайт был небольшим. Но по мере роста вашего сайта, вам определенно понадобится сортировать вещи.

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

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

Всего несколько месяцев назад я писал похожие вопросы о классах, я использую PHP уже несколько лет, и я действительно не видел необходимости в использовании классов, они просто усложнили простой процесс, как вы сказали, ну я наконец-то решил зайти в Class train, и я все еще учусь, но мне удобно использовать их сейчас, и WOW я думаю о них сейчас совершенно по-другому, я думаю, что они - лучшая возможность в PHP сейчас!

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

Все, что я могу сказать, что это одна из тех вещей, в которые вам нужно погрузиться, чтобы увидеть РЕАЛЬНЫЕ преимущества.

Для управления сложностью.

Редакция: Может быть, я проработаю немного больше.

Программы - это сложные сущности, и исторически было предложено много способов приручить их сложность.

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

Объектное программирование не решит всего, и, конечно, для небольшого скрипта оно переборщит, но прекрасно работает для больших приложений или систем.

Мой оригинальный ответ пытается подытожить полное содержание громоздкой книги Code Complete : сделайте все возможное, чтобы управлять сложностью и сделать ваши программы понятными для вас и ваших преемников. Это здорово, если Вы думаете, что объектное программирование поможет Вам в этой задаче, но еще лучше, если Вы ставите под сомнение его удобство и пытаетесь найти лучшие пути.

В PHP классы могут, как минимум, избавить вас от кучи include операторов. Ленивая загрузка функции __autoload() очень удобна. Кроме того, вы можете быть уверены, что имена функций в разных include не будут конфликтовать.

Чтобы пойти дальше, вы можете начать думать о создании API вокруг класса. Функции, которые нужны только другим функциям внутри класса, могут быть помечены private. В конце концов, вы сможете игнорировать фактический код в ваших классах и просто думать о них как о вызовах API.

Если я вызову Do::stuff($a, $b), то получу такой ответ.

И это все, что вам нужно знать. Вы можете забыть, как это работает "под капотом" внутри класса.

И, конечно, есть классы с нестатическими функциями. Они могут делать различные интересные вещи, которые не могут делать обычные функции.