Va bene avere molte librerie per la modularità?

Question

Va bene avere molte librerie per la modularità?

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

2

Situazione:

La mia app esiste come versione standard e di marca, la versione di marca ha alcune funzionalità aggiuntive minuscole, ma la maggior parte delle cose è la stessa.

In questo momento ho una libreria di base con popup e elementi visivi che posso usare in ogni app che faccio. Poi ci sono diversi moduli (librerie) (funzionalità dell'app "cose che si possono fare") e due progetti di app finali.

Un modulo, nella versione di marca, può utilizzare l'hardware ausiliario (ah). Quindi la mia idea era di suddividere il modulo in un modulo base della libreria e creare una libreria aggiuntiva per l'ah e quindi creare due moduli uno con e uno senza ah. In questo modo qualsiasi modifica di base del modulo verrebbe incorporata in tutte le app, ma quella con il marchio avrebbe scelto il modulo con ah e l'app standard avrebbe preso quella senza.

C'è una possibilità che una seconda versione di marca arriverà presto, con alcuni moduli diversi e forse diversi hardware usati da alcuni moduli. Dovrei dividermi ancora di più e temo per il caos. Ma l'unico altro modo in cui vedo è che io creo omni-moduli in grado di gestire ogni possibile variazione e verranno istanziati con una selezione delle funzionalità da contenere. Ma è chiaro che "brand a" non utilizzerà mai l'hardware di "marca b" e viceversa, quindi la selezione sarà solo "standard, a o b", ma il modulo è progettato per gestirli tutti i quali potrebbero gonfiare il modulo.

Quindi, come avrei suddiviso le mie librerie e il mio modulo per gestire questo senza molto caos?

modifica

La mia preoccupazione principale è la manutenzione a lungo termine. Dopo 2 anni qualcuno vuole aggiungere una funzionalità alla versione di marca xyz e devo capire in quale libreria / a quale livello implementarla per non toccare altre versioni.

Avere molte librerie può rendere difficile capire le relazioni / dipendenze tra di loro, ma ciò può essere compensato con una documentazione adeguata. Avere tutto in un solo lib / modulo significa che ho bisogno di seguire le variabili che abilitano / disabilitano le funzionalità per scoprire dove cambiano / fanno cose.

Ma fino a che punto mi divido?

architecture mobile android

posta NikkyD 01.08.2017 - 16:08

fonte

2 risposte

Leggi altre domande sui tag architecture mobile android

comunicare i micro-servizi in un linguaggio statico (java) Enforcing constraint across databases

score 1 · Answer 1

Se questo fosse il mio progetto, farei tutti i componenti che sono comuni nei loro moduli. Quindi, permettendo loro di essere controllati, testati e rilasciati sui propri programmi. Creare un livello intermedio che faccia leva su flag di funzionalità per abilitare e disabilitare le parti dell'applicazione. Questo potrebbe essere fatto manualmente nella configurazione o automaticamente controllando quali moduli sono caricati. Infine, lo completerei creando applicazioni di marca che estendevano il livello intermedio e selezionato le funzionalità di cui avevano bisogno, oltre a fornire le risorse per il branding.

Module 1--|                 |--Branded A
          |                 |
Module 2--|---Middle Layer--|--Branded b
          |                 |
Module 3--|                 |--Branded C

Per quanto riguarda il caos, alcuni piccoli moduli potrebbero essere disapprovati da alcuni, tuttavia, hanno molti vantaggi pratici rispetto a progetti monolitici più ampi. I piccoli moduli sono più facili da scrivere, sono più facili da testare, più facili da eseguire e più facili da rilasciare. L'unico modo per evitare il caos che gestisce i moduli è quello di scomporre le funzionalità che sono generalmente complete e c'è una necessità diretta di condividerle.

Se un modulo è in pesante sviluppo e viene rilasciato frequentemente, puoi ridurre il caos aggiornando ogni settimana anziché ogni giorno.

score 0 · Answer 2

Accetto che suddividere i fetureset in sezioni verticali è una buona cosa a livello di classi / spazi dei nomi.

A livello di modul / lib di differenti / indipendenti, vedo più danni che benefici di avere una libreria specifica per brand-app: potrebbe rendere più difficile il maintanace e il refactoring:

quale funzione è disponibile in quale modulo / marchio: questa è una decisione politica. Presumo che questo cambierà molto nel tempo.

Avere un modul / lib per set di funzionalità è una buona cosa. Non ha una modul / lib per marca-app.

Preferirei avere costante booleana globale specifica della versione in cui il compilatore / offuscatore ottimizzerà le funzioni se const è falso.

// class GlobalConfig is different for every variant
public class GlobalConfig {
    public static final boolean hasFeatureA = false;
}

if (GlobalConfig.hasFeatureA) {
    // this code will be removed by java compiler if GlobalConfig.hasFeatureA == false
}