J'ai un début de webapp que j'ai écrit sans utiliser les fonctions orientées objet de PHP.PHP Objet Orienté ou non?
Je ne sais pas vraiment si cela vaut la peine de revenir en arrière et de réécrire les parties que j'ai terminées. L'objet orienté PHP mérite-t-il de réécrire tout ou partie d'une application de travail décent?
Étant donné que vous avez une application incomplète, je dirais que le retravailler dans une application basée sur l'objet sera probablement utile.
Une chose à prendre en compte est la taille attendue de l'application finale. En dessous d'une certaine complexité L'objet basé peut être exagéré sauf pour l'expérience d'apprentissage.
J'ai commencé par éviter les objets comme la peste parce que mon introduction initiale à eux dans les classes universitaires était terrible. J'ai récemment dû travailler sur un projet implémenté dans des objets php. faire les changements requis était beaucoup plus facile que d'autres projets. Depuis, j'ai travaillé fréquemment dans le modèle objet et je le trouve très pratique pour une création rapide et un entretien plus facile.
Je ne dirais pas que c'est critique, mais si vous allez aller beaucoup plus loin avec l'application, je recommanderais de le faire maintenant alors que ce n'est pas une tâche aussi monumentale. Je dirais que la maintenabilité d'un programme de POO bien écrit pourrait largement l'emporter sur les coûts initiaux. Surtout quand vous considérez que vous serez en mesure de refactoriser une grande partie du code au fur et à mesure.
Les techniques d'apprentissage orientées objet seront très utiles, en particulier pour la programmation dans d'autres langues à l'avenir.
Depuis que vous venez de démarrer l'application, vous pouvez réécrire et améliorer les parties que vous avez écrites. Cela dépend de votre date limite.
Réponse type: "Cela dépend."
J'ai tendance à écrire la page d'affichage en tant que page de script de < html> </html> de début à la fin. Mais les choses qui se passent sur cette page étaient des objets. Un peu comme l'ASP d'un pauvre. Bien que vous ayez une sortie de base POO, j'ai toujours pensé que c'était trop lourd pour une tâche aussi fastidieuse que de déverser des données dans un navigateur. Par conséquent, les règles métier et l'accès aux données étaient des POO. La présentation était un script. Si vous avez des règles d'affaires qui sont et non OOP, je considérerais sérieusement écrire ces objets comme deux objets: (1) est "Avez-vous le temps/effort/argent pour le faire?" et (2) est "Avez-vous un bon IDE PHP qui vous facilitera la vie?" Si cela fonctionne, et que cela change signifie écrire dans Notepad ++, alors je l'appellerais fait. :-)
Juste pour être en désaccord avec le consensus ... Je dirais que non dans la plupart des cas. Pas comme un exercice académique sur le code commercial de toute façon. Si ça marche, ne le réécrivez pas. Si vous devez modifier/ajouter des bits, refactorisez-vous vers les pratiques OO (il y a beaucoup de messages sur SO refactoring quand vous changez de code de toute façon, et pas seulement pour le plaisir).
En pratique si vous n'avez pas fait beaucoup de POO, alors vous voudrez commencer petit et avoir une idée de cela. Une fois que vous maîtrisez les notions de base, un bon guide pour débutants sur les Patterns (j'aime bien le livre Head First) est très utile. La plupart des livres PHP vous enseignent assez mal la POO. Ils vous apprennent sur l'héritage, mais ne vous apprennent généralement pas sur le couplage lâche et de favoriser la composition sur l'héritage.Un livre de modèles de conception vous donnera un meilleur aperçu de cela.
PHP a toujours la réputation de ne pas "faire" OO à droite. Je ne pense pas que ce soit juste, mais c'est le reflet du fait qu'il est si facile pour les gens de se lancer sans vraiment gâcher la POO. Je voudrais sortir sur un membre et dire que la majorité (toujours aussi légèrement - appelez-le 51%) des programmeurs PHP ne sont pas à l'aise avec OOP. Je pense qu'il est possible de faire du bon OO en PHP, et si vous êtes déjà à l'aise avec la langue, c'est un excellent moyen de développer vos compétences.
EDIT:
Juste pour ajouter quelques renonciations ...
Je dirais essayer et aller OO juste parce que ce que vous avez peut être réutilisé beaucoup plus facile que la procédure si elle est faite
Je dirai aussi que OO est beaucoup plus organisé que procédural. Lorsque vous êtes à petite échelle, il est facile de sortir avec le code bâclé OO ou non. Mais quand vous arrivez à des projets plus importants, votre procédure doit être beaucoup plus organisée et réfléchie. Où, comme pour certains grands projets, OO a tendance à vous forcer à être plus organisé, ce qui rend les choses un peu plus faciles.
Non, je pense que si l'application fonctionne comme elle le devrait, il n'est pas nécessaire de la réécrire. PHP n'est pas vraiment OOP du tout. Ils essayent dur mais parfois je pense que même les PHP-développeurs ne comprennent pas vraiment le sens de la POO. Si vous souhaitez apprendre la POO (ce qui est certainement une bonne idée), essayez un vrai langage OOP comme Smalltalk pour apprendre les concepts de base. Java est également agréable 2 apprendre la base, bien qu'il ne soit pas entièrement OOP aussi bien
Il y a deux possibilités: soit votre application est un one-off qui a juste à travailler en ce moment et ne sera jamais touché, adapté, élargi ou modifié, ou votre application est le début de quelque chose que vous allez continuer à travailler et à utiliser sur une longue période.
Si le premier, ne pas casser le code parfaitement utilisable. Tu as de meilleures choses à faire avec ton temps.
Si ce dernier, vous devez garder à l'esprit un fait important sur PHP, qui est le suivant: PHP mal écrit est un cauchemar à maintenir. Pas aussi mauvais que mal écrit Perl - parce que c'est quoi? - mais c'est assez grave pour que tôt ou tard vous ressentiez une forte envie de voler une machine à voyager dans le temps, de revenir au moment où vous avez écrit le code que vous êtes en train de maintenir et de vous poignarder avec un icepick. Donc, si vous voulez maintenir ce code au fil du temps, prenez le temps de le faire correctement. Cela signifie: une sorte de système de modèle, pas de balises PHP incorporées dans le code HTML, des fichiers séparés pour des fonctionnalités séparées, et classes classes classes!
Vos orbites vous remercient.
Je voudrais réitérer les autres réponses ici. Cela dépend de la taille de l'application et de ce que vous voulez apprendre sur la POO.Je ferais attention d'apprendre la POO en utilisant PHP cependant. En ce qui concerne PHP est orienté objet ... PHP4 avait quelques éléments OOP plaqué sur lui, PHP5 est mieux mais il n'est pas cuit dans la langue. PHP fonctionne dans les deux sens, et personnellement j'aime que vous pouvez choisir.
Dans mon esprit, nous PHPer pouvons thorouly jeter le concept d'objet (instance de classe), nous avons seulement besoin de classe Array et Mode:
Tous les tableaux à l'appui de mode initial toute fonction de tableau comme c'est la méthode:
<?php
$array1->array_flip(this);
?>
Utilisez ->mode() pour valider l'ensemble minimal de données, puis la classe de commutateur de mode:
<?php
$array1->mode('class1', $success);
?>
Toute classe de mode n'a pas ->construct(), mais a ->validate() pour valider le jeu de données minimal. Le tableau dans un mode peut toujours utiliser la fonction de tableau comme méthode, mais après l'utilisation de l'un d'entre eux, le tableau sera remis en mode de base, et nous devons utiliser ->mode('class1', $success); pour revenir en mode retour.
La pensée radicale est la programmation centrée sur les données, nous avons besoin de séparer les données (tableau) et l'activité (méthode de classe).
Nous pourrions modifier le moteur PHP, pour se débarrasser des parties de OO (orienté objet), et soutenir la classe de mode, nous pourrions l'appeler MyPHP.
Par exemple: $array_man1 pourrait être mis en deux modes: cls_normal_man et cls_crazy_man:
<?php
$array_man1->mode('cls_normal_man')->normal_method1()->mode('cls_crazy_man')->crazy_method1();
?>
Je en train d'essayer de trouver des moyens de promouvoir un meilleur code PHP, mais il est une tâche ardue. . . –