È usuale scrivere oggetti dominio Java / oggetti di trasferimento dati con variabili membro pubbliche su piattaforme mobili?

8

Recentemente abbiamo eseguito una revisione del codice del codice Java dell'applicazione mobile che è stato sviluppato da un appaltatore esterno e abbiamo notato che tutti gli oggetti dominio / oggetti di trasferimento dati sono scritti con questo stile:

public class Category {
    public String name;
    public int id;
    public String description;
    public int parentId;
}

public class EmergencyContact {
    public long id;
    public RelationshipType relationshipType;
    public String medicalProviderType;
    public Contact contact;
    public String otherPhone;
    public String notes;
    public PersonName personName;
}

Naturalmente, questi membri sono quindi accessibili direttamente ovunque nel codice. Quando gli abbiamo chiesto questo, gli sviluppatori ci hanno detto che si tratta di un modello di progettazione di miglioramento delle prestazioni abituale che viene utilizzato su piattaforme mobili, perché i dispositivi mobili sono ambienti a risorse limitate. Non sembra avere senso; l'accesso ai membri privati tramite getter / setter pubblici non sembra possa aggiungere un sovraccarico. E i benefici aggiunti dell'incapsulamento sembrano superare i benefici di questo stile di codifica.

Questo è generalmente vero? Questo è qualcosa che viene normalmente fatto su piattaforme mobili per i motivi sopra riportati? Tutti i feedback sono benvenuti e apprezzati -

    
posta Sean Mickey 06.06.2012 - 08:34
fonte

5 risposte

4

the developers told us that this is a customary performance enhancement design pattern that is used on mobile platforms, because mobile devices are resource-limited environments

Supponendo che gli autori non si siano preoccupati di fornire riferimenti autorevoli per giustificare la loro "decisione progettuale", si è abbastanza sicuri di considerarlo una scoreggia cerebrale di programmatori non qualificati.

Sono stato in rack Java mobile per diversi anni (avendo ancora 2 o 3K di reputazione SO nei tag correlati perché lo uso come modo per non dimenticare le basi), recensito e scritto un sacco di codice, studiato più specifiche, tutorial e guide di stile - nessuno di questi ha mai menzionato nemmeno una sfumatura di differenza che questo tipo di design potrebbe avere rispetto a Java SE. Se sei interessato a trovare tutorial e guide di questo tipo, controlla i wiki dei tag SO in tag pertinenti come java-me , midp ecc.

    
risposta data 06.06.2012 - 09:26
fonte
3

C'è un granello di verità nell'affermazione dell'appaltatore.

Da qualche tempo, gli sviluppatori di giochi Android sono stati incoraggiati a evitare getter e setter interni per motivi di prestazioni. Tuttavia, questo consiglio si applica solo agli sviluppatori di giochi che hanno bisogno di spingere i dispositivi al limite e devono sacrificare altri benefici per raggiungere i loro obiettivi. Inoltre, con il rilascio di Gingerbread, questo ha anche giocato beneficia poco di questa pratica.

Più di una volta, ho incontrato gli sviluppatori per dare consigli sulle "migliori pratiche" o seguire le linee guida che sono perfettamente valide in uno scenario (spesso storico) ma che semplicemente non si applica al caso in esame. Il più delle volte, questo perché lo sviluppatore ha dimenticato (o non ha mai saputo) i motivi per cui perché il suo consiglio ha applicato il primo posto, quindi presumono che debba essere valido per tutti i casi in ogni momento. Nella mia esperienza, questo è particolarmente comune quando si parla di ottimizzazione delle prestazioni. Questo sembra essere il caso qui.

L'approccio corretto alle prestazioni è:

  1. per farlo bene prima di eseguire se veloce
  2. utilizza le metriche per dirti cosa ottimizzare e di nuovo per determinare se i tuoi sforzi hanno esito positivo
risposta data 08.06.2012 - 08:16
fonte
0

Hai ragione che questo probabilmente non rappresenta una differenza significativa nelle prestazioni, ma se è un segno che in generale gli sviluppatori stanno tenendo d'occhio la riduzione del numero di chiamate al metodo (che sono relativamente costose) e altri costi generali , significa che stanno facendo un buon lavoro.

Discuterò in modo più approfondito con loro sulla loro filosofia generale di codifica per vedere se questo è ciò a cui mirano.

(stai anche partendo dal presupposto che i campi pubblici sono indiscutibilmente cattivi e che i getter / setter sono l'unico modo, che non penso che potresti trovare supporto al 100%, anche su questo sito)

    
risposta data 06.06.2012 - 09:14
fonte
0

Is this generally true? Is this something that is normally done on mobile platforms for the reasons given above?

Può essere vero che storicamente è stato fatto in questo modo; per esempio. perché le piattaforme mobili precedenti sono particolarmente limitate in termini di risorse ... o hanno degli ottimizzatori particolarmente scadenti (senza nominare alcun nome :-)).

Ma non penso che la "consuetudine" o la "pratica storica" siano rilevanti. Hai il diritto assoluto di dire quali standard di codifica vuoi che il tuo appaltatore aderisca. Inoltre, se la tua piattaforma non è limitata da risorse (o qualsiasi altra cosa) la giustificazione della "pratica abituale" del tuo appaltatore è vuota ... perché le condizioni che rendono accettabile questa sfortunata pratica non esistono.

    
risposta data 06.06.2012 - 09:45
fonte
0

Per gli oggetti di dominio questa è spazzatura design - vuoi incapsulare la logica sugli oggetti del dominio, o almeno vuoi essere in grado di aggiungere logica facilmente successiva .

Ma per DTO utilizzo design simili perché non hanno logica, sono DTO.

Suppongo che qualsiasi overhead delle prestazioni (che sarebbe comunque minimo) verrà comunque ottimizzato dalla macchina virtuale java.

    
risposta data 06.06.2012 - 12:22
fonte

Leggi altre domande sui tag