Rappresenta la gerarchia degli oggetti Java con le classi nidificate

Question

Rappresenta la gerarchia degli oggetti Java con le classi nidificate

#1 da (3 voti)

0

Stavo lavorando con alcune API che sono state utilizzate internamente, e mentre osservavo il loro codice ho trovato qualcosa del genere:

public class Parent {
     @Data
     public static class Child {

        private List<GrandChild> grandChildren;

        @Data
        public static class GrandChild {
            private String name;
        }
    }
}

Questa rappresentazione gerarchica è stata ampiamente utilizzata, e ha reso la creazione di alcuni elenchi molto controintuitivi, come ad esempio List<Parent.Child.GrandChild.NewBorn> . Queste rappresentazioni sono state utilizzate per rappresentare una risposta JSON. Quindi questa gerarchia corrispondeva alla gerarchia restituita nella risposta.

Il mio problema principale era che era prolisso e aveva un sacco di codice duplicato, ad esempio, creando un'altra classe Parent2 significherebbe che dovremmo copiare le definizioni delle classi di Child e GrandChild nel nuova Parent2 class.

Ci sarebbero dei vantaggi nell'utilizzare tali rappresentazioni?

Ci sono dei lati negativi di questo utilizzo di cui non sono a conoscenza?

Ha dei guadagni in termini di prestazioni?

coding-style java class-design json

posta engma 10.05.2018 - 04:57

fonte

1 risposta

Leggi altre domande sui tag coding-style java class-design json

Sto cercando alcuni consigli sull'architettura della soluzione per ASP.NET Core e WebApi [chiuso] Come pianificare le attività con gli sviluppatori junior? [chiuso]

score 3 · Accepted Answer

Quello che hai trovato è un buon esempio di stile di codifica estremamente scadente.

Per rispondere alle tue domande:

Would there be any benefit of using such representations?

Sì, se usato entro determinati limiti. Ad esempio, se hai una classe denominata User da memorizzare nel database e vuoi una vista che unisce la tabella user con poche altre tabelle per creare una vista a livello di applicazione di fantasia (non una vista di database!), potresti avere una classe chiamata User.FancyView . Trovo che sia meglio che avere User e UserFancyView o peggio, User e FancyView (che non indica una vista di fantasia di quale classe), o myapp.user.User e myapp.user.FancyView (che crea un pacchetto solo per una tabella di database, il che significa che avrai un numero enorme di pacchetti).

Are there any downsides to this usage that I am not aware of?

Sei già consapevole degli svantaggi, che sono davvero nomi di oggetti prolissi e un sacco di codice duplicato durante la copypasting. Poiché le classi interne statiche sono solo classi regolari che risiedono nel codice di un'altra classe, non ci sono altri aspetti negativi.

Tuttavia, se hai classi interne non statiche, allora l'oggetto classe interna non può esistere senza l'oggetto classe esterno.

Does it have any performance gains?

No, non è così. Le classi interne statiche sono solo classi regolari con un nome che ha punti in esse. Sono archiviati su disco per separare anche% file% di file. In questo modo non ottieni nemmeno un disco rigido minore per ottenere un guadagno in termini di prestazioni di eliminazione, perché sono memorizzati in file .class diversi.

Nel complesso, probabilmente uso classi interne più di quello che altre persone usano, incluse classi interne più anonime. Mi piace la funzionalità del linguaggio Java. Si tratta di uno stile di codifica e alcune guide di stile possono proibire l'uso di classi interne. Tuttavia, smetterei di nidificare a un livello ragionevole. Un livello di nidificazione ( .class ) è buono, due livelli di nidificazione ( User.FancyView ) richiedono una giustificazione estremamente buona.