Come organizzare il codice OO [duplicato]

Questo metodo è ancora parte logica dell'interfaccia di classe? Se è così, ti consigliamo di metterlo in qualche modo vicino alla classe stessa. Potrebbe essere un membro, come un metodo statico di una classe di utilità correlata (compresi i metodi di estensione se la tua lingua ha una cosa simile, ad esempio C #), o una funzione libera nello stesso pacchetto / spazio dei nomi della classe, se la tua lingua supporta quello (ad es. C ++).

Ma se non è realmente legato alla classe, forse da qualche altra parte è un posto migliore.

In generale, non darei a una classe un metodo statico che accetta un singolo parametro di istanza. Nella maggior parte delle lingue, questo metodo non è più limitato in ciò a cui può accedere (di solito può accedere ai membri privati), quindi è solo un onere sintattico per il chiamante.

Tendo ad usare i concetti di accoppiamento e coesione per decidere cosa va in ogni classe / interfaccia / modulo / ecc. Basso accoppiamento e alta coesione sono ciò che desideri.

L'accoppiamento è abbastanza facile da capire. Ma trovo che molti sviluppatori abbiano problemi con la coesione. Fondamentalmente, "coesione" è come la vecchia canzone di Sesame Street, "Una di queste cose non è come le altre ..." In una classe con alta coesione, tutto sembra appartenere insieme.

(Inoltre, per essere pedante, direi che questo è più che altro come "progettare" il codice OO piuttosto che "organizzarlo" - dove l'organizzazione sarebbe più incentrata su come ordini i metodi, i nomi dei pacchetti, ecc.)

Se utilizza campi privati, proprietà o metodi, mantienilo non statico. Passare in una variabile di istanza aggiunge solo rumore.

Tendo a rendere statici i metodi se posso (senza passare le istanze in), segnala l'opportunità di spostare il metodo a basso costo altrove, se necessario.

In caso di dubbio, lascia fuori la statica.

Statico se non è rilevante per l'istanza. Che tu voglia passare un'istanza significa che è un'istanza rilevante quindi no.

Privato se nel migliore dei casi non fa altro che confondere le persone che cercano di riutilizzare la tua classe quando sono esposte a loro. L'obiettivo principale è seppellire come funziona e dare alle persone una facile comprensione, pulsanti ben etichettati da premere.

Pensa prima a ciò che vuoi esporre a qualcun altro usando la tua classe. E fai attenzione alle API pubbliche su cose che ti piace lavorare al meglio per alcune idee su ciò che funziona bene.

L'unica ragione per utilizzare in genere un metodo esteso è se hai una varietà di classi che vuoi avere tutti lo stesso set standard di metodi. Ci sono persone che si estendono e implementano per tutti i tipi di motivi e modelli complessi di jour ma è un cattivo OOP e nella maggior parte dei casi dovrebbero probabilmente fermarsi.

Mantieni tutto semplice e pulito come deve essere. È sempre più facile andare avanti con le lezioni più complesse di quanto non sia mantenere una base di codice piena zeppa di cose che non hanno bisogno di essere lì. Meno c'è da guardare, più chiare sono le tue intenzioni e più facile è mantenere / modificare senza che tutto ti esploda in faccia.

Non sto parlando di parole OO specifiche della lingua (statico, privato, ecc.).

If you have a method that doesn't need access to any non public fields, properties or methods where should you put the method ?

Se il codice non è correlato con alcuna classe nel tuo dominio, allora può essere una funzione semplice, al di fuori dell'ambito di una classe. Un esempio muto è fattoriale o addirittura fibonacci, o semplicemente riceve un valore e calcola un risultato, non appartiene a nessuna classe in particolare. Se il codice è una specie di factory o ha qualcos'altro legato a una certa classe, allora può essere un metodo statico o di classe, o anche un'altra classe.

È importante notare che se la tua lingua consente le funzioni pure , non solo classi e metodi, puoi trarne vantaggio e rendere il tuo design più semplice (per me è uno dei principali svantaggi del linguaggio Java, ma è solo la mia opinione personale).