Так що дивно задавати два запитання спиною до спини, але вони не дуже пов’язані між собою, і я не хотів їх поєднувати, але я не спам-питання, обіцяю!

У всякому разі, я недавній випускник коледжу, і моя освіта лише торкнулася моделей дизайну ... ми реалізували кілька простих, торкнулися того, що є складніші, і отримали вказівку звернутися до книги GoF, якщо ми хотів дізнатися більше. Моє запитання: чи варто вивчити шаблони в книзі GoF? Мені завжди здається протиінтуїтивним спробувати вирішити проблему під класичний зразок, але очевидно, що книга та візерунки відомі чомусь. Вони виявляються достатньо, щоб я мав їх вивчати?

Знову дякую!

Як завжди

Це залежить

Це залежить від того, скільки ви зробили OOP щодо того, чи будете ви розпізнавати чи навіть зможете використовувати шаблони дизайну

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

З іншого боку ... п’ять пальців!

Якщо ви за кілька років зайнялися серйозною роботою над ООП або у вас є надійний наставник, який буде тримати вас на рейках або вам просто подобається читання НУП-ботаніку, то обов'язково йдіть, купуйте книгу та вивчайте її.

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

Так, ви повинні їх вивчити.

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

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

Є ще одна причина, чому варто прочитати: це навчить вас думати . Звичайно, це не срібна куля, але все-таки неоціненне натхнення.

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

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

Книга GOF - чудове джерело багатьох корисних інструментів, якими ми користуємося щодня .

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

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

Прикладами є відвідувачі, одиночні та декоратори.

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

ТАК, але обережно!

Частина ТАК:

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

З обережною частиною:

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

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

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

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

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

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

ТАК, коротше кажучи, вивчати шаблони не тільки варто того ... ви обмежуєте себе НЕ вивчаючи їх. Мені не хочеться описувати всі мотивуючі принципи та загальну форму рішення, коли я кажу: "Схоже на мене відвідувача".

Ось їх веб-сайт: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

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

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

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

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

• Вони були зроблені AFAIK насамперед для мов OOP.
• Деякі проблеми не існують у функціональному програмуванні (Command Pattern - це як зробити першокласні функції, Strategy Pattern наближає функцію вищого порядку ...). Ці зразки призначені для мов (переважно OOP), які не потребують функціональності.
• Вони сортуються за алфавітом. Кілька моделей - це композиція інших, або ідеї складаються з тих, що були там раніше.

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

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

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

Моє запитання: чи варто вивчити шаблони в книзі GoF?

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

Вони виявляються достатньо, щоб я мав їх вивчати?

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

завжди здається контрінтуїтивним спробувати вирішити проблему під класичний зразок

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