Чи повинен геттер кидати виняток, якщо його об’єкт має недійсний стан?

Я часто стикаюся з цією проблемою, особливо на Java, навіть якщо вважаю, що це загальна проблема OOP. Тобто: підвищення винятку виявляє проблему дизайну.

Припустимо, у мене є клас, який має String nameполе і String surnameполе.

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

public void String name;
public void String surname;

public String getCompleteName() {return name + " " + surname;}

public void displayCompleteNameOnInvoice() {
    String completeName = getCompleteName();
    //do something with it....
}

Тепер я хочу посилити поведінку свого класу, видавши помилку, якщо displayCompleteNameOnInvoiceвиклик до того, як ім'я було призначено. Здається, це гарна ідея, чи не так?

Я можу додати getCompleteNameметод підвищення винятків до методу. Але таким чином я порушую «неявний» контракт із користувачем класу; в цілому одержувачі не повинні викидати винятки, якщо їх значення не встановлено. Гаразд, це не стандартний геттер, оскільки він не повертає жодного поля, але, з точки зору користувача, відмінність може бути надто тонкою, щоб думати про це.

Або я можу викинути виняток ізсередини displayCompleteNameOnInvoice. Але для цього я повинен перевірити безпосередньо nameабо surnameполя і при цьому я б порушити абстракції , представлені getCompleteName. Саме цей метод відповідає за перевірку та створення повного імені. Він навіть міг би вирішити, грунтуючись на рішенні на інших даних, що в деяких випадках це достатньо surname.

Таким чином, видається, що єдиною можливістю є зміна семантики методу getCompleteNameна composeCompleteName, що передбачає більш "активну" поведінку і, відповідно, здатність кидати виняток.

Це краще рішення дизайну? Я завжди шукаю найкращий баланс між простотою та правильністю. Чи є проектна посилання на це питання?

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

Відповідь, яку надає DeadMG, значною мірою зазначає це, але дозвольте мені викласти це трохи інакше: уникайте об'єктів з недійсним станом. Об'єкт повинен бути "цілим" у контексті завдання, яке він виконує. Або не повинно існувати.

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

Не має об’єкта з недійсним станом.

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

Отже, питання до цієї частини - "чому ви дозволяєте ім'я чи прізвище бути недійсними?" Якщо це не те, що є дійсним у класі, щоб він працював належним чином, не дозволяйте. Запропонуйте конструктору чи конструктору, який належним чином підтверджує створення об'єкта, і якщо це неправильно, поставте питання в цьому пункті. Ви також можете скористатись одним із наявних @NotNullприміток , щоб допомогти повідомити, що "це не може бути нульовим" та застосувати його в кодуванні та аналізі.

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

Геттери, які роблять більше.

На цю тему є зовсім небагато. Ви отримали скільки логіки в Getters та що слід дозволити всередині геттерів та сетерів? звідси і геттери та сетери, що виконують додаткову логіку на Stack Overflow. Це питання, яке виникає знову і знову в дизайні класів.

Основою цього є:

в цілому одержувачі не повинні викидати винятки, якщо їх значення не встановлено

І ти маєш рацію. Вони не повинні. Вони повинні виглядати «тупими» до решти світу і робити те, що очікується. Занадто багато логіки там призводить до питань, де порушується закон найменшого здивування. І давайте зіткнутися з цим, ви насправді не хочете загортати гетерів, try catchтому що ми знаємо, як сильно ми любимо це робити взагалі.

Існують також ситуації, коли ви повинні використовувати такий getFooметод, як фреймворк JavaBeans, і коли у вас є щось, що викликає EL, очікуючи отримати бін (так що <% bar.foo %>насправді дзвінки getFoo()в класі - відміняючи «якщо боб буде робити композицію або повинен що залишається для перегляду? ", тому що можна легко придумати ситуації, коли те чи інше може бути правильною відповіддю)

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

В кінці дня...

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

Намагаючись дотриматись смислової чистоти істоти private T foo; T getFoo() { return foo; }, що потрапляє, у якийсь момент ви увійдете в проблеми. Іноді код просто не відповідає тій моделі, а контури, що проходять, намагаючись утримати це, просто не мають сенсу ... і в кінцевому підсумку це ускладнює проектування.

Приймайте іноді, що ідеали дизайну не можуть бути реалізовані так, як ви хочете їх у коді. Вказівки - це вказівки - не кайдани.

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

getCompleteNameне кидає виняток, якщо імена неініціалізовані, і displayCompleteNameOnInvoiceтак.

public String getCompleteName()
{
    if (name == null || surname == null)
    {
        return null;
    }
    return name + " " + surname;
}

public void displayCompleteNameOnInvoice() 
{
    String completeName = getCompleteName();
    if (completeName == null)
    {
        //throw an exception.
    }
    //do something with it....
}

Схоже, ніхто не відповідає на ваше запитання.
На відміну від того, що люблять вірити люди, "уникати недійсних об'єктів" не часто є практичним рішенням.

Відповідь:

Так, слід.

Простий приклад: FileStream.Lengthу C # /. NET , який викидає, NotSupportedExceptionякщо файл не шукається.

У вас є вся справа перевірки імені догори дном.

getCompleteName()не повинен знати, які функції будуть використовувати його. Таким чином, відсутність nameдзвінка displayCompleteNameOnInvoice()не є getCompleteName()відповідальністю.

Але, nameце чітка передумова displayCompleteNameOnInvoice(). Таким чином, він повинен взяти на себе відповідальність за перевірку стану (Або він повинен делегувати відповідальність перевірки на інший метод, якщо ви хочете).