Servizio / applicazione basata su componenti in Java

1

Ho un progetto Java la cui architettura è piuttosto orientata ai componenti, e mi chiedo

  • se questo è un modo comune per organizzare il codice
  • quali regole / modelli sono usati,
  • se esiste un nome per questo stile di codifica.

Pacchetti di componenti

src/namespace/component1
src/namespace/component1/error
src/namespace/component1/impl
src/namespace/component1/data

src/namespace/component2
...

Ogni componente è un po 'come un servizio. Alcuni lanciano una discussione, alcuni aprono alcuni socket per le connessioni, ecc.

Struttura del componente

// "Root" of the package : Interfaces + InterfaceCoordinator
src/componentx/componentx/ComponentXInterfaceCoordinator.java
src/namespace/componentx/IStartup.java
src/namespace/componentx/IinterfaceFoo.java

// Implementation of the component
src/namespace/componentx/impl/Startup.java
src/namespace/componentx/impl/Foo.java
...

// Exceptions this component can throw
src/namespace/componentx/error/SomeError.java
...

// Data (not really sure exactly what we can call data or not)
src/namespace/componentx/data/SomeConfiguration.java
src/namespace/componentx/data/SomePersistedEntity.java
src/namespace/componentx/data/SomeNonPersistedEntity.java

Applicazione principale

public static void main(String[] args) {
  ...
  logger.info("Initialize ComponentX Component");
  ComponentXInterfaceCoordinator.getStartup().init();

  logger.info("Initialize ComponentY Component");
  ComponentYInterfaceCoordinator.getStartup().init();
  ...

Coordinatore dell'interfaccia ComponentX

ComponentXInterfaceCoordinator di classe pubblica {

public static IStartup getStartup(){
    return Startup.getInstance();
}

Interfaccia di avvio / impl

public interface IStartup {

    public void init(); 
}

public class Startup implements IStartup{

    private static Startup instance = null;
    private Logger logger = Logger.getLogger("ComponentX");


    public static IStartup getInstance() {
        if(instance==null)
            instance = new Startup();
        return instance;
    }

    @Override
    public void init() {

        logger.debug("Initialising subcomponents: xxx");
        SubComponentXy.getStartup().init();

        logger.debug("Initializing Connection Manager Component");
        ComponentX.getInstance().addProtocol(new MobileSystemListeningProtocol());
        ComponentX.getInstance().startProtocols();
    }
}

Inoltre / parte delle domande che ho posto all'inizio:

Anche la maggior parte del componente principale classificato ha questo codice getInstance() che restituisce l'istanza singleton della classe

getInstance() segue una specie di modello? o anti-pattern? È in realtà solo un modo per aggirare il fatto che i metodi statici non possono essere dichiarati nelle interfacce (in java < = 1.7)? Se avvio un nuovo progetto in JAVA 1.8, dovrei farlo diversamente?

    
posta Cyril Duchon-Doris 02.02.2016 - 20:47
fonte

1 risposta

2

Pacchetti di componenti

Come per i pacchetti di componenti - questo approccio è solitamente chiamato struttura di cartelle verticali (directory / pacchetto) ed è comune per progetti più grandi.

Struttura del componente

Le convenzioni sui nomi sono un po 'non tradizionali:

  • Interfacce con prefisso capitale I - questa è la convenzione C #, non quella Java. In Java, l'interfaccia è denominata senza I - in questo caso Avvio, implementazione quindi comunemente StartupImpl o qualcosa di più descrittivo
  • Errore - Sospetto che questo contenga eccezioni. Gli errori in Java sono un tipo speciale di Throwables, ma non devono essere realmente utilizzati o lanciati dall'applicazione stessa. Se queste sono effettivamente delle eccezioni, dovrebbero essere nominate di conseguenza.
  • Dati - questi sono solitamente chiamati DTO - Oggetto Trasferimento dati. A volte VO (per oggetto valore) nella terminologia DDD. O se ha un'identità (tipicamente se è persistente nel DB), allora forse "entità" invece di dati, non sono sicuro di cosa ci sia dentro.

Interfaccia di avvio / impl

Tutti i componenti sembrano essere singleton (e thread non sicuri). Suppongo che tu chiami i metodi di altri servizi attraverso il metodo statico getInstance (). Ciò riduce OOP allo stile di programmazione essenzialmente procedurale. Questo è esattamente il motivo per cui singleton è spesso considerato anti-pattern. Ha i suoi casi d'uso validi, ma questo non è uno di questi.

Questo anti-pattern nasce dalla necessità di riunire tutti i componenti, farli cooperare. In Java non esiste un modo integrato per farlo correttamente, ecco perché questo stile è abbastanza comune (ci sono stato anche lì). La risposta a ciò è Inversione del controllo e Iniezione delle dipendenze in particolare. Guarda Spring o Guice.

    
risposta data 02.02.2016 - 21:09
fonte