Наименуване на интерфейс в Java [затворено]

Предпочитам да не използвам префикс на интерфейси:

• Префиксът вреди на четливостта.

• Използването на интерфейси в клиенти е стандартният най-добър начин за програмиране, така че имената на интерфейсите трябва да са възможно най-кратки и приятни. Внедряването на класове трябва да е по-грозно, за да обезсърчи използването им.

• Когато се променя от абстрактен клас към интерфейс, конвенцията за кодиране с префикс I предполага преименуване на всички срещания на класа --- не е добре!

Има ли наистина разлика между:

class User implements IUser

и

class UserImpl implements User

ако всичко, за което говорим, е конвенцията за именуване?

Лично аз предпочитам I да НЕ предхожда интерфейса, тъй като искам да кодирам интерфейса и смятам това за по-важно от гледна точка на конвенцията за именуване. Ако извикате интерфейса IUser, тогава всеки потребител от този клас трябва да знае, че това е IUser. Ако извикате класа UserImpl, тогава само класът и вашият DI контейнер знаят за частта Impl, а потребителите просто знаят, че работят с User.

От друга страна, случаите, когато съм бил принуден да използвам Impl, защото по-добро име не се представя, са били рядкост, тъй като изпълнението се наименува в съответствие с изпълнението, защото това е важното, напр.

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

Може да има няколко причини, поради които Java обикновено не използва IUser конвенцията.

1. Част от обектно-ориентирания подход е, че не трябва да знаете дали клиентът използва интерфейс или клас за изпълнение. Така че, дори List да е интерфейс и String да е действителен клас, методът може да бъде предаден и на двата - няма смисъл да се разграничават визуално интерфейсите.

2. Като цяло, ние всъщност ще предпочетем използването на интерфейси в клиентския код (предпочитаме List пред ArrayList, например). Така че няма смисъл интерфейсите да се изтъкват като изключения.

3. Конвенцията за именуване на Java предпочита по-дълги имена с действителни значения пред префикси в унгарски стил. Така че този код ще бъде възможно най-четлив: списъкът представлява списък, а потребителят представлява потребител - не IUser.

Има и друга конвенция, използвана от много проекти с отворен код, включително Spring.

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

Аз лично не харесвам префикса "I" по простата причина, че това е незадължителна конвенция. Така че, ако приема това означава ли IIOPConnection интерфейс за IOPConnection? Какво ще стане, ако класът няма префикса "I", тогава знам ли, че това не е интерфейс...отговорът тук е не, защото конвенциите не винаги се следват и контролът върху тях ще създаде повече работа, която самата конвенция спестява.

Както каза друг плакат, обикновено е за предпочитане интерфейсите да дефинират възможности, а не типове. Бих склонил да не "имплементирам" нещо като "Потребител" и това е причината "IUser" често да не е наистина необходим по начина, описан тук. Често виждам класовете като съществителни, а интерфейсите като прилагателни:

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

Понякога прилагателното няма смисъл, но все пак обикновено използвам интерфейси за моделиране на поведение, действия, възможности, свойства и т.н., не типове.

Освен това, ако наистина смятате да създадете само един потребител и да го наречете потребител, тогава какъв е смисълът да имате и интерфейс IUser? И ако ще имате няколко различни типа потребители, които трябва да внедрят общ интерфейс, какво ви спестява добавянето на „I“ към интерфейса при избора на имена на реализациите?

Мисля, че по-реалистичен пример би бил, че някои типове потребители трябва да могат да влизат в определен API. Можем да дефинираме интерфейс за влизане и след това да имаме родителски клас „Потребител“ със сукласове SuperUser, DefaultUser, AdminUser, AdministrativeContact и т.н., някои от които ще имплементират или не интерфейса за влизане (с възможност за влизане?), ако е необходимо.

Боб Лий каза веднъж в презентация:

какъв е смисълът от интерфейс, ако имате само една реализация.

така че започвате с една реализация, т.е. без интерфейс. по-късно решавате, добре, тук има нужда от интерфейс, така че преобразувате вашия клас в интерфейс.

тогава става очевидно: вашият оригинален клас се нарича User. вашият интерфейс вече се нарича потребител. може би имате UserProdImpl и UserTestImpl. ако сте проектирали приложението си добре, всеки клас (с изключение на тези, които създават потребител) ще бъде непроменен и няма да забележи, че внезапно е преминал интерфейс.

така че става ясно -> Интерфейс Потребителска реализация UserImpl.

In C# it is

public class AdminForumUser : UserBase, IUser

би казал Ява

public class AdminForumUser extends User implements ForumUserInterface

Поради това не мисля, че конвенциите са толкова важни в java за интерфейси, тъй като има изрична разлика между наследяването и реализацията на интерфейса. Бих казал, че просто изберете всяка конвенция за именуване, която искате, стига да сте последователни и да използвате нещо, което да покаже на хората, че това са интерфейси. Не съм правил java от няколко години, но всички интерфейси просто щяха да бъдат в собствената си директория и това беше конвенцията. Никога наистина не съм имал проблеми с него.

Според моя опит конвенцията „I“ се прилага за интерфейси, които са предназначени да предоставят договор на клас, особено когато самият интерфейс не е абстрактно понятие за класа.

Например във вашия случай бих очаквал да видя IUser само ако единственият потребител, който възнамерявате да имате, е User. Ако планирате да имате различни типове потребители - NoviceUser, ExpertUser и т.н. - бих очаквал да видя User интерфейс (и, може би, AbstractUser клас, който изпълнява някои общи функции, като get/setName()).

Също така бих очаквал интерфейси, които дефинират възможности - Comparable, Iterable и т.н. - да бъдат именувани така, а не като IComparable или IIterable.

Следвайки добрите OO принципи, вашият код трябва (доколкото е практично/възможно) да зависи от абстракции, а не от конкретни класове. Например, обикновено е по-добре да напишете метод като този:

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

от това:

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

Ако следвате тази идея, твърдя, че кодът ви ще бъде по-четлив, ако дадете имена на интерфейси като „Потребител“ и „Банкова сметка“ (например), вместо „IUser“, „UserInterface“ или други варианти.

Единствените битове код, които трябва да се интересуват от действителните конкретни класове, са местата, където са конструирани конкретните класове. Всичко останало трябва да бъде написано с помощта на интерфейсите.

Ако направите това, тогава "грозните" конкретни имена на класове като "UserImpl" трябва да бъдат безопасно скрити от останалата част от кода, който може весело да продължи да използва "хубавите" имена на интерфейси.

=v= Префиксът "I" също се използва в рамката на Wicket, където свикнах бързо. Като цяло приветствам всяка конвенция, която съкращава тромавите имена на класове в Java. Трудно е обаче, че всичко е подредено по азбучен ред под "I" в директориите и в Javadoc.

Практиката за кодиране на Wicket е подобна на Swing, тъй като много екземпляри на контроли/приспособления са конструирани като анонимни вътрешни класове с вградени декларации на методи. Досадно е, че се различава на 180° от Swing по това, че Swing използва префикс ("J") за внедряващите класове.

Наставката „Impl“ е небрежно съкращение и не се интернационализира добре. Ако поне бяхме избрали „Imp“, щеше да е по-сладко (и по-кратко). „Impl“ се използва за IOC, особено Spring, така че засега сме останали с него. Все пак става малко шизо след 3 различни конвенции в три различни части на една кодова база.

Това по-широка конвенция за именуване ли е в някакъв истински смисъл? Аз съм по-скоро на страната на C++ и не съм наясно с Java и потомците. Колко езикови общности използват I конвенцията?

Ако имате тук независима от езика конвенция за именуване на магазина, използвайте я. Ако не, продължете с конвенцията за именуване на езика.