OOP (possibilmente specifico di Java): Set completo di categorie di metodi [chiuso]

Question

OOP (possibilmente specifico di Java): Set completo di categorie di metodi [chiuso]

#1 da (6 voti)
#2 da (5 voti)

1

Sto lavorando a una convenzione di codifica da seguire per i miei progetti Java. Trovo più facile trovare la mia strada attraverso una classe quando raggruppo i suoi metodi per categoria. Ad esempio, piuttosto che avere ciascuna coppia getter / setter per una variabile una dopo l'altra in una lunga lista, trovo più semplice raggruppare tutti i getter in una sezione e tutti i setter in un'altra. Ciò significa che il mio codice è organizzato in questo modo:

public class MyClass {
    //=========================== Instance Fields ============================//

    //========================== Instance Interface ==========================//
    //----------------------------- Constructors -----------------------------//

    //------------------------------- Getters --------------------------------//

    //------------------------------- Setters --------------------------------//

    /* More categories? */

    //============================ Static Fields =============================//

    //=========================== Static Interface ===========================//

}

Il problema con questo approccio è uno con le mie conoscenze: non so come classificare ogni metodo. Ovviamente, ho familiarità con costruttori, distruttori, getter e setter. Ho anche sentito parlare di osservatori / query, trasformatori / mutatori e iteratori, anche se non ho ancora trovato nomi standardizzati per questi. Ma poi ci sono metodi che mi lasciano grattarmi la testa, come metodi per classi immutabili che restituiscono una nuova versione di quell'oggetto che rappresenta una modifica a quello stato immutabile.

Esiste un gruppo standardizzato di categorie in OOP che descrive cosa possono fare i metodi? Se sì, qualcuno potrebbe fornire un elenco di questi nomi e spiegazioni su cosa fa quella categoria? Se queste categorie sono specifiche della lingua, potresti fornire anche un set specifico per Java?

object-oriented java theory

posta sadakatsu 23.03.2015 - 14:21

fonte

2 risposte

Leggi altre domande sui tag object-oriented java theory

Aggiunta di uno sviluppatore a breve termine a una rielaborazione di un vecchio progetto [chiuso] Algoritmo di ricerca utilizzato nell'istruzione switch

score 6 · Answer 1

Non sono d'accordo sul fatto che dovresti ordinare i tuoi metodi per categoria, o anche per visibilità. Può sembrare, all'inizio, che questa sia una buona cosa da fare, ma quello che stai facendo è imporre un ordine per ordine, ma non per una ragione particolare. Considera che la tua rubrica sia stata ordinata per numero di telefono. Certamente, sarebbe organizzato , ma il tuo schema organizzativo non sarebbe molto utile. Cosa stai cercando di minimizzare con la tua rubrica? Risposta: la quantità di tempo ti porta a cercare un indirizzo. Tienilo presente alla fine della mia risposta.

Che cosa dovrebbe essere lo schema organizzativo?

Da Pulisci codice :

Have you ever chased your tail through a class, hopping from one function to the next, scrolling up and down the source file, trying to divide how the functions relate and operate, only to get lost in a rat's nest of confusion? Have you ever hunted up the chain of inheritance for the definition of a variable or function? This is frustrating because you are trying to understand what the system does, but you are spending your time and mental energy on trying to locate and remember where the pieces are.

Concepts that are closely related should be kept vertically close to each other. Clearly this rule doesn't work for concepts that belong in separate files. But then closely related concepts should not be separated into different files unless you have a very good reason. Indeed, this is one of the reasons that protected variables should be avoided.

Dovresti leggere l'intero capitolo, continua a lungo su questo. Potrei mettere tutto qui ma non voglio violare la copia di Robert Martin a destra too . Ma, in sostanza, la prossima parte dice questo:

Le dichiarazioni delle variabili locali dovrebbero essere il più vicino possibile al loro utilizzo.
Mantieni le variabili di istanza (campi) in alto, come già fai.
Metti le funzioni dipendenti dopo le funzioni che li chiamano.

# 3 è il concetto di organizzazione chiave. Vuoi leggere il tuo codice come se leggessi un articolo di giornale. Ogni metodo pubblico dovrebbe avere le sue dipendenze private immediatamente successive, con buoni nomi di variabili. Ricorda quella rubrica. L'obiettivo è di ridurre al minimo la quantità di tempo che passi scorrere su e giù per le tue classi per trovare un comportamento pertinente, in modo che la tua mente possa concentrarsi sul " cosa fa il sistema" mentre continui a programmare.

score 5 · Answer 2

Is there a standardized set of categories in OOP that cover what methods can do?

No, poiché per definizione i metodi possono fare qualsiasi cosa. Ma stai risolvendo un sintomo.

I find it easier to find my way through a class when I group its methods by category.

Questo è un segno che le tue classi sono troppo grandi e / o fanno troppo. Potrebbe anche essere un segno che non stai utilizzando il tuo IDE nel modo più efficiente possibile.

Java rende tutto questo difficile, specialmente se stai facendo javadoc-tutto, ma non dovresti aver bisogno di questo livello di organizzazione per navigare nella tua classe. Gli IDE forniscono go to source / declaration. Forniscono riepiloghi di classe per aiutare la navigazione. E se la tua classe sta affrontando correttamente una sola responsabilità, dovrebbe comunque occupare solo alcuni schermi al massimo.

Avere campi, costruttori, proprietà e metodi in gruppi aiuta la leggibilità del codice. I metodi di raggruppamento per visibilità a volte possono aiutare, a volte no. Fare di più è probabilmente eccessivo. Richiedere di più è un segnale che qualcosa è andato storto.