Именование интерфейса в 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 предпочитает более длинные имена с фактическим значением префиксам в венгерском стиле. Таким образом, этот код будет максимально читабельным: List представляет собой список, а User представляет пользователя, а не IUser.

Существует также еще одно соглашение, используемое во многих проектах с открытым исходным кодом, включая Spring.

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

Лично мне не нравится префикс «I» по той простой причине, что это необязательное соглашение. Итак, если я приму это, означает ли IIOPConnection интерфейс для IOPConnection? Что, если класс не имеет префикса «I», знаю ли я, что это не интерфейс? Ответ здесь - нет, потому что соглашения не всегда соблюдаются, и их соблюдение создаст больше работы, которую экономит само соглашение.

Как сказал другой автор, обычно предпочтительнее, чтобы интерфейсы определяли возможности, а не типы. Я бы не стал "реализовывать" что-то вроде "User", и именно поэтому "IUser" часто не нужен, как описано здесь. Я часто вижу классы как существительные, а интерфейсы как прилагательные:

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

Иногда прилагательное не имеет смысла, но я все равно обычно использую интерфейсы для моделирования поведения, действий, возможностей, свойств и т. д., а не типов.

Кроме того, если вы действительно собирались создать только одного пользователя и назвать его пользователем, то какой смысл иметь интерфейс IUser? И если у вас будет несколько разных типов пользователей, которым необходимо реализовать общий интерфейс, что избавит вас от добавления «I» к интерфейсу при выборе имен реализаций?

Я думаю, что более реалистичным примером будет то, что некоторые типы пользователей должны иметь возможность войти в определенный API. Мы могли бы определить интерфейс входа в систему, а затем иметь родительский класс «Пользователь» с надклассами SuperUser, DefaultUser, AdminUser, Административный контакт и т. д., некоторые из которых будут или не будут реализовывать интерфейс входа (вход в систему?) по мере необходимости.

Боб Ли сказал однажды на презентации:

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

Итак, вы начинаете с одной реализации, то есть без интерфейса. позже вы решаете, что здесь нужен интерфейс, поэтому вы конвертируете свой класс в интерфейс.

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

так что становится ясно -> Реализация интерфейса User 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.

Следуя хорошим принципам объектно-ориентированного программирования, ваш код должен (насколько это практически возможно) зависеть от абстракций, а не от конкретных классов. Например, обычно лучше написать такой метод:

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

чем это:

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

Если вы последуете этой идее, то я утверждаю, что ваш код будет более читабельным, если вы дадите интерфейсам такие имена, как «User» и «BankAccount» (например), а не «IUser», «UserInterface» или другие варианты.

Единственные фрагменты кода, которые должны заботиться о реальных конкретных классах, — это места, где создаются конкретные классы. Все остальное должно быть написано с использованием интерфейсов.

Если вы сделаете это, то «уродливые» конкретные имена классов, такие как «UserImpl», должны быть надежно скрыты от остального кода, который может весело продолжать использовать «красивые» имена интерфейсов.

=v= Префикс "I" также используется во фреймворке Wicket, где я к нему быстро привык. В общем, я приветствую любые соглашения, сокращающие громоздкие имена классов Java. Однако смущает то, что все расположено в алфавитном порядке под буквой «I» в каталогах и в Javadoc.

Практика кодирования калитки похожа на Swing, поскольку многие экземпляры элементов управления/виджетов создаются как анонимные внутренние классы с объявлениями встроенных методов. Досадно, что он на 180° отличается от Swing тем, что Swing использует префикс ("J") для классов реализации.

Суффикс «Impl» — корявая аббревиатура, которая плохо интернационализируется. Если бы мы хотя бы пошли с "Imp", это было бы симпатичнее (и короче). «Impl» используется для IOC, особенно для Spring, так что пока мы застряли на нем. Тем не менее, это становится немного шизофреническим, если следовать трем различным соглашениям в трех разных частях одной кодовой базы.

Является ли это более широким соглашением об именах в каком-либо реальном смысле? Я больше на стороне С++, и не особо разбираюсь в Java и потомках. Сколько языковых сообществ используют соглашение I?

Если у вас есть стандартное соглашение об именах магазинов, не зависящее от языка, используйте его. Если нет, следуйте соглашению об именах языков.