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

Чи справді їх використовує більшість програмістів?

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

А також, чи ви (програмісти) шукаєте шаблони (до речі, де я повинен шукати?), Коли починаєте розробку? Якщо так, то це, звичайно, звичка, яку я повинен почати сприймати.

ОНОВЛЕННЯ: Я думаю, що коли я запитую, чи програмісти їх використовують, я запитую, якщо у вас виникають проблеми з вирішенням, ви думаєте, «О, я повинен використовувати цю схему».

Коли я був початківцем програмістом, я любив дизайнерські зразки. Я не просто використовував шаблони дизайну. Я завдав їх. Куди і коли б я міг. Я був нещадним. Ага! Шаблон спостерігача! Візьми це! Використовуйте слухача! Проксі! AbstractFactory! Навіщо використовувати один шар абстракції, коли буде робити п’ять? Я спілкувався з багатьма досвідченими програмістами і виявив, що майже всі, хто читає Книгу GoF, проходять цей етап.

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

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

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

Якщо один визнає їх чи ні, більшість програмістів роблять використання шаблонів.

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

Деякі поширені шаблони вбудовані в деякі мови - наприклад, шаблон ітератора, вбудований в C # з foreachключовим словом.

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

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

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

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

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

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

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

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

ти їх використовуєш?

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

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

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

чи ви (програмісти) шукаєте шаблони

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

де я маю шукати btw?

Оскільки ви студент, ви, мабуть, не бачили типових проблем, які надихають дизайнерські зразки. Настійно рекомендую поглянути на шаблони дизайну Head First . Вони спочатку представляють проблему дизайну, а потім показують, як певна модель може її вирішити / уникнути.

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

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

Не шукайте модності

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

Можливо, ви вже використовуєте шаблон дизайну, який ще не був винайдений / уточнений.

Не намагайтеся ними користуватися, намагайтеся думати в їхніх термінах

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

Пам’ятайте, що в проектній схемі моделей дизайну є типова проблема, яку можна вирішити, ви навіть можете комбінувати схеми дизайну для вирішення інших великих проблем. Це своєрідно типово для сервісно-орієнтованих архітектур, дивіться лише деякі з моделей SOA, які вони є .

Шукайте їх у дикій природі

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

Існують і інші шаблони, такі як шаблони даних, наприклад, використовувався лише проект Doctrine Project, схема активного запису (1.x), модель менеджера об'єктів (2.x), одиниця роботи , сховище , об’єкт запиту , відображення метаданих , дані картографування та інші, більш загальні, такі як шаблон стратегії та шаблон декоратора .

Просто так багато цікавих рішень вибрати. Дивіться "Шаблони архітектури підприємства" Мартіна Фаулера , також є моделі моделей даних .

Просто навчіться їх, коли настане час

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

Стати архітектором

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

Я близько 7 років програмував на C ++ і вивчав схеми близько 2 років тому. Більшість моделей, ймовірно, мають деякі програми, але в моєму використанні деякі краще, ніж інші. Ви повинні подумати, чому ви їх використовуєте.

Шаблон ітератора насправді зробив мій код більш заплутаним і додав зайвої складності. Я можу отримати таку ж ремонтопридатність, використовуючи typedefs для типів вектора STL. І будь-які зміни, які я вношу до повторення класу, я також повинен внести до класу ітераторів.

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

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

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

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

Додавання до Lunivore. Мені подобається цитувати це з головної книги

        ## **Three steps to great software** ##     

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

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

Чи справді їх використовує більшість програмістів?

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

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

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

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

А також, чи ви (програмісти) шукаєте шаблони (де я повинен шукати btw?), Коли ви починаєте розробку? Якщо так, то це, звичайно, звичка, яку я повинен почати сприймати.

Іноді, коли я бачу один і той же код знову і знову, я можу знайти спосіб перефабрикувати код у шаблон або, якщо я запам'ятаю рішення подібної проблеми, пов’язаної з шаблоном, я вийму його та використаю. Шаблони дизайну Head First мають декілька моделей, тоді як Refactoring - це пропозиція щодо методів кодування, які можуть привести до пошуку різних моделей. Якщо вам потрібна інша можлива відправна точка, перегляньте «Шаблони та практики Microsoft» .

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

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

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