У меня есть начало webapp, которое я написал без использования объектно-ориентированных функций PHP.
Я действительно не знаю, стоит ли возвращаться и переписывать детали, которые я закончил. Является ли объектно-ориентированный PHP стоящим переписывать все или часть достойного рабочего приложения?
Учитывая, что у вас есть неполное приложение, я бы сказал, что переработать его в приложении на основе объектов, вероятно, будет полезно.
Одна вещь, которую следует учитывать, - это ожидаемый размер конечного приложения. Ниже определенной сложности На основе объекта может быть излишним, кроме опыта обучения.
Я начал избегать таких объектов, как чума, потому что мое первоначальное введение в них в университетских классах было ужасным. Недавно мне пришлось работать над проектом, который был реализован в php-объектах. внесение необходимых изменений было намного проще, чем другие проекты. С тех пор я часто работал в объектной модели и считаю ее очень удобной для быстрого создания и более легкого обслуживания.
Просто чтобы не согласиться с консенсусом... Я бы сказал, что в большинстве случаев нет. В любом случае, это не академическое упражнение по коммерческому кодексу. Если он работает, не переписывайте его. Если вам нужно входить, чтобы изменить/добавить биты, а затем реорганизовать в сторону OO-практики (есть много сообщений о SO о рефакторинге, когда вы меняете код в любом случае, а не только ради этого).
На практике, если вы не сделали много ООП, тогда вы захотите начать с малого и почувствовать это.
Как только вы получите ручку об основах, очень полезно пособие для начинающих по дизайну (мне нравится книга "Первая книга" ). Большинство книг PHP научат вас ООП довольно плохо. Они учат вас о наследовании, но обычно не учат вас свободному соединению и предпочитают композицию над наследованием. Книга шаблонов дизайна даст вам лучшее представление об этом.
PHP по-прежнему имеет репутацию не "делать" OO вправо. Я не думаю, что это справедливо, но является отражением того факта, что людям так легко начинать, даже не опасаясь ООП. Я бы вышел на конечность и сказал, что большинство (хотя бы немного - назовите это 51%) программистов PHP не устраивает ООП. Я думаю, что можно сделать хорошее OO в PHP, и если вы уже привыкли к этому языку, это отличный способ развить свои навыки.
ИЗМЕНИТЬ:
Просто добавьте пару отказов...
Типичный ответ: "Это зависит".
Я склонен писать страницу отображения как начало-до конца, html > to </html> сценарий. Но вещи, которые происходят на этой странице, были объектами. Своего рода бедняга ASP. Хотя вы можете иметь выход OOP-base, я, как правило, считал, что это слишком громоздко для задачи, как утомительной, как сброс данных в браузер.
Таким образом, бизнес-правила и доступ к данным были ООП. Презентация была script.
Если у вас есть бизнес-правила, которые являются не ООП, я бы серьезно подумал о написании их как объектов в двух условиях: (1) "У вас есть время/усилия/деньги для этого?" и (2): "У вас есть хорошая PHP IDE, которая сделает вашу жизнь проще?" Если он работает, и его изменение означает запись в Notepad ++, я бы назвал это сделанным.: -)
Я бы не сказал, что это важно, но если вы собираетесь пойти дальше с этим приложением, я бы рекомендовал сделать это сейчас, пока это не так много монументальной задачи. Я бы сказал, что ремонтопригодность хорошо написанной программы ООП может значительно перевесить первоначальные затраты. Особенно, если учесть, что вы сможете реорганизовать большую часть кода по мере продвижения.
Обучение объектно-ориентированным технологиям будет действительно полезно, особенно для программирования на других языках в будущем.
Поскольку вы только что запустили приложение, вы можете переписать и улучшить детали, которые вы написали. Это зависит от вашего срока.
Есть две возможности: либо ваше приложение является одноразовым, которое просто должно работать прямо сейчас, и никогда не будет затронуто, адаптировано, расширено или изменено, или еще ваше приложение является началом что вы будете продолжать работать и использовать в течение длительного времени.
Если первый, не сломайте совершенно полезный код. У вас есть лучшие дела с вашим временем.
Если последнее, вы должны иметь в виду важный факт о PHP, который заключается в следующем: плохо написанный PHP - это кошмар для поддержания. Не так плохо, как плохо написанный Perl - потому что является? - но достаточно плохо, что рано или поздно вы почувствуете сильное желание украсть машину времени, вернуться к моменту написания кода, который вы теперь поддерживаете, и нанести удар в глазное гнездо с помощью ледяного щита.
Итак, если вы собираетесь поддерживать этот код с течением времени, найдите время, чтобы сделать это правильно. Это означает: какая-то система шаблонов, встроенные внутри HTML теги PHP, отдельные файлы для отдельной функциональности и классы классов классов!
Ваши глазницы будут благодарны вам.
Я бы сказал, попробуй и пойди ОО только потому, что то, что у тебя есть, может быть использовано гораздо проще, чем процедурное, если сделать правильно
Я также скажу, что OO гораздо более организован, чем процедурный. Когда вы в небольшом масштабе легко убираетесь с неаккуратным кодом OO или нет. Но когда вы попадаете в более крупные проекты, ваш процедурный подход должен быть гораздо более организованным и продуманным. Где, как и в некоторых крупных проектах, OO имеет тенденцию заставлять вас быть более организованными, делая вещи немного легче.
Нет, я думаю, что если приложение работает так, как будто нет необходимости переписывать его. PHP вообще не ООП. Они стараются, но иногда я думаю, что даже разработчики PHP не понимают смысла ООП. Если вы хотите изучить ООП (это, безусловно, хорошая идея), попробуйте настоящий язык ООП, такой как Smalltalk, чтобы изучить основные понятия. Java также хорош 2 изучать базовые, хотя он также не полностью OOP
Я хотел бы повторить другие ответы здесь. Это зависит от размера приложения и того, что вы хотели бы узнать о ООП. Я был бы осторожен в изучении ООП, используя PHP.
В отношении того, насколько PHP является объектно-ориентированным... PHP4 имел некоторые элементы ООП, наложенные на него, PHP5 лучше, но он не испек на язык. PHP работает в обоих направлениях, и лично мне нравится, что вы можете выбрать.
На мой взгляд, мы можем полностью отказаться от концепции Object (экземпляр класса), нам нужен только класс Array и Mode:
Все массивы в начальном режиме поддерживают любую функцию массива как метод:
<?php
$array1->array_flip(this);
?>
Используйте ->mode() для проверки минимального набора данных, а затем переключите класс режима:
<?php
$array1->mode('class1', $success);
?>
Любой класс режима не имеет ->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();
?>