Когда мы должны использовать класс, и когда мы не должны

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

Если script никогда не имеет свободных функций? Должен ли я использовать тысячи классов, чтобы сделать script более чистым? А как насчет выступлений? Требуется ли class::method() гораздо больше времени, чем простая function()? В чем смысл ООП? Я немного смущен.

Поскольку я обнаружил ООП, я не вижу случайных функций. Я одержим. Я не вижу функций, у которых нет родительского класса. Я скорее создаю класс с помощью всего лишь метода, а затем вижу эту функцию в одиночку. Это правильно? Есть ли примеры чистых CMS OOP?

ОТВЕТЫ

Ответ 1

Самое важное для программиста в PHP, на мой взгляд, помимо его опыта - его инструментарий. То есть код, который он/она написал внутри и снаружи, назад и вперед с незапамятных времен.

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

$my_session = new session();
$my_session->start();

if ( ($session_errno = $my_session->error()) !== FALSE)
{
   //DO SOMETHING BECAUSE OF A SESSION ERROR
}

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

session_start();

if (session_error())
{
   //DO SOMETHING BECAUSE OF A SESSION ERROR
}

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

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

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

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

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

Я оставлю свою последнюю метафору. Объекты похожи на специализированные машины и инструменты внутри factory. В то время как factory сам имеет ряд уникальных инструментов на своей сборочной линии: все от простых тормозов сгиба до станков с ЧПУ и автоматизированных роботов, они составляют лишь небольшую часть команды, которая существует, чтобы помочь более многочисленным рабочим и менеджерам, наши статические функции, делают работу по созданию лучшего автомобиля, грузовика или велосипеда.

Ответ 2

Используйте ООП:

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

Не используйте ООП:

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

Ответ 3

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

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

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

Ответ 4

Посмотрите на это:

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

Ссылка

Ответ 5

Если вы думаете о своих объектах как о тяжелых камнях, это может быть хорошо. Поскольку php не имеет особого характера (кроме некоторых стандартных расширений), существует процедурных функций достаточно, около 6000, не так ли?

Я бы посоветовал вам продолжить ООП. Сотни классов кажутся слишком сложными. Для начала поставьте все, что вам нужно, в один объект, и при необходимости разделите их на подклассы.

Ответ 6

Нет простого ответа на этот вопрос.

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

Самое главное помнить, что вы пишете программы на языке и стиле, что делает их читаемыми людьми! Тот факт, что компьютер может их анализировать, в значительной степени совпаден.

Конечно, накладные расходы на вызов статического метода и функции не должны рассматриваться, и вы определенно виновны в преждевременной оптимизации. Если вы беспокоитесь об этом, почему бы вам не измерить это для себя? Вы обнаружите, что, хотя он медленнее, разница очень мала и не должна переопределять основные цели при написании кода (т.е. Он должен работать, он должен быть как можно более ясным, как он работает, он не должен иметь никакой стороны -effects).