Non posso semplicemente usare tutti i metodi statici?

Qual è la differenza tra i due metodi UpdateSubject di seguito? Sentivo che usare metodi statici è meglio se vuoi solo operare sulle entità. In quali situazioni dovrei scegliere metodi non statici?

public class Subject
{
    public int Id {get; set;}
    public string Name { get; set; }

    public static bool UpdateSubject(Subject subject)
    {
        //Do something and return result
        return true;
    }
    public bool UpdateSubject()
    {
        //Do something on 'this' and return result
        return true;
    }
}

So che riceverò molti calci dalla comunità per questa domanda davvero fastidiosa, ma non potevo smettere di farmi questa domanda.

Questo diventa poco pratico quando si ha a che fare con l'eredità?

Aggiornamento:
sta succedendo nel nostro posto di lavoro ora. Stiamo lavorando su un'applicazione web asp.net di 6 mesi con 5 sviluppatori. Il nostro architetto ha deciso di utilizzare tutti i metodi statici per tutte le API. Il suo ragionamento è che i metodi statici sono leggeri e avvantaggia le applicazioni web mantenendo basso il carico del server.

Vado con i problemi più ovvi di metodi statici con parametri espliciti "questo":

1. Si perde l'invio virtuale e successivamente il polimorfismo. Non è mai possibile sovrascrivere quel metodo in una classe derivata. Ovviamente puoi dichiarare un metodo new( static) in una classe derivata, ma qualsiasi codice a cui accede deve essere a conoscenza dell'intera gerarchia di classi ed eseguire controlli e casting espliciti, che è esattamente ciò che OO dovrebbe evitare .

2. Ordinato di un'estensione n. 1, non è possibile sostituire le istanze della classe con un'interfaccia , poiché le interfacce (nella maggior parte delle lingue) non possono dichiarare staticmetodi.

3. La verbosità inutile. Quale è più leggibile: Subject.Update(subject)o semplicemente subject.Update()?

4. Verifica argomento. Di nuovo dipende dalla lingua, ma molti compileranno un controllo implicito per assicurarsi che l' thisargomento non sia nullal fine di impedire a un bug di riferimento null di creare condizioni di runtime non sicure (tipo di sovraccarico del buffer). Non usando i metodi di istanza, dovresti aggiungere questo controllo esplicitamente all'inizio di ogni metodo.

5. È confusionario. Quando un programmatore normale e ragionevole vede un staticmetodo, naturalmente supporrà che non richieda un'istanza valida (a meno che non richieda più istanze, come un metodo di confronto o di uguaglianza, o che si prevede che sia in grado di operare su nullriferimenti) . Vedere metodi statici usati in questo modo ci farà fare un doppio o forse triplo, e dopo la quarta o la quinta volta saremo stressati e arrabbiati e dio ti aiuterà se conosciamo il tuo indirizzo di casa.

6. È una forma di duplicazione. Ciò che realmente accade quando invochi un metodo di istanza è che il compilatore o il runtime cerca il metodo nella tabella dei metodi del tipo e lo invoca usando thiscome argomento. Fondamentalmente stai implementando nuovamente ciò che il compilatore fa già. Stai violando DRY , ripetendo ripetutamente lo stesso parametro in diversi modi quando non è necessario.

È difficile concepire una buona ragione per sostituire i metodi di istanza con metodi statici. Per favore, no.

Hai praticamente descritto esattamente come esegui OOP in C, in cui sono disponibili solo metodi statici e "this" è un puntatore a struttura. E sì, puoi eseguire il polimorfismo del tempo di esecuzione in C specificando un puntatore a funzione durante la costruzione da memorizzare come elemento della struttura. I metodi di istanza disponibili in altre lingue sono solo zucchero sintattico che essenzialmente fa esattamente la stessa cosa sotto il cofano. Alcuni linguaggi, come Python, sono a metà strada, dove il parametro "self" è esplicitamente elencato, ma una sintassi speciale per chiamarlo gestisce l'ereditarietà e il polimorfismo per te.

Il problema con il metodo statico arriva nel momento in cui è necessaria una sottoclasse.

I metodi statici non possono essere sovrascritti nelle sottoclassi, quindi le nuove classi non possono fornire nuove implementazioni dei metodi, rendendoli meno utili.

Se si dichiara un metodo static, non è necessario creare un'istanza di un oggetto dalla classe (utilizzando la newparola chiave) per eseguire il metodo. Tuttavia, non è possibile fare riferimento a nessuna variabile membro a meno che non siano anche statiche, nel qual caso tali variabili membro appartengono alla classe, non a un oggetto istanziato specifico della classe.

Detto in altri termini, la staticparola chiave fa sì che una dichiarazione faccia parte della definizione della classe, quindi diventa un singolo punto di riferimento in tutte le istanze della classe (oggetti istanziati dalla classe).

Ne consegue, quindi, che se si desidera più copie in esecuzione della propria classe e non si desidera che lo stato (variabili membro) sia condiviso tra tutte le copie in esecuzione (ovvero ogni oggetto detenga il proprio stato univoco), si non è possibile dichiarare quelle variabili membro statiche.

In generale, è necessario utilizzare staticclassi e metodi solo quando si creano metodi di utilità che accettano uno o più parametri e restituiscono un oggetto di qualche tipo, senza effetti collaterali (ovvero modifiche alle variabili di stato nella classe)

Il motivo per cui le persone sostengono che i "metodi statici mostrano una cattiva progettazione" non sono necessariamente dovuti ai metodi, sono in realtà dati statici, impliciti o espliciti. Per implicito intendo QUALSIASI stato nel programma che non è contenuto nei valori o nei parametri di ritorno. La modifica dello stato in una funzione statica è un ritorno alla programmazione procedurale. Tuttavia, se la funzione non modifica lo stato o delega la modifica dello stato alle funzioni degli oggetti componenti, in realtà è più un paradigma funzionale che procedurale.

Se non cambi stato, i metodi e le classi statici possono avere molti vantaggi. Rende molto più semplice garantire che un metodo sia puro e quindi privo di effetti collaterali e che tutti gli errori siano completamente riproducibili. Assicura inoltre che metodi diversi in più applicazioni che utilizzano una libreria condivisa possano essere certi che otterranno gli stessi risultati con lo stesso input, rendendo molto più facile sia il rilevamento degli errori che il test delle unità.

In definitiva, non vi è alcuna differenza nella pratica tra oggetti sovradimensionati comunemente visti come "StateManager" e dati statici o globali. Il vantaggio dei metodi statici usati correttamente è che possono indicare l'intenzione dell'autore di non modificare lo stato in revisori successivi.

A seconda della lingua e di ciò che stai cercando di fare, la risposta potrebbe essere che non c'è molta differenza, ma la staticversione ha un po 'più di confusione.

Come la tua sintassi di esempio suggerisce Java o C #, penso che Thorbjørn Ravn Andersen abbia ragione nel sottolineare il problema prevalente (con associazione tardiva). Con un metodo statico, non esiste un parametro "speciale" su cui basare l'associazione tardiva, quindi non è possibile eseguire l'associazione tardiva.

In effetti, un metodo statico è solo una funzione in un modulo, quel modulo con lo stesso nome della classe - non è affatto un metodo OOP.

Fondamentalmente stai sconfiggendo l'intero punto degli oggetti quando lo fai. C'è una buona ragione per cui siamo passati dal codice procedurale al codice orientato agli oggetti.

Avrei mai dichiarare un metodo statico che ha preso il tipo di classe come parametro. Questo rende il codice più complesso senza alcun guadagno.

Ci sono molte grandi risposte qui, e sono molto più perspicaci e ben informati di qualsiasi cosa io possa mai trovare una risposta, ma sento che c'è qualcosa che non viene affrontato:

"Il nostro architetto ha deciso di utilizzare tutti i metodi statici per tutte le API. Il suo ragionamento è che i metodi statici sono leggeri e avvantaggia le applicazioni Web mantenendo basso il carico del server ."

(l'enfasi audace è mia)

Il mio 2c su questa parte della domanda è questo:

Teoricamente, ciò che viene detto è vero: chiamare un metodo statico ha solo il sovraccarico di invocare effettivamente quel metodo. La chiamata a un metodo non statico (istanza) ha l'ulteriore sovraccarico di prima istanziare l'oggetto e, a un certo punto, distruggere l'istanza (manualmente o tramite una qualche forma di garbage collection automatica, a seconda della piattaforma utilizzata).

Gioca un po 'di avvocato del diavolo su questo: possiamo andare ancora oltre e dire cose come:

• questo può diventare davvero brutto se viene creata un'istanza per ogni invocazione del metodo (istanza) (invece di lasciarla statica e chiamarla così)

• a seconda della complessità del costruttore, del tipo di gerarchia, di altri membri dell'istanza e di altri fattori sconosciuti, l'overhead aggiuntivo della chiamata del metodo non statico può variare e diventare molto grande

In verità, IMHO, i punti precedenti (e l'approccio generale di "usiamo la statica perché sono più veloci") sono argomenti / valutazioni di paglia:

• se il codice è valido e, più specifico di questo argomento, se le istanze vengono create solo quando necessario (e distrutte in modo ottimale), non si ottiene alcun sovraccarico aggiuntivo dall'uso dei metodi di assicurazione quando appropriato (perché se si creare solo gli oggetti necessari, quelli sarebbero stati creati anche se quel metodo fosse stato dichiarato statico in alcuni casi = stesso overhead di instanciazione)

• abusando della dichiarazione dei metodi statici in questo modo, è possibile nascondere alcuni problemi con il codice in merito alla modalità di creazione delle istanze (poiché il metodo è statico, un codice di instanciazione errato può passare inosservato fino a dopo, e non è mai un bene).

Questa è una domanda molto interessante che tende ad avere risposte molto diverse a seconda della comunità che stai chiedendo. Altre risposte sembrano essere C # o java bias: un linguaggio di programmazione che è (principalmente) puro oggetto orientato e ha una sorta di visione idiomatica di quale sia l'orientamento dell'oggetto.

In altre comunità, come C ++, l'orientamento agli oggetti viene interpretato con maggiore liberalità. Alcuni ben sanno che gli esperti hanno studiato l'argomento e, in realtà, concludono che le funzioni libere migliorano l'incapsulamento (l'enfasi è mia):

Abbiamo ora visto che un modo ragionevole per valutare la quantità di incapsulamento in una classe è contare il numero di funzioni che potrebbero essere interrotte se l'implementazione della classe cambia. Stando così le cose, diventa chiaro che una classe con n funzioni membro è più incapsulata di una classe con n + 1 funzioni membro. E questa osservazione è ciò che giustifica il mio argomento per preferire le funzioni non amiche non membro alle funzioni membro

Scott Meyers

Per chi non ha familiarità con la terminologia C ++:

• funzione membro = metodo
• funzione non membro = metodo statico
• non amico = usa solo API pubbliche
• non membro funzione non amico = metodo statico che utilizza solo API pubbliche

Ora, per rispondere alla tua domanda:

Non posso semplicemente usare tutti i metodi statici?

No, non dovresti sempre usare metodi statici.

Ma dovresti usarli ogni volta che devi solo usare l' API pubblica di una classe.

in Java ...

I metodi statici non vengono sovrascritti ma sono nascosti e quindi sarebbe una grande differenza (problema?) In caso di estensione della classe.

D'altra parte ho notato che i programmatori Java hanno la tendenza a pensare che TUTTO DEVE essere oggetto, senza davvero capire il perché, e non sono d'accordo.

Statico dovrebbe essere usato per il codice specifico della classe. L'elettricità statica non funziona bene con l'ereditarietà.

alcuni buoni esempi di utilizzo di metodi statici sono funzioni indipendenti senza effetti collaterali.

vedi anche la parola chiave sincronizzata ...