У меня есть начало webapp, которое я написал без использования объектно-ориентированных функций PHP.
Я действительно не знаю, стоит ли возвращаться и переписывать детали, которые я закончил. Является ли объектно-ориентированный PHP-ресурс переписывать все или часть достойного рабочего приложения?
Учитывая, что у вас есть неполное приложение, я бы сказал, что переработка его в приложение на основе объектов, вероятно, будет полезно.
Следует рассмотреть вопрос о ожидаемом размере конечного приложения. Ниже определенной сложности Объект может быть чрезмерным, за исключением опыта обучения.
Я начал избегать предметов, подобных чуме, потому что мое первоначальное введение в них в университетских классах было ужасным. Недавно мне пришлось работать над проектом, который был реализован в php-объектах. внесение необходимых изменений было намного проще, чем другие проекты. С тех пор я часто работал в объектной модели и считаю ее очень удобной для быстрого создания и более легкого обслуживания.
Чтобы не согласиться с консенсусом … Я бы сказал, что в большинстве случаев нет. В любом случае, это не академическое упражнение по коммерческому кодексу. Если он работает, не переписывайте его. Если вам нужно входить, чтобы изменить / добавить биты, а затем реорганизовать в сторону OO-практики (есть много сообщений о SO о рефакторинге, когда вы меняете код в любом случае, а не только ради этого).
На практике, если вы не сделали много ООП, тогда вы захотите начать с малого и почувствовать это.
Как только вы получите представление об основах, очень полезно руководство для начинающих по дизайну (мне нравится книга «Первая книга»). Большинство книг PHP научат вас ООП довольно плохо. Они учат вас о наследовании, но обычно не учат вас свободному соединению и предпочитают композицию над наследованием. Книга шаблонов дизайна даст вам лучшее представление об этом.
PHP все еще имеет репутацию не «делать» OO вправо. Я не думаю, что это справедливо, но является отражением того факта, что людям так легко начинать, даже не опасаясь ООП. Я бы вышел на конечность и сказал, что большинство (хотя бы немного – назовите это 51%) программистов PHP не устраивает ООП. Я думаю, что можно сделать хороший OO в PHP, и если вам уже нравится язык, это отличный способ развить свои навыки.
РЕДАКТИРОВАТЬ:
Просто добавьте пару отказов …
Типичный ответ: «Это зависит».
Я склонен писать страницу отображения как начальную, <html> к </ html> страницу сценария. Но вещи, которые происходят на этой странице, были объектами. Своего рода ASP ASP. В то время как у вас может быть выход на основе ООП, я, похоже, считал это слишком громоздким для задачи, столь же утомительной, как сброс данных в браузер.
Таким образом, бизнес-правила и доступ к данным были ООП. Представление было сценарием.
Если у вас есть бизнес-правила, которые не являются ООП, я бы серьезно подумал о том, чтобы называть их объектами в двух условиях: (1) «У вас есть время / усилия / деньги для этого?» и (2): «У вас есть хорошая PHP IDE, которая сделает вашу жизнь проще?» Если он работает, и его изменение означает запись в Notepad ++, я бы назвал это сделанным. 🙂
Я бы не сказал, что это критично, но если вы собираетесь пойти дальше с этим приложением, я бы рекомендовал сделать это сейчас, пока это не так много монументальной задачи. Я бы сказал, что ремонтопригодность хорошо написанной программы ООП может значительно перевесить первоначальные затраты. Особенно, если учесть, что вы сможете реорганизовать большую часть кода по мере продвижения.
Обучение объектно-ориентированным технологиям будет действительно полезно, особенно для программирования на других языках в будущем.
Поскольку вы только что запустили приложение, вы можете переписать и улучшить детали, которые вы написали. Это зависит от вашего срока.
Есть две возможности: либо ваше приложение является одноразовым, которое просто должно работать прямо сейчас, и никогда не будет затронуто, адаптировано, расширено или изменено, иначе ваше приложение станет началом того, над чем вы будете продолжать работать и использовать долго.
Если первый, не сломайте совершенно полезный код. У вас есть лучшие дела с вашим временем.
Если последнее, вы должны иметь в виду важный факт о PHP, который заключается в следующем: плохо написанный PHP – это кошмар для поддержания. Не так плохо, как плохо написанный Perl – потому что что? – но достаточно плохо, что рано или поздно вы почувствуете сильное желание украсть машину времени, вернуться к моменту написания кода, который вы сейчас найдете, и нанести удар в глазное гнездо с помощью ледяного шлема.
Поэтому, если вы собираетесь поддерживать этот код с течением времени, найдите время, чтобы сделать это правильно. Это означает: какая-то система шаблонов, встроенные внутри HTML теги PHP, отдельные файлы для отдельной функциональности и классы классов классов !
Ваши глазницы будут благодарны вам.
Я бы сказал, попробуй и пойди ОО только потому, что то, что у тебя есть, может быть использовано гораздо проще, чем процедурное, если сделать правильно
Я также скажу, что ОО гораздо более организован, чем процедурный. Когда вы в небольшом масштабе легко уйти с неаккуратным кодом OO или нет. Но когда вы попадаете в более крупные проекты, ваш процедурный подход должен быть гораздо более организованным и продуманным. Где, как и в некоторых более крупных проектах, ОО стремится заставить вас быть более организованным, делая вещи немного легче.
Нет, я думаю, что если приложение работает так, как будто нет необходимости переписывать его. PHP вообще не ООП. Они стараются, но иногда я думаю, что даже разработчики PHP не понимают смысла ООП. Если вы хотите изучить ООП (это, безусловно, хорошая идея), попробуйте настоящий язык ООП, такой как Smalltalk, чтобы изучить основные понятия. Java тоже хорош. 2 изучите базовый язык, хотя он также не является полностью ООП.
Я хотел бы повторить другие ответы здесь. Это зависит от размера приложения и того, что вы хотели бы узнать о ООП. Я был бы осторожен в изучении ООП, используя PHP.
Что касается того, насколько PHP является объектно-ориентированным … В PHP4 были задействованы некоторые элементы OOP, PHP5 лучше, но он не запекается на этом языке. PHP работает в обоих направлениях, и лично мне нравится, что вы можете выбрать.
На мой взгляд, мы можем полностью отказаться от концепции Object (экземпляр класса), нам нужен только класс Array и Mode:
Все массивы в начальном режиме поддерживают любую функцию массива как метод:
<?php $array1->array_flip(this); ?> Используйте ->mode() для проверки минимального набора данных, а затем переключите класс режима:
<?php $array1->mode('class1', $success); ?>
Любой класс mode не имеет ->construct() в нем, но имеет ->validate() для проверки минимального набора данных.
Массив в режиме все еще может использовать функцию массива в качестве своего метода, но после использования любого из них массив будет переключен обратно в режим базового массива, и нам нужно использовать ->mode('class1', $success); для переключения режима назад.
Радикальная мысль – это ориентированное на данные программирование, нам нужно разделить данные (массив) и активность (метод класса).
Мы могли бы модифицировать PHP-движок, чтобы избавиться от частей OO (объектно-ориентированного) и поддерживать класс Mode, мы могли бы назвать его MyPHP.
Например: $array_man1 можно установить в два режима: cls_normal_man и cls_crazy_man :
<?php $array_man1->mode('cls_normal_man')->normal_method1()->mode('cls_crazy_man')->crazy_method1(); ?>