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

Більшість мов OO мають префікс своїх імен інтерфейсу з великої літери I, чому Java не робить цього? Що було обґрунтуванням недотримання цієї конвенції?

Щоб продемонструвати, що я маю на увазі, якби я хотів мати користувальницький інтерфейс та користувацьку реалізацію, я мав би два варіанти на Java:

1. Клас = Користувач, Інтерфейс = Інтерфейс користувача
2. Клас = UserImpl, інтерфейс = користувач

Де на більшості мов:

Клас = Користувач, Інтерфейс = IUser

Тепер ви можете стверджувати, що ви завжди можете вибрати найбільш описову назву для впровадження користувача, і проблема усувається, але Java підштовхує POJO-підхід до речей і більшість контейнерів IOC широко використовують DynamicProxies. Ці дві речі разом означають, що у вас буде багато інтерфейсів з однією реалізацією POJO.

Отже, я думаю, моє запитання зводиться до: "Чи варто дотримуватися більш широкої конвенції про іменування інтерфейсів, особливо з огляду на те, куди, начебто, рухаються рамки Java Frameworks?"

Я вважаю за краще не використовувати префікс на інтерфейсах:

• Префікс шкодить читабельності.

• Використання інтерфейсів у клієнтів - це стандартний найкращий спосіб програмування, тому імена інтерфейсів повинні бути максимально короткими та приємними. Реалізація занять повинна бути більш неприємною, щоб відмовити від їх використання.

• При переході від абстрактного класу до інтерфейсу конвенція кодування з префіксом I передбачає перейменування всіх випадків класу --- не добре!

Чи дійсно є різниця між:

class User implements IUser

і

class UserImpl implements User

якщо все, про що ми говоримо, це називати конвенції?

Особисто я вважаю за краще НЕ передувати інтерфейсу, Iоскільки я хочу кодувати інтерфейс, і вважаю це більш важливим з точки зору конвенції про іменування. Якщо ви зателефонуєте до інтерфейсу, IUserто кожен споживач цього класу повинен знати його IUser. Якщо ви називаєте клас, UserImplто тільки клас і ваш контейнер DI знають про Implчастину, а споживачі просто знають, що вони працюють з a User.

Знову ж таки, часів, які я змушений був використовувати, Implтому що краще ім'я не представляє себе, було небагато і далеко між тим, що реалізація називається відповідно до реалізації, тому що це важливо, наприклад,

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

Причин може бути декілька, чому Java взагалі не використовує конвенцію IUser.

1. Частина об'єктно-орієнтованого підходу полягає в тому, що вам не доведеться знати, чи використовує клієнт інтерфейс або клас реалізації. Отже, навіть List - це інтерфейс, а String - це фактичний клас, метод може бути переданий обом - не має сенсу візуально розрізняти інтерфейси.

2. Взагалі ми будемо віддавати перевагу використанню інтерфейсів у коді клієнта (наприклад, надайте список списку ArrayList). Тому не має сенсу робити так, щоб інтерфейси виділялися виключеннями.

3. Конвенція про іменування Java надає перевагу довшим іменам із фактичними значеннями префіксам угорського стилю. Отже, цей код буде максимально читабельним: список представляє список, а користувач представляє користувача, а не IUser.

Існує також інша конвенція, яка використовується багатьма проектами з відкритим кодом, включаючи Весну.

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

Мені особисто не подобається префікс "Я" з тієї простої причини, що його необов'язкова умова. Отже, якщо я прийму це, чи означає IIOPConnection інтерфейс для IOPConnection? Що робити, якщо у класу немає префікса "Я", чи знаю я його не інтерфейс? Відповідь тут "ні", тому що конвенції не завжди дотримуються, а поліцейський контроль за ними створить більше роботи, яку збереже сама конвенція.

Як сказав інший плакат, зазвичай краще, щоб інтерфейси визначали можливості, а не типи. Я б схильний не "реалізовувати" щось на кшталт "Користувача", і саме тому "IUser" часто не дуже потрібний описаним тут способом. Я часто бачу класи як іменники та інтерфейси як прикметники:

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

Іноді прикметник не має сенсу, але я все-таки використовую інтерфейси для моделювання поведінки, дій, можливостей, властивостей тощо, а не типів.

Крім того, якщо ви дійсно збиралися зробити одного Користувача і назвати його Користувачем, то який сенс також мати інтерфейс IUser? І якщо у вас буде кілька користувачів різних типів, яким потрібно реалізувати загальний інтерфейс, що додавання "Я" до інтерфейсу заощадить у виборі імен реалізацій?

Я думаю, що більш реалістичним прикладом може бути те, що деякі типи користувачів повинні мати можливість увійти до певного API. Ми могли б визначити інтерфейс для входу, а потім мати батьківський клас "Користувач" із суперкласами SuperUser, DefaultUser, AdminUser, AdministrativeContact та ін., Деякі з яких будуть чи не реалізуватимуть інтерфейс Login (Logible?) За необхідності.

Боб Лі сказав один раз на презентації:

у чому сенс інтерфейсу, якщо у вас є лише одна реалізація.

Отже, ви починаєте з однієї реалізації, тобто без інтерфейсу. пізніше ви вирішите, ну тут потрібен інтерфейс, тому ви перетворите свій клас в інтерфейс.

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

тож стає зрозуміло -> Інтерфейс Реалізація користувача UserImpl.

В C # це

public class AdminForumUser : UserBase, IUser

Ява скаже

public class AdminForumUser extends User implements ForumUserInterface

Через це я не думаю, що конвенції є настільки важливими для Java для інтерфейсів, оскільки існує явна різниця між успадкуванням та реалізацією інтерфейсу. Я б сказав, що просто вибирайте будь-який конвент про іменування, який ви хотіли б, доки ви константський і використовуєте щось, щоб показати людям, що це інтерфейси. Я не робив Java протягом декількох років, але всі інтерфейси просто були у власному каталозі, і це було умовою. Ніколи насправді не було з цим жодних проблем.

З мого досвіду, конвенція "Я" застосовується до інтерфейсів, призначених забезпечити контракт класу, особливо коли сам інтерфейс не є абстрактним поняттям класу.

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

Я також очікував, що інтерфейси, що визначають можливості - Comparable, Iterableі т. Д. - будуть названі так, а не як IComparableабоIIterable .

Виконуючи добрі принципи ОО, ваш код повинен (наскільки це практично / можливо) залежати від абстракцій, а не конкретних класів. Наприклад, зазвичай краще написати такий метод:

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

ніж це:

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

Якщо ви дотримуєтесь цієї ідеї, то я стверджую, що ваш код буде більш читабельним, якщо ви дасте імена інтерфейсів, наприклад "User" та "BankAccount" (наприклад), а не "IUser", "UserInterface" або інші варіанти.

Єдині біти коду, які повинні піклуватися про фактичні конкретні класи - це місця, де будуються конкретні класи. Все інше слід писати за допомогою інтерфейсів.

Якщо ви це зробите, то "потворні" конкретні назви класів на кшталт "UserImpl" повинні бути безпечно приховані від решти коду, який може весело продовжувати використання "nice" імен інтерфейсу.

= v = Префікс "Я" також використовується в рамках Wicket, де я швидко звик до нього. Загалом, я вітаю будь-яку умову, яка скорочує громіздкі назви класів Java. Хоча, все, що в каталогах та в Javadoc все позначається за "Я".

Практика кодування Wicket схожа на Swing, оскільки багато екземплярів управління / віджетів будуються як анонімні внутрішні класи з вбудованими деклараціями методу. Прикро, що він відрізняється на 180 ° від Swing тим, що Swing використовує префікс ("J") для класів реалізації.

Суфікс "Impl" - це манірне абревіатура і не інтернаціоналізується добре. Якби ми хоча б пішли з "Imp", це було б симпатичніше (і коротше). "Impl" використовується для МОК, особливо Spring, тому ми зараз начебто застрягли з ним. Однак, це отримує трохи шизо після 3 різних конвенцій у трьох різних частинах однієї бази коду.

Це більш широка конвенція про іменування в будь-якому реальному сенсі? Я більше на стороні C ++, а не дуже на Яві та нащадках. Скільки мовних спільнот використовують I конвенцію?

Якщо у вас є стандартна умова іменування магазину, незалежна від мови, використовуйте її. Якщо ні, перейдіть за умовами назви мови.