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