Comment dois-je organiser la structure de répertoires d'une bibliothèque de programmation à usage général?

Question

J'ai écrit mon propre usage général PHP bibliothèque depuis un moment et je suis en train de réfléchir à la façon d'organiser la structure de répertoire, mais je voulais avoir les idées avant que je officialisé la structure de répertoire de la bibliothèque.

Voici ce que j'ai à ce jour: https://github.com/homer6/altumo/tree/master/source/php

Je pensais que je pouvais soit faire "Par Sujet" ou "Par Catégorie". Jusqu'à présent, je ne peux que penser à un exemple que j'aime de la "Catégorie": Boost http://www.boost.org/doc/libs/1_46_1/?view=categorized

Aussi, Qt est organisé par le module, mais je pense que c'est un peu brouillon, car le tout est un peu en peluche dans QtCore http://doc.trolltech.com/latest/modules.html

Des idées?

Merci à l'avance.

Mise à JOUR: J'ai trouvé un très bon livre qui m'a montré un certain nombre de grands de conception de la bibliothèque conventions à suivre: http://www.apibook.com/blog/

Mise à JOUR: J'ai trouvé un article intéressant qui parle de l'organisation du code (http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html). Au fond, il dit: "Qu'est-ce que votre arbre de code va ressembler? Il ne veut pas de ces mots pour le décrire: simple, pragmatique, élégant, orthogonal, composable. C'est un idéal, la réalité est un peu différente."

Answer 1

Tout d'abord, la structure choisie est un compromis, ce qui signifie que vous aurez à gérer et prioriser certains aspects par rapport à d'autres en fonction de votre objectif. Il y a quelques groupement de critères que vous pourriez suivre, tels que:

• La Cohésion fonctionnelle, je pense que cela devrait être la plus forte dans la conception de votre. Classes/fichiers/ressources avec la même ou une fonctionnalité similaire devrait être ensemble
• Hiérarchie des composants, en Fonction de la granularité de niveau, vous choisissez, ce qui signifie que si vous préférez fine des composants vs gros-grain, vous avez plus ou moins de fichiers de ressources dans un dossier. Ceci peut être contrôlé à l'aide de la hiérarchie de dossiers et de nidification.
• Changement, Certains fichiers sont plus susceptibles d'être modifiées que d'autres, vous devez garder cela à l'esprit afin de fournir une hiérarchie de dossiers en fonction de la probabilité d'être modifié.
• L'extensibilité, Pour un cadre utile et adaptable à presque n'importe quel scénario que vous avez à offrir la possibilité d'étendre les composants et les fonctions. Ajout d'un dossier pour les extensions (aka plugins) est une bonne idée.

Il y a beaucoup de critères à utiliser, mais gardez toujours à l'esprit le Principe de BAISER. Vous pouvez effectuer une recherche pour la gestion des paquets dans des livres comme Le Unifié de Développement Logiciel (Ivar Jacobson et coll.), J'espère que cela pourrait être utile.

Answer 2

Car il est multi-usages de la bibliothèque consacrée à résoudre polyvalent problèmes ou de fournir des interfaces pour caractéristiques communes, il est préférable d'avoir de la structure en subject qui peut être DataType/Technologie/Langue/Protocole etc. comme suit:

+ Http
  - request
  - response
  + util
    - status_codes
+ Html
  - Validator
  + Form
    - UploadFile
  + Tag
+ JavaScript
  - JSON
+ Ajax
+ XML
  - Reader
  - Writer
  - Parser
+ DataType
  - Array
  - Integer
  - String
  - Double
  - Float
  + util
    - datatypes_cast_lib

Sur le dessus, nous avons:

• Http qui est un protocole de sorte que votre Http.request serait une interface pour effectuer la requête Http
• Html qui est un langage de balises, de sorte Html.Form.UploadFile fournira développeur avec des fonctionnalités pour créer de télécharger le fichier de formes
• Le JavaScript qui est un langage de programmation, de sorte que votre Javascript.JSON permettraient de résoudre les problèmes de conversions de JSON à des Tableaux peut-être
• Ajax qui est de la technologie
• XML qui est langage de balisage
• Le type de données qui est ... eh bien, le type de données.

Un avis, qu' status_codes restent sous util en Http. Chaque sous-bibliothèque peut avoir son propre util fonctionnalités comme l' DataType lib peut-être besoin datatype_cast_lib de savoir comment jongler avec les types de données.

De cette façon, de l'organisation de bibliothèque pour la plupart ressemble organisation de PECL

Bonne question, d'ailleurs! J'ai posé la même question à moi-même fréquemment. J'ai été l'organisation et la réorganisation de ma structure de répertoires depuis des années. Cela dépend vraiment de projet. J'ai adapté la structure ci-dessus correspondant à la structure que vous avez fournies ici.

Answer 3

Je suggère que vous regardez la façon dont les choses sont organisées dans deux récentes de php 5.3 cadres, Symfony2 et de Lithium.

Le core devs derrière eux étaient actifs (avec d'autres grands cadre de développeurs et php célébrités) dans la définition standard de php 5.3 conventions de nommage ainsi que leurs composantes respectives pourraient jouer les uns avec les autres, Zend, et d'autres librairies/frameworks qui pourrait suivent les mêmes conventions:

http://groups.google.com/group/php-standards/web/php-coding-standard

Dans les deux cas, les bundles/bibliothèques sont des citoyens de première classe, et les deux ont suivi des tendances similaires quand il s'agit de les organiser.

La batterie au Lithium de base, en particulier, est une bibliothèque dans son propre droit. Elle est organisée comme suit:

$ ls
LICENSE.txt analysis    core        g11n        security    template    tests
action      console     data        net         storage     test        util

(J'ai tendance à trouver Symfony 2 un peu messier/moins prédictive, mais c'est juste mon propre avis.)

Answer 4

S'il vous plaît soyez compatible PSR-0 , quelle que soit la structure que vous allez utiliser.

Je suggère personnellement d'utiliser la structure de répertoires PEAR2 .

Answer 5

Je dirais un bon endroit pour commencer est de regarder comment les autres cadres et/ou des bibliothèques le font.

Personnellement, j'aime la façon dont le Zend Framework est organisé, avec un assez plat, espace de noms, d'avoir tous les principaux composants du Zend. Lors de l'utilisation du Zend MVC structure de projet, vous obtenez une ajouté autochargeur la traduction _ à / toutes les classes sont nommés, comme Zend_Form et le mettre dans un fichier appelé Form.php à l'intérieur du Zend, de sorte que lors de l'appel d' new Zend_Form - l'autochargeur recherche Zend/Form.php. Seulement le "principal" de la classe est directement à l'intérieur du Zend dossier, tous les autres fichiers de classe, comme des exceptions et le résumé sont mis à l'intérieur d'un Zend/Form le dossier et les noms de classe nommé comme Zend_Form_Exception - ce qui cause l'autochargeur de regarder pour Zend/Form/Exception.php.

Un autre point est de garder backend logique, loin de tout dossier public_html. E. G - seuls les fichiers qui devraient être directement accessibles pour les utilisateurs devraient être en ligne ici (javascript, css, et votre loader.php + .htaccess). Alors loader.php inclure les fichiers dont il a besoin, en général un répertoire de niveau supérieur.

Les bibliothèques externes sont généralement traitées comme telles, et séparé du reste du code dans /lib, /bibliothèque et/ou /vendor dossier pour indiquer que les auteurs sont responsables de ces classes.