Хорошие практики для именования интерфейсов и реализаций и размещения их в пакетах - PullRequest
Новая
       1

Хорошие практики для именования интерфейсов и реализаций и размещения их в пакетах

2 голосов
/ 01 июня 2011

Я в основном говорю о Java и классическом ООП.Скажем, я использую шаблон DAO.Поэтому я создаю интерфейсы, такие как CustomerDao, AccountDao и другие.Я бы поместил его в пакет org.example.dao: 

org.example.dao.CustomerDao
org.example.dao.AccountDao
...

Пока мне все это кажется хорошим.Затем я создаю реализации для этих интерфейсов.Здесь возникает мой первый вопрос: Как мне их назвать ?Одна практика, которую я видел, - это использование * Impl postfix, например CustomerDaoImpl.Или, возможно, имя должно отражать характер реализации, например AccountDatabaseDao или DatabaseBasedAccountDao?Или, может быть, имя следует оставить без изменений, и тогда пакет будет описывать природу этих реализаций?Если вы предлагаете тот или иной путь, то где должны быть размещены эти реализации?Отдельный пакет (какая логика именования?) Или такой же пакет?

Ответы [ 4 ]

2 голосов
/ 01 июня 2011

Есть два лагеря: функциональное и техническое именование.

Один, как: 

org.example.customer
org.example.account

Другой, как: 

org.example.dao
org.example.service

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

При увеличении размера вы можете разделить пакеты, например, org.example.customer.dao, org.example.customer.service и org.example.customer.ui.(Технически это то же самое, что и org.example.dao.customer.dao, org.example.service.customer и org.example.ui.customer, поскольку пакеты Java не являются вложенными.)

Для вашего примера я бы начал с: 

org.example.customer.CustomerDao
org.example.customer.DatabaseCustomerDao (package private)
org.example.account.AccountDao
org.example.account.DatabaseAccountDao (package private)

Чтобы сделать пакет реализации закрытым, вам нужна фабрика для создания экземпляров.Если вы используете DI.DI-framework реализует для вас фабрику, и вы можете внедрить экземпляры в классы пользователей, которые зависят только от контракта интерфейса.

1 голос
/ 01 июня 2011

Есть некоторые, которые делают 

src
    org
        companyname
            dao
                impl

и имеют в виду, например, 

import org.companyname.dao.UserDao;

public class MySQLUserDAO implements UserDao;

или 

src
    org
        companyname
            dao


import org.companyname.dao.UserDao;

public class UserDaoImpl implements UserDao;

Причина, по которой мне нравится первый вариант, заключается в том, чтоВы просматриваете папку impl для размещения реализации интерфейса DAO.Это аккуратнее.

0 голосов
/ 01 июня 2011

Это все зависит от вас.

Все, что вы перечислили, является реальным решением вашей проблемы, и вы не будете первым, кто сделает что-либо из них.

Тем не менее, я предпочитаю сохранять наименование класса как самый большой дескриптор: 

public interface AccountDao {}

public class MySqlAccountDao implements AccountDao {}

Я бы поместил оба в org.company.dao

0 голосов
/ 01 июня 2011

Я не уверен, что существует лучшая практика для этого.Обычно мы используем подпакеты в зависимости от того, как мы реализовали.

Например: Интерфейс может быть com.company.product.dao.ExampleDAO, и (если бы мы использовали MyBATIS) реализация была бы в: com.company.product.dao.mybatis.ExampleDAOMyBatis

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

...