Чи "уникнути проблеми йо-йо" є вагомою причиною, щоб дозволити "примітивну одержимість"?

Згідно Коли коли примітивна одержимість не є кодовим запахом? , Я повинен створити об'єкт ZipCode, щоб представляти поштовий індекс, а не об'єкт String.

Однак, зі свого досвіду, я волію бачити

public class Address{
    public String zipCode;
}

замість

public class Address{
    public ZipCode zipCode;
}

тому що я думаю, що останній вимагає від мене перейти до класу ZipCode, щоб зрозуміти програму.

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

Тому я хотів би перенести методи ZipCode в новий клас, наприклад:

Старий:

public class ZipCode{
    public boolean validate(String zipCode){
    }
}

Нове:

public class ZipCodeHelper{
    public static boolean validate(String zipCode){
    }
}

так що тільки той, кому потрібно перевірити поштовий індекс, залежав би від класу ZipCodeHelper. І я знайшов ще одну «користь» від збереження примітивної одержимості: він зберігає клас схожим на його серіалізовану форму, якщо така є, наприклад: таблиця адрес із стовпчиком zipCode.

Моє запитання: чи "уникнення проблеми йо-йо" (переміщення між визначеннями класів) є вагомою причиною, щоб дозволити "примітивну одержимість"?

Припущення полягає в тому, що вам не потрібно йо-йо класу ZipCode, щоб зрозуміти клас адреси. Якщо ZipCode добре розроблений, це повинно бути очевидним, що він робить, лише прочитавши клас адреси.

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

Наприклад, я впевнений, що ви не будете йо-йо читати вихідний код для String кожного разу, коли стикаєтеся з String в коді.

Перейменування класу з ZipCode на ZipCodeHelper дозволяє припустити, що зараз існує два окремих поняття: поштовий індекс та помічник поштового індексу. Так удвічі складніше. А тепер система типів не може допомогти вам розрізнити довільну рядок та дійсний поштовий індекс, оскільки вони мають один і той же тип. Тут доречна "одержимість": Ви пропонуєте більш складну і менш безпечну альтернативу лише тому, що хочете уникнути простого типу обгортки навколо примітиву.

Використання примітиву IMHO виправдано у випадках, коли немає перевірки чи іншої логіки залежно від конкретного типу. Але як тільки ви додасте будь-яку логіку, набагато простіше, якщо ця логіка буде інкапсульована з типом.

Щодо серіалізації, я думаю, що це звучить як обмеження в рамках, яку ви використовуєте. Безумовно, ви повинні мати змогу серіалізувати ZipCode до рядка або відобразити його у стовпчик бази даних.

Якщо можете зробити:

new ZipCode("totally invalid zip code");

І конструктор для ZipCode робить:

ZipCodeHelper.validate("totally invalid zip code");

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

validateМетод повинен бути статичним методом на класі ZipCode. Тепер знання "дійсного" поштового коду поєднуються разом із класом ZipCode. З огляду на те, що ваші приклади коду виглядають як Java, конструктор ZipCode повинен кинути виняток, якщо надано неправильний формат:

public class ZipCode {
    private String zipCode;

    public ZipCode(string zipCode) {
        if (!validate(zipCode))
            throw new IllegalFormatException("Invalid zip code");

        this.zipCode = zipCode;
    }

    public static bool validate(String zipCode) {
        // logic to check format
    }

    @Override
    public String toString() {
        return zipCode;
    }
}

Конструктор перевіряє формат і викидає виняток, тим самим запобігаючи створенню недійсних поштових індексів, а статичний validateметод доступний для іншого коду, тому логіка перевірки формату інкапсульована у класі ZipCode.

У цьому варіанті класу ZipCode немає "йо-йо". Це просто називається правильним об'єктно-орієнтованим програмуванням.

Ми також будемо ігнорувати тут інтернаціоналізацію, що може зажадати іншого класу під назвою ZipCodeFormat або PostalService (наприклад PostalService.isValidPostalCode (...), PostalService.parsePostalCode (...) тощо).

Якщо ви з цим питанням багато бороєтесь, можливо, мова, яку ви використовуєте, не є правильним інструментом для роботи? Такі "примітивні типи приміток" виражаються тривіально легко, наприклад, у F #.

Там ви могли, наприклад, написати:

type ZipCode = ZipCode of string
type Town = Town of string

type Adress = {
  zipCode: ZipCode
  town: Town
  //etc
}

let adress1 = {
  zipCode = ZipCode "90210"
  town = Town "Beverly Hills"
}

let faultyAdress = {
  zipCode = "12345"  // <-Compiler error
  town = adress1.zipCode // <- Compiler error
}

Це дійсно корисно для уникнення поширених помилок, як порівняння ідентифікаторів різних сутностей. А оскільки ці типові примітиви набагато легші, ніж клас C # або Java, ви в кінцевому підсумку використовуєте їх.

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

(1) Усі адреси гарантовано знаходяться в одній країні. Жодних винятків. (Наприклад, немає іноземних клієнтів, або немає працівників, приватна адреса яких знаходиться за кордоном, поки вони працюють для іноземного замовника.) У цій країні є поштові індекси, і від них можна очікувати, що вони ніколи не будуть серйозно проблемними (тобто вони не потребують введення у вільній формі наприклад "зараз D4B 6N2, але це змінюється кожні 2 тижні"). Поштові індекси використовуються не лише для адреси, але для перевірки платіжної інформації або подібних цілей. - За цих обставин клас поштового індексу має багато сенсу.

(2) Адреси можуть бути майже в кожній країні, тому десятки чи сотні адресних схем із поштовими індексами або без них (і з тисячами дивних винятків та особливих випадків) є актуальними. "Поштовий код" дійсно просять лише нагадувати людям з країн, де поштові індекси використовуються, щоб не забути вказати свої. Адреси використовуються лише для того, що якщо хтось втратить доступ до свого акаунта, і він зможе підтвердити своє ім’я та адресу, доступ буде відновлено. - За цих обставин класи поштових індексів для всіх відповідних країн будуть зусиллями величезними. На щастя, вони зовсім не потрібні.

Інші відповіді говорили про моделювання домену OO та використання більш багатого типу для представлення вашої цінності.

Я не погоджуюся, особливо з огляду на приклад коду, який ви опублікували.

Але мені також цікаво, чи це насправді відповідає назви вашого питання.

Розглянемо наступний сценарій (витягнутий із фактичного проекту, над яким я працюю):

У вас є віддалений додаток на польовому пристрої, який спілкується з вашим центральним сервером. Одне з полів DB для запису пристрою - це поштовий індекс адреси, на якій знаходиться польовий пристрій. Вас не хвилює поштовий індекс (чи будь-яка інша адреса з цього приводу). Усі люди, які переймаються цим, перебувають з іншого боку кордону HTTP: ви просто стаєте єдиним джерелом правди для даних. Він не має місця у вашому доменному моделюванні. Ви просто записуєте його, підтверджуєте, зберігаєте і на запит переміщуєте його в JSON-краплі, щоб вказати в іншому місці.

У цьому сценарії багато чого, крім перевірки вставки, з обмеженням зворотного виразів SQL (або його еквівалентом ORM), ймовірно, є надмірним для різноманітності YAGNI.

ZipCodeАбстракція може мати сенс , тільки якщо ваш Addressкласі не також TownNameвласність. В іншому випадку у вас є половина абстракції: поштовий індекс позначає місто, але ці два пов'язані біти інформації знаходяться в різних класах. Це не зовсім має сенс.

Однак навіть тоді це все-таки не правильне застосування (а точніше рішення) примітивної одержимості; яка, як я розумію, в основному зосереджена на двох речах:

1. Використання примітивів у якості вхідних (або навіть вихідних) значень методу, особливо коли потрібна колекція примітивів.
2. Класи, які з часом отримують додаткові властивості, не замислюючись над тим, чи слід деякі з них групувати у свій підклас.

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

Ось як ви знаєте, що не потрібно більше підрозділятись: їх розбиття ще більше погіршить функціональний намір Addressкласу. Так само вам не потрібен Nameпідклас, щоб використовувати його у Personкласі, якщо тільки Name(без особи, що додається) є вагомим поняттям у вашому домені. Що це (як правило) не є. Імена використовуються для ідентифікації людей, вони зазвичай не мають значення самостійно.

Зі статті:

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

Вихідний код читається набагато частіше, ніж написано. Таким чином, проблема йо-йо про необхідність перемикання між багатьма файлами викликає занепокоєння.

Однак ні , проблема йо-йо вважається набагато актуальнішою при роботі з глибоко взаємозалежними модулями або класами (які дзвонять між собою назад і назад). Це - особливий вид кошмару для читання, і це, мабуть, те, що мав на увазі формуляр проблеми йо-йо.

Однак - так , важливо уникати занадто багато шарів абстракції!

Всі нетривіальні абстракції, певною мірою, є герметичними. - Закон про проникнення абстракцій.

Наприклад, я не погоджуюся з припущенням, зробленим у відповіді mmmaaa, що "вам не потрібно йо-йо, щоб [(відвідати)] клас ZipCode, щоб зрозуміти клас адреси". Мій досвід полягав у тому, що ви це робите - принаймні перші кілька разів читаєте код. Однак, як зазначали інші, бувають випадки, коли ZipCodeклас підходить.

YAGNI (Я не буду потрібен) кращий малюнок , щоб слідувати , щоб уникнути Лазанья коду ( тобто занадто великою кількістю шарів) - абстракції, такі як типи і класи там , щоб допомогти програмісту, і не повинні використовуватися , якщо вони не є допомогу.

Я особисто прагну "зберегти рядки коду" (і, звичайно, пов'язані "збереження файлів / модулів / класів" тощо). Я впевнений, що є такі, хто застосував би до мене епітет "примітивних одержимих" - мені здається, важливіше мати код, про який легко міркувати, ніж турбуватися про мітки, шаблони та анти-шаблони. Правильний вибір, коли створити функцію, модуль / файл / клас або поставити функцію у загальне місце розташування, дуже ситуативний. Я орієнтуюсь приблизно на 3-100 функцій рядків, 80-500 рядкових файлів та "1, 2, n" для багаторазового використання бібліотечного коду ( SLOC - не включаючи коментарів чи котлован; я, як правило, хочу хоча б 1 додатковий мінімум SLOC на рядок обов'язкового котельня).

Більшість позитивних зразків виникають у розробників, які роблять саме це, коли їм це потрібно . Набагато важливіше навчитися писати читабельний код, ніж намагатися застосовувати шаблони без тієї самої проблеми для вирішення. Будь-який хороший розробник може реалізувати заводський зразок, не бачивши його раніше, в тому незвичайному випадку, коли це правильно підходить для їхньої проблеми. Я використовував заводський зразок, модель спостерігача і, мабуть, сотні, крім того, не знаючи їх назви (тобто чи існує "змінна схема присвоєння"?). Для цікавого експерименту - подивіться, скільки моделей GoF вбудовано в мову JS - я припинив рахувати приблизно через 12-15 років у 2009 році. Фабрична схема така ж проста, як повернення об'єкта з конструктора JS, наприклад - не потрібно a WidgetFactory.

Отже - так , іноді ZipCode це хороший клас. Однак ні , проблема йо-йо не є суто актуальною.

Проблема йо-йо актуальна лише в тому випадку, якщо вам доведеться пересуватись вперед-назад. Це викликано однією або двома речами (іноді обома):

1. Погане називання. ZipCode здається нормальним, ZoneImprovementPlanCode потребує огляду більшості людей (і тих, хто не вразить).
2. Невідповідна муфта. Скажімо, у класу ZipCode є пошук регіонального коду. Ви можете подумати, що це має сенс, тому що це зручно, але це насправді не пов’язано з ZipCode, і вбрання його в нього означає, що зараз люди не знають, куди іти.

Якщо ви можете подивитися на ім’я та мати розумне уявлення про те, що воно робить, а методи та властивості роблять досить очевидні речі, вам не потрібно переглядати код, ви можете просто використовувати його. В цьому і полягає вся суть класів - це модульні фрагменти коду, які можна використовувати і розробляти поодиноко. Якщо вам потрібно подивитися на що-небудь крім API для класу, щоб побачити, що він робить, це в кращому випадку частковий збій.

Пам'ятайте, срібної кулі немає. Якщо ви пишете надзвичайно простий додаток, який потрібно швидко просканувати, то простий рядок може зробити цю роботу. Однак у 98% випадків ціннісний об’єкт, як описано Еріком Евансом у DDD, був би ідеальним. Ви можете легко побачити всі переваги, які надають об'єкти цінності, читаючи.