Ніколи не використовуйте Strings на Java? [зачинено]

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

public void bookTicket(
  String name,
  String firstName,
  String film,
  int count,
  String cinema);

public void bookTicket(
  Name name,
  FirstName firstName,
  Film film,
  Count count,
  Cinema cinema);

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

Інкапсуляція існує для захисту вашої програми від змін . Чи зміниться подання Імені? Якщо ні, то ви витрачаєте свій час, і YAGNI застосовується.

Редагувати: Я прочитав пост у блозі, і він має принципово гарну ідею. Проблема полягає в тому, що він занадто далеко змінив його масштаб. Що - щось на зразок String orderId це дуже погано, тому що по- видимому "!"£$%^&*())ADAFVF, не є допустимим orderId. Це означає, що Stringпредставляє набагато більше можливих значень, ніж є дійсні orderIds. Однак, для чогось подібного name, тоді ви не можете передбачити, що може бути, а що не може бути дійсним іменем, а будь-яке Stringє дійсним name.

По-перше, ви (правильно) зводите можливі входи лише до дійсних. По-друге, ви не досягли звуження можливих дійсних входів.

Ще раз редагуйте: розгляньте випадок недійсного введення. Якщо ви напишете "Гарет Гобулькок" як своє ім'я, це буде виглядати нерозумно, це не буде кінцем світу. Якщо ви введете недійсний OrderID, швидше за все, він просто не працюватиме.

Це просто божевільно :)

• Використовуйте здоровий глузд
• Не зайвий інженер!
• Нехай це буде малим просто!
• Вам це не потрібно (YagNi)

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

Не робіть цього; це надмірно ускладнить речі, і Ви цього не потребуєте

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

Переваги

Головне серед переваг - можливість змінювати та розширювати код. Якщо ви використовуєте

class Point {
    int x,y;
    // other point operations
}

замість того, щоб просто пропустити пару цілих чисел навколо, а це, на жаль, багато інтерфейсів, - згодом стає набагато легше додати ще один вимір. Або змінити тип на double. Якщо ви використовуєте List<Author> authorsабо List<Person> authorsзамість List<String> authorsцього, пізніше стає набагато простіше додати більше інформації до того, що представляє автор. Якщо записати це так, то здається, що я висловлюю очевидне, але на практиці я був винен, що я багато разів використовував рядки таким чином, особливо у тих випадках, коли це було не очевидно на початку, тоді мені знадобилося б більше, ніж рядок.

На даний момент я намагаюся переробити деякий список рядків, який переплітається в моєму коді, тому що мені там потрібна додаткова інформація, і я відчуваю біль: \

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

Кінцева вигода - це безпека типу , з очевидних причин, але в моїх очах це незначна річ.

Недоліки

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

Він може залучати безліч зайвих сеттерів (або конструкцій) та гетерів . Автор блогу new Point(x(10), y(10))замість цього дає справді некрасивий приклад new Point(10, 10), і я хотів би додати, що використання може також включати такі речі, як Math.max(p.x.get(), p.y.get())не Math.max(p.x, p.y). І довгий код часто вважається важчим для читання, і це справедливо. Але, чесно кажучи, у мене є відчуття, що багато коду переміщує об'єкти навколо, і лише вибрані методи створюють його, і ще менше людей потребують доступу до його суворих деталей (що так і не є OOPy).

Дискусійний

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

Як і в більшості інших шкіл програмування думки, я вважаю, що це нездорово сприймати цю крайність. Я не бачу, щоб я колись розділяв координати x і y, щоб вони були різного типу. Я не вважаю Countза потрібне, коли intслід вистачити. Мені не подобається unsigned intвикористання C - хоча теоретично це добре, воно просто не дає вам достатньо інформації, і забороняє розширювати ваш код пізніше, щоб підтримати цей магічний -1. Іноді вам потрібна простота.

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

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

Хоча це щось надмірне, я часто думаю, що більшість речей, які я бачив, замість цього недостатньо розроблені.

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

НАЙВИШНІЙ (на сьогоднішній день) бібліотеку Java, з якою я працював, написав хтось, хто дуже любив Smalltalk і моделював бібліотеку GUI після неї, щоб вона діяла більше як smalltalk - проблема в тому, що кожен метод приймав один і той же базовий об'єкт, але насправді не вдалося ВИКОРИСТИТИ все, на що може бути передано базовий об'єкт, тому ви знову вгадували, що перейти до методів, і не знаючи, чи не вдалося ви виконати до виконання (Щось я мав мати справу з кожним разом, коли я працював у С).

Інше питання - Якщо ви обходите рядки, ints, колекції та масиви без об’єктів, все, що у вас є, - це кулі даних без сенсу. Це здається природним, коли ви думаєте, що з точки зору бібліотек використовуватиметься "якийсь додаток", але при розробці цілого додатка набагато корисніше призначити значення (код) всім вашим даним у місці, де дані визначені, і лише думати про умови взаємодії цих об'єктів високого рівня. Якщо ви обмінюєте примітиви замість об'єктів, ви, за визначенням, змінюєте дані в місці, відмінному від визначеного (Це також, чому я дійсно не люблю Setters і Getters - та сама концепція, ви працюєте на дані, які не є вашими).

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

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

Мені б дуже цікаво побачити добре написаний проект java, в якому насправді було визначено занадто багато класів (Де це ускладнило програмування), я починаю вважати, що не можна мати занадто багато класів.

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

public void bookTicket(
  String name,
  String firstName,
  String film,
  int count,
  String cinema);

Для визначення фактичного мецената, який бронює квитки, потрібні два параметри. У вас можуть бути два різних фільми з однаковими іменами (наприклад, рімейки), у вас може бути той самий фільм з різними іменами (наприклад, переклади). Певна мережу кінотеатрів можуть мати різні філії, так як ви будете мати справу з цим в рядку і послідовним чином (наприклад , ви використовуєте $chain ($city)або $chain in $cityнавіть що - то ще й як ви збираєтеся , щоб переконатися , що це Найгірше - це конкретизація вашого покровителя за допомогою двох параметрів, той факт, що надано і ім’я, і прізвище, не гарантує дійсного замовника (і ви не можете розрізнити двох John Doeс).

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

Отже, повідомлення в блозі IMHO просто говорить "переконайтеся, що ви передаєте правильні типи", його автор просто зробив надто обмежений вибір, зокрема, для вибору основних типів даних (що є неправильним повідомленням).

Пропонована альтернатива краще:

public void bookTicket(
  Name name,
  FirstName firstName,
  Film film,
  Count count,
  Cinema cinema);

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

Що варто, я б насправді написав щось подібне

public Ticket bookTicket(
  Person patron,
  Film film,
  int numberOfTickets,
  Cinema cinema);

Короткий короткий огляд: вам не слід передавати безглузді змінні; єдиний раз, коли ви насправді вказуєте об'єкт зі значенням, яке не визначає фактичного об'єкта, це коли ви запускаєте запит (наприклад public Collection<Film> findFilmsWithTitle(String title)) або коли ви збираєте доказ-концепцію. Утримуйте чисту систему, тому не використовуйте занадто загальний тип (наприклад, фільм, представлений a String) або занадто обмежуючий / конкретний / надуманий (наприклад, Countзамість int). Використовуйте тип, який визначає ваш об'єкт однозначно та однозначно, коли це можливо та життєздатний.

редагувати : ще коротший підсумок. Для невеликих застосувань (наприклад, доказ понять): навіщо турбуватися зі складною конструкцією? Просто використовуйте Stringабо intпродовжуйте це.

Для великих застосувань: чи справді це велика кількість класів, які складаються з одного поля з базовим типом даних? Якщо у вас таких занять мало, у вас просто "нормальні" об'єкти, нічого особливого там не відбувається.

Я вважаю, що ідея інкапсуляції струн ... це лише незавершена конструкція: надмірно складна для невеликих додатків, недостатньо повна для великих застосувань.

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

Я б сказав, що це дійсно гарна ідея на мові з сильно набраною функцією typedef.

У Java у вас цього немає, тому створення цілого нового класу для цих речей означає, що вартість, ймовірно, перевершує вигоду. Ви також можете отримати 80% переваги, обережно ставившись до імені змінної / параметрів.

Було б добре, якщо IF String (кінцевий Integer, і ... кажучи лише про String) не був остаточним, тому ці класи могли бути БЕЗКОШТОВНИМ (обмеженим) рядком зі значенням і все-таки могли бути відправлені на якийсь самостійний об'єкт, який вміє обробляти базовий тип (без розмови назад і назад).

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

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

На приклад: у нашій розробленій в даний час системі існує безліч різних сутностей, які можна ідентифікувати за різними видами ідентифікаторів (за рахунок використання зовнішніх систем), іноді навіть одного типу сутності. Усі ідентифікатори - це рядки, тож якщо хтось змішує тип ідентифікатора, який повинен передаватися як параметр, не відображається помилка часу компіляції, але програма підірватиметься під час виконання. Це трапляється досить часто. Тож я мушу сказати, що головна мета цього принципу - не захист від змін (хоча це також і служить), а захист себе від помилок. І як би там не було, якщо хтось розробляє API, він повинен відображати поняття домену, тому концептуально корисно визначати конкретні доменні класи - все залежить від того, чи є порядок у свідомості розробників,