Чи банда чотирьох ретельно досліджувала «Простір візерунка»?

З того часу, як я вперше дізнався про шаблони дизайну Gang of Four (GoF) , щонайменше 10 років тому, у мене складається враження, що ці 23 візерунки повинні бути лише невеликим зразком чогось набагато більшого, що мені подобається називати Pattern Space . Цей гіпотетичний простір шаблонів складається з усіх рекомендованих рішень (відомих чи невідомих) для загальних об'єктно-орієнтованих проблем проектування програмного забезпечення.

Тому я очікував, що кількість відомих та задокументованих моделей дизайну значно зросте.

Це не сталося. Через 20 років після виходу книги GoF у статті Вікіпедії вказано лише 12 додаткових зразків, більшість з яких набагато менш популярні, ніж оригінали. (Я не включав сюди шаблони одночасності, оскільки вони охоплюють певну тему.)

Які причини?

• Чи є набір моделей GoF насправді більш вичерпним, ніж я думаю?

• Чи впав інтерес до пошуку нових зразків, можливо, тому, що вони виявилися не такими корисними в розробці програмного забезпечення?

• Щось ще?

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

• "Спільнота зразків " , WikiWikiWeb
• "Дослідницька група з моделей дизайну Нью-Йорка" , Industrial Logic
• "Каталог візерунків" , The Hillside Group

Але потім...

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

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

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

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

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

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

Шаблони дизайну (в розумінні GoF) мають лише одну мету: компенсувати недоліки в мові програмування, яку ви використовуєте.

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

Я думаю, що тут грають три фактори.

Відсутність критичної маси

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

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

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

Занадто багато візерунків

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

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

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

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

Відсутність інтересу

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

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

Підсумок

Помилка моделей дизайну через:

1. Вони не змогли досягти критичної маси.
2. Диференціація між моделями була недостатньою для гарантування чіткості.
3. Вони здебільшого мали справу з частинами коду, майже нікого насправді не цікавило.

У шаблонах відсутні абстракції, прості візерунки абстрагуються, складні візерунки не розпізнаються, тому шаблони не корисні (за винятком кількох високорівневих).

Я думаю, що Пол Грехем сказав це найкраще:

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

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

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

Щось, що жодна з інших відповідей не згадує, що також є актуальним:

Зростання динамічно набраних мов.

Коли книга вийшла вперше, відбулося серйозне обговорення того, що Java просто надто повільна, щоб зробити справжню роботу. Тепер Java часто використовується на більш виразних мовах через її швидкість. Можливо, Ruby, Python, JavaScript та ін все ще занадто повільні для деяких важливих класів додатків, але за великим рахунком вони досить швидкі для більшості цілей. І JavaScript принаймні стає швидшим, незважаючи на те, що в кожній версії пакується більше функцій.

Оригінальна книга GoF мала шаблони і в smalltalk, і в ++, і якщо пам'ять слугує, то шаблони завжди були коротшими у smalltalk, а іноді й істотно. Деякі особливості класичних моделей дизайну - це справді способи додати динамічні функції до статично типованої системи (як уже обговорювана AbstractFactory, в якій ви інстанціюєте правильний клас на основі даних часу виконання). Інші настільки коротші в динамічних мовах, що вони просто врізаються в ідіоматичне використання самої мови.

Це ж сталося. Десятки, якщо не сотні книг були опубліковані у тому, що виглядало як спроба звести всю інформатику до розробки моделей, оскільки видавці та автори намагалися перейти на (або створити) ще одну стрічку. У мене є полиця з ними. Ніколи не консультувався з моменту першого сканування, і так, я був присоском, тому що в ньому практично нічого не було, або фактично не було відомо (див., Наприклад, Тип об'єкта, що не більше ніж третя нормальна форма, висловлена ​​за десяток сторінок замість одного абзацу), і тому, що очевидно, що менше шаблонів, тим краще: пункт, який ухилявся від більшості практиків. Дійсно, коли я опублікував спростування Type Object, мені було доручено переробити текст як шаблон дизайну.Правдива історія. Що також свідчить про ще один недолік проекту: відсутність перегляду чи механізму виключення чи відхилення.

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

Що вони зробили , що було корисно, це дві речі:

• опублікуйте кілька корисних прийомів, таких як шаблон відвідувачів
• надайте стандартний набір імен, який значною мірою застряг: Factory, Adapter, Iterator, ... Якщо ви подивитесь на CORBA, який був розроблений заздалегідь, ви побачите значення цього: всілякі "іноземні" імена, такі як Interceptor , Слуга, Брокер, ...

Ще одна корисна концепція, що виникла, була "анти-шаблон", наприклад "журнал і кидок". Проект, як і багато прихильників у КС, був зірваний з-за власного євангелізму та неправильним прийняттям як чергової релігії СС, і пішов шляхом більшості таких релігій: корисний частинами, але, безумовно, "жодної срібної кулі" ((c ) Фред Брукс, 1965). Сумно, що нам доводиться постійно розкривати це кожні кілька років.

Існувало / є декілька книг під назвою PLoP ( Pattern Languages ​​of Programme Design ), які є антологією робіт, що були представлені на щорічній конференції .

Читаючи книги, я виявив, що деякі зразки були цікавими і новими для мене, деякі з них є стандартами (наприклад, "половина об'єкта плюс протокол").

Тож ні, колекція GoF не була вичерпною, і надихала / надихає людей збирати / описувати / відкривати / винаходити нові.

Імовірно, «лише 12 додаткових зразків, перелічених у статті Вікіпедії», також не є повною колекцією: тобто є інші, задокументовані в інших місцях, наприклад, у книгах PLoP, а може бути і в інших місцях.

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

Ви очікуєте, що електромонтажник матиме деякі інструменти, яких звичайний будівельник не має, також ви очікуєте, що програміст WPF знати схеми проектування "Властивості залежності" або "SQL-програміст", щоб знати схему проектування для використання тригерів для створити дані аудиту.

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

Ще декілька модельних моделей дизайнерських книг - "Переймка, вдосконалення дизайну існуючого коду (Мартін Фаулер)" та "Чистий код: Довідник про гнучку майстерність програмного забезпечення" (Роберт К. Мартін) " Обидві ці книги представляють вміст як перетворення, яке ви робите. до вашого поточного коду, а не як "попередньо консервований дизайн багаторазового використання", однак вони є настільки ж "моделями дизайну".

Ось інтерв'ю з Еріхом Гаммою, де він розмірковував про їх вибір моделей і те, що вони змінили б сьогодні (ну і сьогодні, як 10 років тому, ха-ха).

http://www.informit.com/articles/article.aspx?p=1404056

Ларрі: Як би ви відтворили "Шаблони дизайну"?

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

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

Ось ось деякі зміни:

• Перекладача та полегшеної ваги слід перенести в окрему категорію, яку ми назвали «Інше / Складене», оскільки вони справді є іншими звірами, ніж інші зразки. Фабричний метод буде узагальнений до Фабричного.
• Категорії: основні, творчі, периферійні та інші. Метою тут є наголосити на важливих зразках та відокремити їх від менш часто використовуваних.
• Новими членами є: Null Object, Type Object, Injection Dependency, та Extension Object / Interface (див. "Об'єкт розширення" у "Мові шаблону". 3, Addison-Wesley, 1997).
• Це були такі категорії:
  • Основні: композитний, стратегія, стан, команда, ітератор, проксі, метод шаблону, фасад
  • Творчі: завод, прототип, конструктор, впорскування залежностей
  • Периферія: абстрактна фабрика, відвідувач, декоратор, посередник, тип об’єкта, нульовий об'єкт, об’єкт розширення
  • Інше: Легка вага, Перекладач

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

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

Тому я очікував, що кількість відомих та задокументованих моделей дизайну значно зросте.

Це не сталося. Через 20 років після виходу книги GoF у статті Вікіпедії вказано лише 12 додаткових зразків, більшість з яких набагато менш популярні, ніж оригінали. (Я не включав сюди шаблони одночасності, оскільки вони охоплюють певну тему.)

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

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

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

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

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

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

Шаблони нескінченні. Ви можете налаштувати кожен візерунок або поєднати n відповідність, щоб створити нові .. Шаблони інтеграції підприємств також добре визначені. Так, так, Gof не відчував болю за документування шаблонів за допомогою uml та створив стандарт для їх пояснення. Але для кожного шаблону домену розвиваються, і вони також змінюються для експресивної мови на зразок python або scala.