Чи повинні назви пакетів бути одниною чи множиною?

227

Часто в бібліотеках, особливо, пакунки містять класи, які організовані навколо однієї концепції. Приклади: xml, sql, користувач, config, db . Я думаю, що ми всі природно відчуваємо, що ці пакети є правильними в однині .

com.myproject. xml .Element
com.myproject. sql .Connection
com.myproject. Користувач .user
com.myproject. користувач .UserFactory

Однак якщо у мене є пакет, який фактично містить колекцію реалізацій одного типу - таких як завдання, правила, обробники, моделі тощо , який є кращим?

com.myproject. завдання .TakeOutGarbageTask
com.myproject. завдання .DoTheDishesTask
com.myproject. завдання .PaintTheHouseTask

або

com.myproject. завдання .TakeOutGarbageTask
com.myproject. завдання .DoTheDishesTask
com.myproject. завдання .PaintTheHouseTask

object-oriented naming packages

— Ніколь
джерело

сингулярно так само, як імена таблиць бази даних завжди повинні бути єдиними, але з різних причин. Наприклад, подивіться на будь-яку популярну стандартну бібліотеку, наприклад, Java або Python.

@Jarrod Roberson: Будь ласка, опублікуйте свою відповідь як відповідь, щоб ми змогли її правильно висловити.

— С.Лотт

@Jarrod знадобиться кілька прикладів, оскільки в стандартних бібліотеках більшість класів належать до першої я перерахованої категорії.

— Ніколь

@ Renesis Поглянь на мою оновлену відповідь.

— Матвій Родатус

@Matthew - мені це подобається. Ви висловили те, про що я підозрював, але не знаєте, як зашифрувати.

— Ніколь

Відповіді:

293

Використовуйте множину для пакетів з однорідним вмістом і однини для пакетів з неоднорідним вмістом.

Клас схожий на відношення до бази даних. Співвідношення бази даних має бути названо в однині, оскільки його записи вважаються екземплярами цього відношення. Функція відношення полягає у складанні складного запису з простих даних.

Пакет, з іншого боку, не є абстракцією даних. Він допомагає в організації коду та вирішенні конфлікту імен. Якщо пакет названий в однині, це не означає, що кожен член пакету є його екземпляром; він містить споріднені, але неоднорідні поняття. Якщо він буде названий у множині (як це часто є ), я б очікував, що пакет містить однорідні поняття.

Наприклад, тип повинен бути названий TaskCollectionзамість TasksCollection, оскільки це колекція, що містить екземпляри Task. Пакет з назвою com.myproject.taskне означає, що кожен міститься клас є екземпляром завдання. Там може бути TaskHandler, А TaskFactoryі т.д. пакет з ім'ям com.myproject.tasks, однак, буде містити різні типи, все завдання: TakeOutGarbageTask, DoTheDishesTaskі т.д.

— Матвій Родатус
джерело

Для подібного питання див. English.stackexchange.com/q/25713 . Категорія аналогічна єдиним число і тип аналогічний множинний.

— Матвій Родатус

Саме посилання, яке ви надали, показує виняток із цього правила. beansє множиною, проте java.beansмістить усі види класів, пов'язані з JavaBeans.

— SkyDan

Хороша відповідь, але я не згоден з логікою відношення бази даних. Відносини в ЄРД є єдиними, оскільки вони відображають відносини між сутностями. Таблиці - це фізична реалізація відносин, і вони містять кілька рядків, і, таким чином, повинні бути множинні ІМО. Відповідь "що в цій таблиці?" є "користувачі", а не "користувач". Зрозуміло, здається, що сингулярне іменування є більш поширеним у корпоративному світі (C #, Java), ніж у таких спільнотах, як Ruby, Python, Javascript та PHP.

— ryeguy

@ Коментар SkyDan вказує на щось дуже важливе, що тут повністю не помічено. Мені здається, що множинне найменування "java.beans" насправді було помилкою, і натомість воно повинно було називатися "java.bean", однини.

— Vicky Chijwani

@VickyChijwani @SkyDan, оскільки JavaBeans ™ є торговою маркою, вони, ймовірно, хотіли зберегти ім'я як таке, щоб посилатися на саму технологію, а значить, і використовували java.beans.

— Хеджазі

Це, мабуть, залежить від конкретної мови. У .NET (C #) це, безумовно, має бути множиною, якщо вірогідне зіткнення імені типу простору імен ( type name expected but namespace foundпомилка). Я мав справу з цим, це не приємно, і це призводить до перекваліфікації імен типів у всьому коді. Приклад .

— Лігво
джерело