Denominazione dell'interfaccia in Java [chiuso]

La maggior parte delle lingue OO prefissa i nomi delle loro interfacce con la I maiuscola, perché Java non lo fa? Qual era la logica per non seguire questa convenzione?

Per dimostrare cosa intendo, se volessi avere un'interfaccia utente e un'implementazione utente avrei due scelte in Java:

1. Class = User, Interface = UserInterface
2. Class = UserImpl, Interface = User

Dove nella maggior parte delle lingue:

Class = User, Interface = IUser

Ora, potresti sostenere che potresti sempre scegliere un nome più descrittivo per l'implementazione dell'utente e il problema scompare, ma Java sta spingendo un approccio POJO alle cose e la maggior parte dei contenitori IOC utilizzano ampiamente DynamicProxies. Queste due cose insieme significano che avrai molte interfacce con una singola implementazione POJO.

Quindi, suppongo che la mia domanda si riduca a: "Vale la pena seguire la più ampia convenzione di denominazione dell'interfaccia, specialmente alla luce di dove sembra che Java Frameworks stia andando?"

Preferisco non usare un prefisso sulle interfacce:

• Il prefisso danneggia la leggibilità.

• L'uso delle interfacce nei client è il modo migliore standard per programmare, quindi i nomi delle interfacce dovrebbero essere il più brevi e piacevoli possibile. Le classi di implementazione dovrebbero essere più brutte per scoraggiarne l'uso.

• Quando si passa da una classe astratta a un'interfaccia, una convenzione di codifica con prefisso I implica la ridenominazione di tutte le occorrenze della classe --- non va bene!

C'è davvero una differenza tra:

class User implements IUser

e

class UserImpl implements User

se tutto ciò di cui stiamo parlando sono convenzioni di denominazione?

Personalmente preferisco non precede l'interfaccia con Icome io voglio essere la codifica per l'interfaccia e ritengo che sia più importante in termini di convenzione di denominazione. Se chiami l'interfaccia, IUserogni consumatore di quella classe deve sapere che è un IUser. Se chiami la classe, UserImplsolo la classe e il tuo contenitore DI conoscono la Implparte e i consumatori sanno solo che stanno lavorando con una User.

Poi di nuovo, i tempi che sono stato costretto a usare Implperché un nome migliore non si presenta sono stati pochi e lontani tra loro perché l'implementazione prende il nome in base all'implementazione perché è lì che è importante, ad es.

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

Ci possono essere diversi motivi per cui Java generalmente non usa la convenzione IUser.

1. Parte dell'approccio orientato agli oggetti è che non dovresti sapere se il client utilizza un'interfaccia o una classe di implementazione. Quindi, anche List è un'interfaccia e String è una classe reale, un metodo potrebbe essere passato a entrambi - non ha senso distinguere visivamente le interfacce.

2. In generale, preferiremo in realtà l'uso di interfacce nel codice client (preferiamo List to ArrayList, ad esempio). Quindi non ha senso far risaltare le interfacce come eccezioni.

3. La convenzione di denominazione Java preferisce nomi più lunghi con significati effettivi ai prefissi in stile ungherese. Quindi quel codice sarà il più leggibile possibile: un elenco rappresenta un elenco e un utente rappresenta un utente, non un utente.

C'è anche un'altra convenzione, utilizzata da molti progetti open source tra cui Spring.

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

Personalmente non mi piace il prefisso "I" per la semplice ragione che è una convenzione opzionale. Quindi se adotto questo IIOPConnection significa un'interfaccia per IOPConnection? Che cosa succede se la classe non ha il prefisso "I", allora so che non è un'interfaccia..la risposta qui è no, perché le convenzioni non sono sempre seguite e il loro controllo creerà più lavoro che la convenzione stessa salva.

Come diceva un altro poster, in genere è preferibile che le interfacce definiscano capacità e non tipi. Tenderei a non "implementare" qualcosa di simile a un "Utente" ed è per questo che "IUser" spesso non è realmente necessario nel modo descritto qui. Vedo spesso le classi come sostantivi e le interfacce come aggettivi:

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

A volte un aggettivo non ha senso, ma in genere utilizzerei comunque le interfacce per modellare comportamenti, azioni, capacità, proprietà, ecc., Non tipi.

Inoltre, se avessi davvero intenzione di creare un solo utente e chiamarlo utente, qual è il punto di avere anche un'interfaccia IUser? E se hai diversi tipi di utenti che devono implementare un'interfaccia comune, cosa ti consente di salvare un "io" nell'interfaccia nella scelta dei nomi delle implementazioni?

Penso che un esempio più realistico sarebbe che alcuni tipi di utenti devono essere in grado di accedere a una particolare API. Potremmo definire un'interfaccia di accesso e quindi avere una classe genitore "Utente" con le sottoclassi di SuperUser, DefaultUser, AdminUser, AdministrativeContact, ecc., Alcune delle quali implementeranno o meno l'interfaccia di Login (Loginable?) Secondo necessità.

Bob Lee ha detto una volta in una presentazione:

che senso ha un'interfaccia se hai una sola implementazione?

quindi, inizi con una implementazione, cioè senza un'interfaccia. più tardi decidi, beh, qui c'è bisogno di un'interfaccia, quindi converti la tua classe in un'interfaccia.

allora diventa ovvio: la tua classe originale era chiamata Utente. la tua interfaccia ora è chiamata Utente. forse hai UserProdImpl e UserTestImpl. se hai progettato bene la tua applicazione, ogni classe (eccetto quelle che istanziano l'Utente) rimarrà invariata e non noterà che all'improvviso gli viene passata un'interfaccia.

così diventa chiaro -> Interfaccia Implementazione utente UserImpl.

In C # lo è

public class AdminForumUser : UserBase, IUser

Direbbe Java

public class AdminForumUser extends User implements ForumUserInterface

Per questo motivo, non credo che le convenzioni siano altrettanto importanti in Java per le interfacce, poiché esiste una differenza esplicita tra ereditarietà e implementazione dell'interfaccia. Vorrei solo scegliere qualsiasi convenzione di denominazione che desideri, purché tu sia coerente e usi qualcosa per mostrare alla gente che si tratta di interfacce. Non lavoro a Java da alcuni anni, ma tutte le interfacce si troverebbero nella loro directory e quella era la convenzione. Non ho mai avuto problemi con esso.

Nella mia esperienza, la convenzione "I" si applica alle interfacce che intendono fornire un contratto a una classe, in particolare quando l'interfaccia stessa non è una nozione astratta della classe.

Ad esempio, nel tuo caso, mi aspetto solo di vedere IUserse l'unico utente che hai intenzione di avere è User. Se prevedi di avere diversi tipi di utenti - NoviceUser, ExpertUserecc. - mi aspetterei di vedere Userun'interfaccia (e, forse, una AbstractUserclasse che implementa alcune funzionalità comuni, come get/setName()).

Mi aspetto anche che le interfacce che definiscono le capacità - Comparable, Iterableecc. - vengano denominate in questo modo, e non come IComparableo IIterable.

Seguendo i buoni principi OO, il codice dovrebbe (per quanto pratico / possibile) dipendere da astrazioni piuttosto che da classi concrete. Ad esempio, è generalmente meglio scrivere un metodo come questo:

public void doSomething(Collection someStuff) {
    ...
}

di questo:

public void doSomething(Vector someStuff) {
    ...
}

Se segui questa idea, sostengo che il tuo codice sarà più leggibile se dai nomi alle interfacce come "Utente" e "BankAccount" (ad esempio), anziché "IUser", "UserInterface" o altre varianti.

Le uniche parti di codice che dovrebbero interessare le classi concrete concrete sono i luoghi in cui sono costruite le classi concrete. Tutto il resto dovrebbe essere scritto usando le interfacce.

Se lo fai, allora i nomi di "concrete" "brutte" come "UserImpl" dovrebbero essere nascosti in modo sicuro dal resto del codice, il che può continuare allegramente usando i nomi di "bella" interfaccia.

= v = Il prefisso "I" viene utilizzato anche nel framework Wicket, dove mi sono abituato rapidamente. In generale, accolgo con favore qualsiasi convenzione che accorcia ingombranti nomi di classe Java. È una seccatura, però, che tutto sia alfabetizzato sotto "I" nelle directory e nel Javadoc.

La pratica del codice Wicket è simile a Swing, in quanto molte istanze di controllo / widget sono costruite come classi interne anonime con dichiarazioni di metodi inline. Stranamente, differisce di 180 ° da Swing in quanto Swing utilizza un prefisso ("J") per le classi di implementazione.

Il suffisso "Impl" è un'abbreviazione birichina e non si internazionalizza bene. Se solo fossimo andati almeno con "Imp", sarebbe stato più carino (e più breve). "Impl" è usato per IOC, specialmente Spring, quindi per ora siamo un po 'bloccati. Tuttavia, diventa un po 'schizo seguendo 3 diverse convenzioni in tre parti diverse di una base di codice.

È una convenzione di denominazione più ampia in qualche senso reale? Sono più sul lato C ++ e non su Java e i discendenti. Quante comunità linguistiche usano la convenzione I?

Se hai una convenzione di denominazione standard di negozio indipendente dalla lingua qui, usala. In caso contrario, seguire la convenzione sulla denominazione delle lingue.