Quali sono gli svantaggi di denominare le cose in ordine alfabetico?

Se iOS ha seguito la convenzione di denominazione che proponi, le classi menzionate saranno denominate:

• UIObjectResponderViewcontroller

• UIObjectResponderViewcontrollerTable

Ci sarebbero anche classi con nomi come:

• UIObjectResponderView

• UIObjectResponderViewControl

• UIObjectResponderViewControlButton

• UIObjectResponderViewScroll

• UIObjectResponderViewScrollTable

Gli svantaggi di questa convenzione di denominazione diventano sempre più evidenti con il crescere di questa dimensione del framework:

1. Nomi di classi molto lunghe.

2. La maggior parte delle classi inizia con lo stesso prefisso lungo, come "UIObjectResponderView ..."

3. L'ordine ordinato dei file di origine corrisponde alla gerarchia di ereditarietà, che non è quasi tanto utile quanto avere gruppi in base alla funzionalità. Cioè, è più utile avere XYDetailView e XYDetailViewController finire vicini l'uno all'altro piuttosto che avere XYObjectResponderViewDetail raggruppato con tutte le viste e XYObjectResponderViewcontrollerDetail raggruppato con tutti i controller di visualizzazione.

4. Le classi di denominazione in base alla catena di ereditarietà violano il principio "Non ripetere te stesso" (DRY).

5. Rende il completamento dei nomi quasi inutile: devi digitare la maggior parte di un nome molto lungo prima che l'elenco di possibili completamenti sia utile. In Cocoa Touch, quasi tutte le classi derivano da NSObject e moltissime classi derivano da NSResponder e il numero di visualizzazioni è piuttosto ampio. Quindi, ogni volta che vuoi digitare il nome di una vista, devi digitare almeno "UIObjectResponderView" solo per ottenere l'elenco (lungo) delle classi di visualizzazione.

6. Non funziona con i prefissi. In Objective-C, i prefissi dei nomi come "NS", "UI", "CF" e "MK" vengono utilizzati per evitare conflitti di nome. Le classi UIKit iniziano tutte con "UI", ma tutte quelle classi sono in realtà derivate da NSObject.

7. Non funziona bene con nomi di classi composti da più parole. Un controller di visualizzazione è un controller che gestisce una vista; è non una vista. Usando la tua convenzione, l'utilizzo di entrambe le parole per rendere "UIObjectResponderViewController" sembra essere una sottoclasse di "UIObjectResponderView."

I vantaggi di schemi di denominazione più convenzionali sono praticamente l'inverso degli svantaggi sopra elencati:

1. Consente nomi molto più brevi, come "UIButton" anziché "UIObjectResponderViewControlButton."

2. Evita i prefissi comuni noiosamente lunghi. I nomi delle classi sono effettivamente leggibili: "UITextField", "UISlider", "NSManagedObjectContext" e così via.

3. I file di origine vengono ordinati in gruppi più utili.

4. Non viola DRY.

5. Puoi digitare solo alcuni caratteri di un nome e ottenere un utile elenco di completamento.

6. & 7. Funziona bene con diversi prefissi e con nomi di più parole.

I miei 2 centesimi se ho capito bene la tua convention (correggimi se ho sbagliato per favore).

• Credo che sarà difficile dare seguito a questa convenzione per progetti più grandi. In un mondo ideale avresti lezioni che svolgono piccoli compiti e seguono buoni segreti segreti che portano alla coppia e alla coesione. Sul mondo reale, ciò che ho visto sono classi che tendono a fare molte cose. Forse il nome richiede due o più parole per descrivere la classe. In questo caso, supponendo su CarHondaAccord, dite che la classe Honda era un nome di classe più grande composto da più di una parola (ad esempio la vostra, TableView). Come andresti a differenziare la tua classe genitore da quella che è una parola composta? (Tabella è una classe genitore di View?). Forse potresti argomentare dal contesto, ma direi che a volte mi confonderei. Ciò aumenterebbe il mio sforzo solo per capire il nome della classe.

• Credo che certe convenzioni siano buone per migliorare la manutenibilità del codice a lungo termine, ma potresti voler considerare quanto impegno metti durante la programmazione per seguire queste convenzioni. Penso che dover gestire un mini algoritmo di ordine alfabetico nella mia mente ogni volta che chiamerei una sottoclasse potrebbe essere un peso.

• Aumenta la ridondanza. Prendi in considerazione la dichiarazione di una classe nel codice, non solo dichiari che la tua classe è un tipo di altra classe come richiesto dalla lingua, ma sovraccarichi anche le stesse informazioni sul nome della classe. Credo che un codice che potrebbe essere riusabile in questo caso e che abbia una struttura di ereditarietà profonda (forse il codice della linea di prodotti software) soffrirebbe molto usando questa convenzione sui nomi. Non vorrei nemmeno leggere il nome delle classi più profonde o scriverlo. (Sebbene tu possa discutere su come copiare e incollare o usare un ottimo completamento automatico IDE per fare il trucco).

• Credo che la comunicazione su certe classi si riduca a puntare anche le classi, poiché probabilmente si fatica a memorizzare completamente ogni nome di classe, poiché sapere che significa conoscere un percorso dalla classe genitore radice a il bambino più profondo. Che dire dell'ereditarietà multipla? Ahia! La dimensione della classe che segue questa convenzione richiederebbe lo scorrimento per muoversi molto presto. In effetti, un principio di HCI è quello di cercare di evitare di dare agli utenti di conservare le cose nei loro ricordi a breve termine (quelli che si memorizzano qualcosa e se qualcosa ti distrae, "puf !!" sono andati). Ciò porterebbe potenzialmente a scivoloni, il che potrebbe aumentare gli errori sul codice se i nomi delle classi sono simili (probabilmente perché la maggior parte di essi sono simili. Avere loro simili aumenta anche le possibilità di slittamento). Questa discussione si verifica su libro di Normans .

• Sembra meno naturale. Apple Le linee guida del codice lo affermano a un certo punto per i metodi con cui credo che il nome.

• Non mi sento OO per me. Voglio chiamare il mio codice oggetti come li chiamo nel mondo reale. Non ho motivo per la loro gerarchia dei nomi dei genitori. Mi piacerebbe piuttosto che i nomi avessero un significato significativo per me, cioè rendere la mia vita più facile da capire, piuttosto che rendere l'elenco delle directory dei file del computer più semplice per mostrarmi loro ordinati.

Penso che questo sia dovuto al fatto che in inglese gli aggettivi precedono i nomi e che tu dici Ho comprato una Honda invece di Ho comprato una macchina Honda .

Se hai lunghi elenchi di classi, puoi spostare alcune classi in un nuovo pacchetto.