2010-03-04 11 views
5

Questo potrebbe essere un problema di età avanzata e sono sicuro che ognuno ha i propri modi. Supponiamo che io sono alcune proprietà definite comeProprietà java: esporre o non esporre?

secret.user.id=user 
secret.password=password 
website.url=http://stackoverflow.com 

Supponiamo che io sono 100 diverse classi e posti in cui ho bisogno di utilizzare queste proprietà. Quale è buono (1) Creo una classe Util che caricherà tutte le proprietà e le servirà utilizzando una costante di chiave Ad esempio: Util è un singleton che carica tutte le proprietà e continua con la chiamata getInstance().

Util myUtil = Util.getInstance(); 
String user = myUtil.getConfigByKey(Constants.SECRET_USER_ID); 
String password = myUtil.getConfigByKey(Constants.SECRET_PASSWORD); 
.. 
//getConfigByKey() - inturns invokes properties.get(..) 
doSomething(user, password) 

Quindi ovunque io abbia bisogno di queste proprietà, posso eseguire i passaggi sopra.

(2) Creo una classe significativa per rappresentare queste proprietà; per esempio, ApplicationConfig e fornire getter per ottenere proprietà specifiche. così sopra il codice può apparire come:

ApplicationConfig config = ApplicationConfig.getInstance(); 
doSomething(config.getSecretUserId(), config.getPassword()); 
//ApplicationConfig would have instance variables that are initialized during 
// getInstance() after loading from properties file. 

Nota: il file delle proprietà in quanto tale avrà solo piccole modifiche in futuro.

La mia scelta personale è (2) - fammi sentire alcuni commenti?

+0

Le proprietà non dovrebbero essere memorizzate nella cache in ogni caso, quindi nessuna penalizzazione delle prestazioni se lo si è caricato in più punti diversi? – willcodejavaforfood

+0

Perché il piatto della caldaia? Non sono un buon suggerimento. Inoltre, l'ho taggato con il design del programma. Mi piace il codice che funziona bene e che legge bene. –

risposta

1

trovo il primo approccio ad essere più dettagliato del necessario. (Soprattutto se non ci si aspetta che le proprietà cambino molto.) Inoltre, utilizzando il secondo approccio è possibile gestire i problemi di casting/tipo quando le proprietà vengono caricate invece di quando vengono utilizzate.

+0

piaciuto il punto di fusione. –

0

Credo che la mia prima domanda è perché si desidera creare un'istanza di qualcosa che si sta dicendo è un singleton (hai menzionato usando il codice come Util.getInstance()). Un singleton ha solo 1 istanza, quindi non dovresti provare a istanziare più copie nel tuo codice.

Se i dati sono statici (come questo sembra essere) creerei un singleton e recupererò i valori da esso.

+1

Questo * è * uno dei modi in cui si accede a un'istanza singleton. – alphazero

+0

concordato, Util.getInstance(). WhateverMethod .. è sufficiente. Copie create (se mai l'ho fatto davvero era solo per chiarezza del codice) Ma la tua risposta non era completa. In entrambi i casi ho singleton.La domanda è se utilizzare un approccio basato su KEY costante o modellare alcune classi che forniranno getter –

0

Non penso ci sia alcun vantaggio significativo di un metodo rispetto all'altro e non penso che la soluzione (1) sia più sicura, solo perché fornisce una chiave di proprietà invece di un getter java per ottenere le password .

Se dovessi sceglierne uno, prenderei l'opzione (2).

+0

hm .. Penso che myUtil.getConfigByKey (Constants.SECRET_PASSWORD); è sicuro o (meno per questo) come: config.getPassword() –

+1

Concordato che sia sicuro (o meno). Se myUtil è stato scritto bene e la sicurezza di JVM è stata migliorata (per evitare la riflessione/l'ispezione di variabili private), potrebbe essere * abbastanza * sicuro –

2

farlo nel modo più semplice (una classe con valori statici):

package com.domain.packagename 

public class Properties { 
    private static String hostName; 
    public static getHostName() { return hostName; } 
    private static int port; 
    public static int getPort() { return port; } 

    public static void load() { 
     //do IO stuff, probably 
     hostName = ??; 
     port = ??; 
     //etc 
    } 
} 
+1

Votato 1 dato che questo fornisce alcune buone idee. Una classe immutabile può essere creata per rappresentare le proprietà come: Configurazione di classe pubblica { public final String userId; password stringa finale pubblica; public final int timeOut; configurazione statica privata CONFIG = null; configurazione privata (oggetti di scena Properties) {// codice per popolare le variabili finali // alcuni Singleton Mumbo-Jumbo} getInstance public static() {// ... } –

1

L'opzione (2) per mantenere i getter specifici delle applicazioni sembra migliore e pulita. Le chiavi finali statiche pubbliche di un'interfaccia sono state un cattivo progetto in Java per anni.

+0

Sì! Anche a me non piacciono le chiavi finali statiche pubbliche da un'interfaccia –

Problemi correlati