È un approccio per memorizzare classi appartenenti a una singola funzione in una singola cartella, superiore alla classificazione in più cartelle "di comunità"?

Question

È un approccio per memorizzare classi appartenenti a una singola funzione in una singola cartella, superiore alla classificazione in più cartelle "di comunità"?

#1 da (1 voti)
#2 da (1 voti)

0

nel mio progetto sto scoprendo che mescolo e abbino i seguenti due modelli, quando si tratta di organizzare le classi in cartelle / spazi dei nomi:

Blocchi MVC modulari

module/Album/Feature/Controller/AlbumFeatureController.php
module/Album/Feature/Repository/AlbumFeatureRepository.php
module/Album/Feature/Form/AlbumFeatureForm.php

- - - - 

module/Album/Feature2/Controller/AlbumFeature2Controller.php
module/Album/Feature2/Repository/AlbumFeature2Repository.php
module/Album/Feature2/Form/AlbumFeature2Form.php

- - - - 

- - - - 

module/Album/Feature100/Controller/AlbumFeature100Controller.php
module/Album/Feature100/Repository/AlbumFeature100Repository.php
module/Album/Feature100/Form/AlbumFeature100Form.php

Pro: se voglio rimuovere una feature, rimuovo la cartella chiamata "Feature" e apporto alcune modifiche
Con: crea più cartelle

Community MVC Blocks

module/Album/Controller/AlbumFeatureController.php
module/Album/Controller/AlbumFeature2Controller.php
. . .
module/Album/Controller/AlbumFeature100Controller.php

- - - -

module/Album/Repository/AlbumFeatureRepository.php
module/Album/Repository/AlbumFeature2Repository.php
. . . 
module/Album/Repository/AlbumFeature100Repository.php

- - - - 

module/Album/Form/AlbumFeatureForm.php
module/Album/Form/AlbumFeature2Form.php
. . . 
module/Album/Form/AlbumFeature100Form.php

Pro: tutti Controllers si trovano nella cartella "Controllers"
Con: qui quando voglio eliminare la funzione, devo andare individualmente nelle cartelle Controller, Form, Repository e cercare le classi che prendono il nome dalla mia funzione e rimuoverle.

Sto iniziando a favorire l'approccio modulare grazie alla sua compartimentalizzazione memorizzata nel file system.

Domanda:

è un approccio superiore a un altro o entrambi sono ugualmente intercambiabili in base ai propri bisogni, gusti e preferenze?

php code-organization zend-framework file-structure

posta Dennis 10.05.2016 - 19:30

fonte

2 risposte

Leggi altre domande sui tag php code-organization zend-framework file-structure

Come attraversare la "lista collegata" come struttura con nodi paralleli Differenza fondamentale tra una classe statica e funzioni con nomi assegnati

score 1 · Answer 1

In realtà questa è una questione di coesione.

Da wikipedia:

In computer programming, cohesion refers to the degree to which the elements of a module belong together.

Puoi consultare questo articolo sulla coesione: link

Per me l'approccio modulare, come lo chiami, è la rappresentazione della coesione funzionale, che è indicata come miglior errore di battitura.

Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module

score 1 · Answer 2

Questa è la domanda perché la capisco:

Esiste un modo migliore per classificare i file che contengono codice? Ecco due classificazioni di esempio.

Non proprio. Nella mia esperienza, entrambi gli approcci sono validi. L '"approccio migliore" dipende dal codice base, dall'organizzazione e, eventualmente, dalle preferenze personali.

I progetti più piccoli / più recenti iniziano e beneficiano del primo approccio "modulare". Aggiungete funzionalità che possono o non possono essere mantenute a lungo termine. Le codebase più piccole e più dinamiche di solito coinvolgono le funzioni di refactoring e non come componenti spesso o per funzione. Il processo di aggiunta di una funzione è ben definito e causa un impatto minimo su altre aree della base di codice.

Il codebase più grande, più vecchio e più complesso è generalmente meglio gestito in base alla funzionalità e alla comunanza degli elementi del codice, piuttosto che alle funzioni che supporta. Quindi la versione "community" è un approccio migliore. Questo aiuta a modificare i cambiamenti come nuove versioni di librerie, aggiornamenti di database, modifiche ai font, ecc.

Le organizzazioni con sviluppatori che lavorano su singole funzionalità possono trarre vantaggio dall'approccio "modularizzato". Le organizzazioni che hanno diversi sviluppatori che lavorano sulla stessa base di codice probabilmente divideranno il lavoro più basato sul concetto di "comunità": uno funziona sui controller mentre un altro fa l'interfaccia utente.

Considerate anche che state nominando file che rappresentano concetti che il codice dovrebbe contenere. Tuttavia, diversi sviluppatori avranno approcci e / o prospettive diversi sui contenuti specifici di ciascun file. Il che significa che potresti prendere in considerazione del codice per appartenere al controller mentre un altro sviluppatore lo vedrebbe come appartenente al modulo. Ora cosa?

Più persone hai coinvolto nel tuo progetto, più importante è dividere per "funzione" piuttosto che per "caratteristica" per forzare il raggruppamento della base di codici con funzionalità comuni. Meno persone hai, più è importante fare il contrario in molti casi, in modo che uno sviluppatore incaricato di modificare una funzione mantenga le modifiche contenute in quella funzione.

La tua tendenza a favorire un approccio rispetto all'altro è probabilmente dovuta alla natura del tuo lavoro e / o all'approccio organizzativo allo sviluppo e al mantenimento del codice, in contrasto con uno innato superiormente rispetto all'altro.