Pure funzioni con una connessione a un sistema

Question

Pure funzioni con una connessione a un sistema

#1 da (2 voti)

1

Qual è un buon posto dove mettere le pure funzioni che hanno connessioni a un sistema?

public class Core {
    System system;
}

public class System {
    SubSystem subSystem;
    // subSystem.Multiply(a, b);
}

public class SubSystem {
    public float Multiply(float a, float b) { return a * b; }
}

In questo caso, SubSystem ha una strong connessione con System . Le funzioni all'interno di SubSystem sono pure / senza stato.

Il problema: se non c'è stato, perché preoccuparsi dell'istanza quando una classe statica potrebbe fare lo stesso lavoro?

In sostanza è Core.system.subSystem.Multiply(a, b); su SubSystem.Multiply(a, b);

E, certo, possiamo andare con le classi statiche. Ma cosa succede quando ci sono più sistemi con più sottosistemi statici sparsi nel progetto? La connessione viene persa e diventa rapidamente un disastro.

Per come la vedo io, ci sono le seguenti opzioni:

Core.system.subSystem.Multiply(a, b); // instances
SubSystem.Multiply(a, b);             // static
SystemUtils.SubSystem.Multiply(a, b); // with namespace

Ma quale è il migliore? E c'è un modo migliore?

object-oriented functions

posta Iggy 22.10.2018 - 12:25

fonte

1 risposta

Leggi altre domande sui tag object-oriented functions

Come gestire "Blocco Ottimistico" in una raccolta con intestazioni ETag? REST Percorsi in base ai ruoli

score 2 · Answer 1

The problem: If there is no state, why bother with the instance when a static class could do the same job?

Gli oggetti possono essere sviluppati usando interfacce e quindi derisi. Le classi statiche non possono implementare le interfacce.
Su una nota correlata, gli oggetti possono essere passati da un metodo all'altro, ma le classi statiche non possono.

If there is no state, why bother with the instance when a static class could do the same job?

"nessuno stato" e "statico" non sono termini equivalenti.

È vero che le classi e i metodi statici non comportano uno stato (sebbene si possa sostenere che le proprietà statiche sono ancora una forma di stato, anche se globale).

Non è vero che qualsiasi cosa che non usa uno stato deve quindi essere statica. Prendendo il tuo esempio di un metodo di moltiplicazione, è perfettamente possibile creare diverse classi che possono svolgere questa funzione:

NormalMultiplier utilizza l'approccio a * b semplice.
WolframAlphaMultiplier chiede a Wolfram Alpha il risultato.
WindowsMultiplier si affida a Windows Calculator per trovare il risultato.

Sembra un po 'sciocco per la moltiplicazione, ma ha più senso per es. ottenendo un valore preciso di pi. Il tuo computer locale non sarà in grado di calcolare più cifre decimali quante possono utilizzare Wolfram Alpha (in un lasso di tempo ragionevole); ma poi di nuovo, se hai bisogno solo di una manciata di cifre decimali, non vuoi dover fare affidamento sulla connessione di rete a Wolfram Alpha.

In tutti e tre i casi, il metodo Multiply(a,b) non richiede in particolare uno stato; ma come andresti a implementarli come classi statiche? Potresti farlo, ma in questo modo rendi impossibile per queste classi avere un antenato comune (ad esempio Multiplier ) o implementare la stessa interfaccia (ad esempio IMultiplier ) .

Questo è dove le classi statiche si disgregano. Sono utili solo nei casi in cui esiste esattamente un'implementazione , mai più, mai meno. E questo non è sempre il caso.
Indirettamente, anche questo rende impossibile simulare le classi statiche, il che può essere un problema durante il test.