Именование интерфейса в 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. В общем, мы на самом деле предпочтем использовать интерфейсы в клиентском коде (например, предпочтение от List ArrayList). Поэтому не имеет смысла выделять интерфейсы как исключения.

3. Соглашение об именах Java предпочитает более длинные имена с фактическим значением префиксам в венгерском стиле. Таким образом, этот код будет максимально читабельным: список представляет список, а пользователь представляет пользователя, а не IUser.

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

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

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

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

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

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

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

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

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

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

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

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

так становится понятно -> Интерфейс пользователя, реализация 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) {
    ...
}

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

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

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

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

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

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

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

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