metodo statico o non statico per classe immutabile

Question

Data la definizione di classe riportata di seguito. Come procedere nel decidere se i metodi di stub dovrebbero essere statici o non statici?

class Point { 
    private final int x; 
    private final int y; 

    public Point(int x, int y) { 
     this.x = x; 
     this.y = y; 
    } 

    // Should the methods add(), subtract() and inverseOf() be non-static ... 

    public Point add(Point point) { 

    } 

    public Point subtract(Point point) { 

    } 

    public Point inverseOf() { 

    } 


    // Or static? 

    public static Point add(Point point1, Point point2) { 

    } 

    public static Point subtract(Point point1, Point point2) { 

    } 

    public static Point inverseOf(Point point) { 

    } 
} 

Answer 1

Vorrei andare per esempio i metodi. Si ha quindi la capacità di rendere i metodi parte di un inteface e sovrascriverli. Otterrai il vantaggio quando dovrai gestire punti 2D o punti 3D e disporre di un codice client che non gli interessa e che dovrà semplicemente eseguire operazioni sui punti che implementano l'interfaccia.

Answer 2

Utilizzare un metodo statico quando il corpo del metodo non dipende da una particolare istanza.

Come esempio, guarda il tuo metodo add(Point, Point). Si sommano i due Point s che vengono passati alla funzione come argomenti e si restituisce un altro Point. Questo ha davvero bisogno di un riferimento interno this ad alcuni Point?

D'altra parte, si dispone di un metodo add(Point). Presumibilmente questo aggiunge l'argomento della funzione all'istanza: in tal caso, dovresti renderlo un metodo di istanza in modo da avere entrambi i valori Point s.

Modifica: Penso di aver frainteso, in origine. Guardando indietro, hai le firme corrette per entrambe le implementazioni statiche e non statiche. A questo punto, direi che è una questione di stile, come sapete entrambi funzioneranno correttamente. Come vuoi che la tua point-class sia usata? Pensa se rende il codice più intuitivo per dire Point a = Point.add(b, c) o Point a = b.add(c). Personalmente, mi piace il primo, poiché mi dice che nessuno degli operandi verrà modificato.

Answer 3

È naturale che queste funzioni non siano statiche. Ma se dubiti di fare riferimento a GRASP, loro descrivono cose come questa.

Secondo l'esperto di informazioni GRASP queste funzioni non devono essere statiche.

Nonostante il fatto non ci sono informazioni dirette sul metodo statico, c'è

Information Expert ci porterà a luogo una responsabilità in classi con la maggior parte delle informazioni necessarie per compierla.

Se si rendono i metodi statici, si sposterà ulteriormente la logica dai dati effettivi e sarà necessario passare i dati al metodo.

La rimozione di statico avvicina la logica ai dati che utilizza.

Answer 4

Nel tuo caso deve essere non statico a meno che non si cambi la firma in public static Point add(Point point1, Point point2).

MODIFICA: ho votato. Va bene. Non stavo cercando di dare un suggerimento banale come mettere il metodo statico davanti. In questo caso, un metodo di istanza è migliore, ma non c'è davvero una risposta singa. Dipende solo dalle tue preferenze.

Answer 5

Tendo a controcorrente, ma in entrambi i casi mi sembra ragionevole.

• I metodi devono, ovviamente, essere parte del metodo Point, dal momento che si occupano specificamente di punti
• Per i metodi che usano due punti, non c'è niente su di loro che implicano hanno bisogno di ulteriori informazioni su uno dei punti di l'altro...Quindi non c'è alcuna spinta su quale istanza il metodo sarebbe un membro non statico di.

Per un linguaggio come Java, andrei con metodi statici, in particolare a causa del secondo punto sopra. Per un linguaggio che ha un sovraccarico dell'operatore (come Ruby), andrei con un metodo di istanza per trarne vantaggio.

Answer 6

Semantico, l'approccio statico sembra avere un po 'più senso. Ovviamente entrambi funzioneranno, ma l'approccio non statico dà la precedenza a un punto piuttosto che a un altro, e inoltre implica che il punto1 (il metodo con cui viene chiamato add) possa essere modificato come risultato della chiamata.

Come sviluppatore utilizzando le classi, se ho visto la seguente:

Point p1 = new Point(1,2); 
Point p2 = new Point(2,3); 

p1.Add(p2); 

o ..

Point p1 = new Point(1,2); 
Point p2 = new Point(2,3); 

Point.Add(p1, p2); 

mia inclinazione naturale sarebbe quello di ritenere che il metodo add() nel settore non -la versione statica modifica il punto1 per aggiungere il risultato del punto 2. Con l'approccio statico, è più chiaro (anche se non garantito!) che il metodo è puro e che i punti rappresentativi non vengono modificati.

Answer 7

Penso che dipenda da cosa stai cercando di realizzare. Se stai fornendo un metodo che aggiunge due punti insieme, allora vuoi un metodo statico. Ma se vuoi un metodo che aggiunge un punto ad una determinata istanza di Point, allora vuoi un metodo non statico.

Se si utilizzano metodi statici, è possibile considerare di inserire i metodi statici in una classe di utilità separata (PointCalculator) che contiene solo metodi statici. Questo è simile alla classe Math.

Answer 8

Preferisco i metodi non statici più orientati agli oggetti (sì, l'utilizzo di troppi metodi statici interrompe il beneficio di oggetti come il polimorfismo, l'ereditarietà ...), anche se il tuo Point è immutabile. In realtà, ciò sarebbe coerente con il modo in cui sono state progettate classi come BigDecimal o BigInteger. Oltre a questo, static methods make classes harder to test, quindi preferisco evitare di usarli, se possibile, soprattutto quando ha senso.

Answer 9

Questi metodi devono essere statici perché la classe stessa si presta a essere creata tramite il costruttore e i valori assegnati una volta a causa di xey finale. Ciò significa che puoi creare Punti, ma non manipolare i loro dati andando avanti. I metodi Add/Substract/Etc sono metodi di utilità che non dovrebbero richiedere l'utilizzo di un'istanza di Point.

Answer 10

Se si intende utilizzare Java e creare oggetti, quindi stilisticamente, penso che si dovrebbe cercare di sfruttare al massimo gli oggetti e l'incapsulamento dei dati. Per me, questo significa lasciare i dati dov'è (nella classe Point) e non passarli a un metodo separato per affrontarli. Fai lavorare i tuoi oggetti per te; non solo avere getter e setter. In effetti, pensa bene a come puoi evitare di aver bisogno di un getter.

È perfettamente comune avere metodi come add() e sottrarre() su una classe immutabile che restituisce nuove istanze della classe immutabile. Questo è un buon stile per la programmazione FP-like e perfettamente ragionevole per una classe come questa. (Vedi BigInteger o BigDecimal per buoni esempi. NON vedere Data o Calendario per esempi spaventosi di rotture sbagliate.:)

metodi Tenendo in classe consente di opzionalmente definiscono interfacce che queste classi possono implementare, utilizzare il decoratore o pattern Adapter, scrivere certi tipi di prove, ecc

Answer 11

Rendendoli statica rende anche più difficile per unità provali! L'unico sistema di simulazione che conosco in .NET che potrebbe gestire questo è TypeMock.

Se l'intenzione è quella di rendere questa classe immutabile, allora restituirai nuovi oggetti Punto in qualsiasi accessorio, chiama così renderli statici non ha molto senso qui.