Какви са моделите на дизайна

Бит спомени от младостта си

Когато бях в университета, са били обучавани в един от курсовете на моделите на дизайна. По това време, те ми се струваше нещо като сферичен кон във вакуум, защото опитът на прилагането им, имах (това е третият или началото на четвъртата година, преди много години). Не забравяйте, кой кой е, също е доста трудно, да не говорим за тънкостите и детайлите. Въпреки това, въпроси за моделите на дизайна помолени безпроблемно на всеки интервю за работа. Кандидатите трябваше да издуват бузи и да докаже колко е готино различни шаблони (особено Singleton), като ги видя в живота на не повече от веднъж или два пъти на страниците на книгите.







Но не и глупави хора са дошли с моделите на дизайна:

След това продължете с историческите записи няма смисъл. Това е първата книга, от които нашето поколение привлече познанията си в областта на моделите на дизайна и се опита да ги прилага в работата си. Той се смята за класика в този въпрос, и се изисква четене.

След известно време на работа, аз започнах да забелязвам, че дори и теоретични познания по дизайн модели, за да ми помогне да се разбере кода на някой друг е много по-бързо. Това е особено важно в началото на кариерата си, когато трябва да се рови в съществуващите проекти без опит. Например, среща на класа със съставителя на наставка, разбрах, че тя добавя към опростяване на логиката на изграждане и изолиране на сложни обекти. Веднага му беше лесно да го използвате и да използвате в кода си. През представителите на модела Сингълтън се разпаднаха, да се направи грешка по време на подготовката за работа са толкова лесни без знанието на правилата. В кода, с които съм работил, щедро се срещна Фасадна, Посетителски, веригата на отговорност, Итераторът, адаптер, декоратор, Proxy, Стратегии, Шаблон метод, както и други популярни модели дизайн.

И как без шаблони?

С течение на времето ... Аз бързо свикнах с широко разпространеното използване на шаблони за дизайн и стана трудно да се работи без тях. Аз започнах да разбирам какво интервюто кандидатите се изисква за тях (разбира се, ако не просто "за показ"). Тук дори не е задължително дизайн модели за кандидатстване, както и за улесняване на комуникацията между разработчици. И това е процес, който е от ключово значение за развитието - обсъждане на архитектурата и дизайна на конкретно решение.

Първият важен параметър - времето, което е прекарал в обсъждане и вземане на решения (Надявам се, че не приемаме решения един брадат Старши Старши Global Каталог софтуерен архитект). Представете си колко трудно би било бързо, за да обясни на някой, какво е необходимо за реализиране на декоратор: «Ние трябва да се направи клас, който ще даде на дизайнера копие на друга реализация на същия интерфейс, както и че ще добави логика да се обадя тези методи без да се променя основния си поведение. "Но дори и зад кулисите са един куп малки неща и нюанси. И това е за малки части от дизайна, които в по-голямата част от десетки решения, или дори стотици. Ние дори не докосвайте сложни и сериозни архитектурни модели.







На примера на декоратор е лесно да се разбере, вторият важен параметър - едно и също разбиране на проектирането решаването на проблема в съзнанието на всички членове на екипа. Когато замъгляване думи всеки може да разбере решението по различни начини, но е изпълнен с проблеми. В крайна сметка, на изпълнението може да бъде много различен от идеите, които се обсъждат. Това ще доведе до допълнително време в кода за преглед и преработена суровина.

Третият важен параметър - разбирането на работата на трети страни, инструменти и библиотеки. В момента почти всеки проект използва много решения на трети страни. За да ги използвате правилно и да не стъпи на гребло, архитект и разработчикът трябва да се разбере как работи. За тази цел, добре познат модели, които имат за цел да опрости значително разбирането и в сравнение с алтернативни решения.

В живота, ние активно се използват примери, за да се опишат ситуации, обекти и дейности. За да се обясни на някой какво понятие, ние се основават на общоизвестни и изграждане на примери за това. "Същото като здравословен Боб", "както и трудно след 5 km бягане", "лошо, колкото махмурлук", "кисел като лимон" и т.н. Ние използваме такива изрази в речта си постоянно и дори не го забелязват. За нас, прилагането им е по-лесно от подробното описание и позволява на слушателя да се разбере по-добре.

Следващото ниво

Ако забележите, че не се опитвате да си спомни подробности за изпълнението на шаблона за дизайн, но може просто да предостави подробности за приложението му в собствените си думи, че сте надраснали ниво Шу в добре познатия източната философия Shuhari (бях отдавна пише за неговата приложимост към Agile подходи и практики) , На нивото на Шу просто следвайте шаблона и не могат да осъзнаят ползата от тях, финес и въздействие. На нивото на Ха, че всички сте наясно и може съзнателно да се откаже от някои модели, критикувайки решенията, базирани на тях, да промени някои шаблони за конкретна ситуация и контекст.

Ние харесваме едно и също ниво на РИ. На това ниво, което изобщо да спре да мисли за използването на шаблони. Решения се раждат по естествен начин, въз основа на своите знания и умения, които сте натрупали през годините. Някъде задаващата някои шаблони някъде на собствената си работа, която се превръща в образец за вас в този контекст. В главата ми спрете да работите по веригата "на шаблона към разтвор" и само "от решението за шаблона". След това, вместо въпроси за конкретните модели дизайн в интервюто, и да отидете, за да отворите въпроса за приложимостта на този инструмент и примери от реалния живот ...

заключение

шаблони за дизайн - е един от инструментите за разработчици, които му помагат да се спести време и да направи по-добро решение. Подобно на всеки друг инструмент в ръцете на това може да донесе много ползи, но в друга - само една болка. Опитах се да предам на примерите, които ще ви даде специфични дизайнерски модели и как да мислят за това. Надявам се, че го е направил ...

Послепис На един от обучения похвалиха книга за шаблони за дизайн за начинаещи «Head First Design Patterns». Лично той не го прочете, защото доста усвоили темата от други източници и ненадежден почерпка този формат книги.