Նախագծման ձևանմուշներ
Նախագծման ձևանմուշները ծրագրային ապահովման ճարտարագիտության մեջ համարվում են բազմակի օգտագործման լուծումներ հաճախակի հանդիպող խնդիրների համար։ Նախագծման մոդելը ավարտուն դիզայն չէ, որ կարելի է վերցնել ու օգտագործել ելակետային կամ մեքենայական կոդերի մեջ։ Դա լոկ նկարագրություն է կամ մոդել, թե ինչպես կարելի է լուծել խնդիրը տարբեր իրավիճակների դեպքում։ Ծրագրեր կամ համակարգեր նախագծելիս մոդելների օգտագործումը համարվում է լավագույն պրակտիկա։
Որպես կանոն օբյեկտ կողմնորշված նախագծման մոդելները ցույց են տալիս դասերի և օբյեկտների փոխհարաբերությունները՝ առանց նշելու նախագծին մասնակցող դասերի կամ օբյեկտների վերջավոր թիվը։ Օբյեկտ կողմնորշված ծրագրավորման մեջ կիրառություն չունեն այն մոդելները, որոնք ունեն փոփոխական վիճակներ։
Նախագծման մոդելները տեղադրվում են մոդուլների և փոխկապվածությունների շրջաններում։ Ավելի բարձր մակարդակներում կիրառում են ճարտարապետական մոդելները, որոնք չափերով ավելի մեծ են և սովորաբար նկարագրում են պատկերի ամբողջ տեսքը իրեն հետևող համակարգերով[1]։
Նախագծման մոդելները բաժանվում են հետևյալ դասերի.
- Ալգորիթմական մարտավարության մոդելներ, կիրառություն ունի բարձր մակարդակներում ծրագրերի բնութագրերի մարտավարությունը նկարագրելու համար։
- Հաշվողական նախագծման մոդելներ, բանալիների (key) նույնականացման հաշվարկների համար։
- Կատարողական մոդելներ, ծրագրերի կատարման աջակցման, այդ թվում խնդիրների հոսքերի կատարման մարտավարության և խնդիրների սինխրոնիզացման համար նակատեսված բլոկների կառուցման համար։
- Իրականացման մարտավարության մոդելներ, Ելակետային կոդի աջակցման համար։
- Կառուցվածքային նախագծման մոդելներ, բարձր մակարդակի ծրագրերի կառուցվածքների հետ կապված խնդիրների լուծման համար։
Պատմություն
խմբագրելՄոդելները որպես ճարտարապետական հասկացողություն առաջին անգամ ծագել է Քրիստոֆեր Ալեքսանդրի (1977/79) կողմից։ 1987 թ.-ին Քենտ Բեքը և Ուորդ Կանինգհեմը սկսեցին փորձեր կատարել մոդելները ծրագրավորման ոլորտում օգտագործելու համար և նույն թվականին իրենց արդյունքները ներկայացրեցին OOPSLA կոնֆերանսին[2][3]։ Հաջորդ տարիներին Բեքը, Կանինգհեմը և այլք հետևում էին այս գործին։
Նախագծման մոդելները ինֆորմատիկայի մեջ կիրառություն գտավ Նախագծման մոդելներ. Օբեյկտ կողմնորոշված ծրագրավորման մեջ բազմակի օգտագործման տարրեր գրքի հրատարակումից հետո, որը լույս տեսավ 1994 թ.-ին։ Գրքի հեղինակները չորս հոգի են և իրենց անվանում են "Gang of Four" (հայերեն՝ Չորսի բանդա), որի պատճառով էլ գիրքը հաճախ անվանում են "GoF" (հայերեն՝ ԳօՖ)։ Այդ նույն տարում տեղի ունեցավ առաջին "Ծրագրավորման լեզուների մոդելներ" կոնֆերանսը, իսկ հաջորդ տարում "Portland Pattern Repository", որը զբաղվում էր ծրագրավորման մոդելների փաստագրումներով։
Նախագծման մոդելներին նվիրված հիշարժան գրքերը հետևյալն են.
- Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.
{{cite book}}
: CS1 սպաս․ բազմաթիվ անուններ: authors list (link) - Buschmann, Frank; Regine Meunier; Hans Rohnert; Peter Sommerlad (1996). Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons. ISBN 0-471-95869-7.
- Schmidt, Douglas C.; Michael Stal; Hans Rohnert; Frank Buschmann (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 0-471-60695-2.
- Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0-321-12742-6.
- Hohpe, Gregor; Bobby Woolf (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN 0-321-20068-3.
- Freeman, Eric T; Elisabeth Robson; Bert Bates; Kathy Sierra (2004). Head First Design Patterns. O'Reilly Media. ISBN 0-596-00712-4.
Չնայած նրան, որ նախագծման մոդելները երկար տարիներ կիրառություն ունեին, բայց պահանջվեց մի քանի տարի դրանց սահմանման և դասակարգման համար[4]։
Պրակտիկա
խմբագրելՆախագծման մոդելները, արդեն իսկ թեսթավորված լինելով հանդերձ, կարող են արագացնել ծրագրի նախագծման պրոցեսը[5]։ Բացի այդ նման մոդելների օգտագործումը ծրագրի կոդը դարձնում են ավելի ընթեռնելի և ճարտարապետական տեսանկյունից ավելի պարզ բոլոր այն ծրագրավորողների համար, ովքեր արդեն իսկ ծանոթ են նախագծման մոդելներին։
Ըստ սահմանման, ամեն մի ծրագրի մեջ նախագծման մոդելները պետք է ենթածրագրավորվեն։ Որոշ հեղինակներ դա դիտարկում էին որպես ավելորդ քայլ, քանի որ նախագծման մոդելներ օգտագործելիս անընդհատ վերասահմանման խնդիր էր առաջ գալիս։ Դրա համար Մեյերը և Արնոութը նախագծման մոդելների երկու երրորդը մասնակի կամ ամբողջական տեսքով ենթարկեցին կոմպոնենտիզացման[6]։
Նախագծման մոդելները ապահովում են ընդհանուր լուծումներ, նրանք փաստաթղթավորված են և կապված չեն կոնկրետ խնդրի հետ։
Կառուցվածք
խմբագրելՆախագծման մոդելները բաղկացած են մի քանի բաժիններից։ Հատուկ ուշադրության են արժանի Կառուցվածք, Մասնակիցներ և Համագործակցություն բաժինները։ Այս բաժինները նկարագրում են «նախագծի եղանակ», որ ծրագիր ստեղծողը կարող է պատճենել և հարմարեցնել իր ծրագրի կոդում, մոդելում նկարագրված խնդիրը լուծելու համար։ Միկրոճարտարապետությունն իրենից ներկայացնում ծրագրային բաղադրիչների (օրինակ դասեր, մեթոդներ և այլն) հավաքածու և փոխհարաբերություններ միմյանց միջև։
Նախագծողներն նախագծման մեթոդն իրենց ծրագրերում կիրառում են միկրոճարտարապետության նախատիպը ներդնելով։ Դա իր հերթին նշանակում է, որ տվյալ կոնստրուկցիայում միկրոճարտարապետությունը կունենա այնպիսի կառուցվածք և կազմավորում, որը բնորոշ է ընտրված մեթոդի եղանակին։
Դոմեին-բնորոշ մոդելներ
խմբագրելՁեռնարկվել է անգամ դոմեին բնորոշ նախագծման մոդելների նախագծումը։ Մոդելներում կիրառություն են գտել ինչպես հին, այնպես էլ նոր նախագծման մոդելներ։ Մոդելներն իր մեջ ընդգրկում են օգտագործման ինտերֆեյսի[7] ինֆորմացիայի վիզուալիզացման[8], նախագծի անվտանգության[9], "անվտանգության օգտագործման"[10], Web նախագծերի[11] և բիզնես նախագծերի[12] մոդելներ։
Դասակարգում
խմբագրելՆախագծման կաղապարներն ի սկզբանե բաժանվել են հետևյալ դասերի. Ստեղծող ձևանմուշներ, կառուցվածքային նախագծման ձևանմուշներ և վարքագծային ձևանմուշներ։ Մյուս դասակարգումն ներառում էր նախագծման ճարտարապետական ձևանմուշի հասկացությունը, որը կարող է կիրառվել ծրագրային ապահովման ճարտարապետական մակարդակի վրա, որպիսին է օրինակ ձևանմուշի ներկայացման վերահսկումը։
Անուն | Բնագիր անվանում | Նկարագրություն | Նախագծման կաղապարներ | Code Complete[13] |
---|---|---|---|---|
Աբստրակտ ֆաբրիկա | Abstract factory | Ապահովում է ինտերֆեյս կապված կամ կախյալ օբյեկտների ընտանիք ստեղծելու համար առանց նշելու վերջիններիս կոնկրետ դասը։ | ||
Կառուցող | Builder | Բարդ օբյեկտի կառուցվածքը բաժանում է վերջինիս ներկայացումից՝ թույլ տալով իրականացնել կառուցման մեթոդներ տարբեր ներկայացումների համար։ | Ոչ | |
Ֆաբրիկային մեթոդ | Factory method | Տալիս է ինտերֆեյս մի օբյեկտ ստեղծելու համար, բայց թույլ է տալիս որոշել, թե որ ենթադասը կարելի է ներառել (անգլ.՝ instantiate)։ | ||
Ծույլ բեռնում | Lazy initialization | Մարտավարություն, նոր օբյեկտների ստեղծումը, խնդիրների լուծումը կամ ավելի թանկարժեք պրոցեսը հետաձգելու համար, քանի այն անհրաժեշտ չէ։ Այս ձևանմուշն առաջին անգամ հայտնվել է ԳօՖի ցուցակում Վիրտուալ Պրոքսի անվան տակ։ | Ոչ | Ոչ |
Բազմակի օգտագործման | Multiton | Դասն ունի միայն անուններով նմուշներ և ապահովում է գլոբալ հասանելիություն բոլոր նմուշներին։ | Ոչ | Ոչ |
Օբյեկտների ավազան | Object pool | Խուսափում է նոր միջոցների և ռեսուրսների հատկացումից ի հաշիվ չօգտագործվող օբյեկտների վերաշրջանառման։ Այն համարվում է կապակցող ավազան և Հոսքերի ավազան ձևանմուշների ընդհանրացումը։ | Ոչ | Ոչ |
Նախատիպ | Prototype | Նոր օբյեկտները թույլ է տալիս ստեղծել նախօրոք սահմված նախատիպը պատճենելով։ | Ոչ | |
Ռեսուրսի ստանալը ինիցիալիզացիա է | Resource acquisition is initialization | Հավաստիանում է, որ ռեսուրսները հարկ եղած ձևով ազատվում են՝ ռեսուրսները կապելով համապատասխան օբյեկտների կյանքի տևողության հետ։ | Ոչ | Ոչ |
Եզակի օգտագործման | Singleton | Հավաստիանում է, որ դասը օբյեկտի միայն մի օրինակ ունի և ապահովում է գլոբալ հասանելիություն դեպի այն։ |
Անվանում | Բնագիր անվանում |
Նկարագրություն | Նախագծման կաղապարներ | Code Complete[13] |
---|---|---|---|---|
Ադապտեր | Adapter or Wrapper or Translator | Դասի ինտերֆեյսը փոխարկում է այլ ինտերֆեյսի, որը սպասում են օգտագործողները (անգլ.՝ client)։ Ադապտերը թույլ է տալիս իրարից տարբեր ինտերֆեյսներ ունեցող դասերին աշխատել միասին։ Ինտեգրացման մեկ այլ եղանակ է թարգմանիչ ձևանմուշների օգտագործումը։ | ||
Կամուրջ | Bridge | Աբստրակցիան անջատում է իրականացումից՝ թույլ տալով որ դրանք լինեն միամյանցից գրեթե ազատ։ | ||
Կազմող | Composite | Թույլ է տալիս ստեղծել ծառատիպ օբյեկտներ հիերարխիան պատկերելու համար։ Կազմողը թույլ է տալիս օգտագործողներին տրամադրել առանձին օբյեկտներ և կազմում է միատեսակ օբյեկտներ։ | ||
Դեկորատոր | Decorator | Դինամիկ կերպով օբյեկտի ինտերֆեյսը պահպանելով օբյեկտին կապակցում է նոր պարտականություններ։ Դեկորատորները ապահովում են ճկուն այլընտրանք դասերի ֆունկցինալությունն ընդլայնելու համար։ | ||
Ճակատ | Facade | Միասնական ինտերֆեյս է ապահովում ենթահամակարգի բոլոր օրինակների համար։ Ճակատը սահմանում է բարձր մակարդակի ինտերֆեյս, որը հեշտացնում ենթահամակարգի օգտագործումը։ | ||
Հարմարեցնող | Flyweight | Օգտագործում է բաշխում՝ մեծ քանակով նմանատիպ օբյեկտների հետ արդյունավետ աշխատելու համար։ | Ոչ | |
Ճակատը հսկող ձևանմուշ | Front Controller | ձևանմուշը վերաբերվում է Web ծրագրերին։ Այն ապահովում է կենտրոնացված մուտք հարցումներին պատասխանելու համար։ | Ոչ | |
Մոդուլ | Module | Մի քանի իրար հետ փոխկապակցված էլեմենտներ, դասեր, միայնակներ հանդես են գալիս մեկ կոնցեպտուալ միավորով։ | Ոչ | Ոչ |
Պրոքսի | Proxy | Օբյեկտին տալիս է փոխարինող կամ լրացնող, որպեսզի կարողանա ղեկավարել վերջինիս հասանելիությունը։ | Ոչ | |
Եկվորյակ[14] | Twin | Թույլ է տալիս ձևանմուշավորել բազմաթիվ ժառանգումներ ծրագրավորման լեզուների մեջ, որոնք չեն սպասարկում տվյալ ֆունկցիան։ | Ոչ | Ոչ |
Անուն | Բնագիր անվանում | Նկարագրություն | Նախագծման կաղապարներ | Code Complete[13] |
---|---|---|---|---|
Գրատախտակ | Blackboard | Ընդհանուր դիտորդ, որը թույլ է տալիս բազմաթիվ ընթերցողներ (readers) և գրողներ (writers). Ինֆորմացիան տարածում է ողջ համակարգով մեկ։ | Ոչ | Ոչ |
Պարտականությունների շղթա | Chain of responsibility | Թույլ է տալիս, որ ուղարկված հարցումը վերաբերվի մեկից ավելի օբյեկտների։ Հարցումը այնքան ժամանակ կմնա շղթայի մեջ, մինչև որ օբյեկտներից մեկը կանդրադառնա նրան։ | Ոչ | |
Հրաման | Command | Հարցումն ինկապսուլացիա է անում օբյեկտի տեսքով՝ թույլ տալով հաճախորդներին կատարել զանազան հարցումներ, որոնք ընկնում են հերթի մեջ։ Սպասարկում է նաև գործողությունների չեղարկում (undo)։ | Ոչ | |
Թարգմանիչ | Interpreter | Ընտրում է այն լեզուն, որը համապատասխանում է տվյալ նախադասության ներկայացմանը։ | Ոչ | |
Իտերատոր | Iterator | Հերթականությամբ հասանելիություն է ապահովում օբյեկտների բազմության՝ առանց վնասելու դրանց ներկայացումները։ | ||
Միջնորդ | Mediator | Որոշում է այն օբյեկտը, որն ինկապսուլյացիա է եղել որպես փոխազդող օբյեկտների բազմություն։ Միջնորդը թույլ է տալիս թուլացնել օբյեկտների միջև կապերը, օբյեկտների միմյանց հետ փոխգործակցությունը մեզ թողնելով։ | Ոչ | |
Պահպանող | Memento | Առանց ինկապսուլյացիան խախտելու, թույլ է տալիս օբյեկտին ավելի ուշ վերականգնել իր նախկին վիճակը։ | Ոչ | |
Զրոյական օբյեկտ | Null object | Լռելյայն(by default) արժեքով օբյեկտներ տրամադրելով խուսափում է զրոյական հղումներից։ | Ոչ | Ոչ |
Դիտորդ | Observer or Publish/subscribe | Որոշում է մեկ օբյեկտի կախվածություն մի քանիսից, որտեղ մի օբյեկտի վիճակի փոփոխությունը ազդում է մյուս օբյեկտների վրա և ավտոմատ կերպով թարմացնում դրանք։ | ||
Ծառայող | Servant | Որոշում է ընդհանուր ֆունկցիոնալություն դասերի խմբի համար։ | Ոչ | Ոչ |
Հատկորոշում | Specification | Իրենից ներկայացնում է բիզնես տրամաբանության և Բուլյան հանրահաշիվի մեթոդների վերադրումը։ | Ոչ | Ոչ |
Վիճակ | State | Թույլ է տալիս օբյեկտին փոխել իր վարքը երբ փոխվում է նրա ներքին ներկայացումը։ | Ոչ | |
Մարտավարություն | Strategy | Որոշում է ալգորիթմների խմբեր, ինկապսուլյացիա է անում դրանք և դրանք դարձնում է համափոխարինելի։ Մարտավարությունը թույլ է տալիս հաճախորդներից (clients) անկախ օգտագործել ալգորիթմները։ | ||
Կաղապարային մեթոդ | Template method | Որոշում է գործողության ժամանակ ալգորիթմի կմախքը՝ որոշ քայլեր թողնելով ենթադասերի վրա։ Կաղապարային մեթոդը թույլ է տալիս ենթադասերին որոշել ալգորիթմների որոշ քայլեր՝ առանց ալգորիթմի կառուցվածքը փոփոխելու։ | ||
Այցելող | Visitor | Իրենից ներկայացնում է գործողություն, որը պետք է իրականանա օբյեկտային կառուցվածքի էլեմենտների վրա։ Այցելողը թույլ է տալիս որոշել նոր գործողություն՝ չփոփոխելով դասերի էլեմենտները, որի նկատմամբ ինքն իրականացնում է գործողություն։ | Ոչ |
Անվանում | Բնագիր անվանում |
Նկարագրություն | Pattern-Oriented Software Architecture[15] |
---|---|---|---|
Ակտիվ օբյեկտ | Active object | Որոշում է կանչվող մեթոդի ֆունկցիայի աշխատանքը, որոնք գտնվում են իրենք իրենց վերահսկման հոսքի մեջ։ Նպատակը ասինքրոն կանչի մեթոդի և հարցումների մշակումը՝ պլանավորողի միջոցով զուգահեռացում մտցնելն է։ | |
Հենվող | Balking | Օբյեկտի նկատմամբ գործողություն իրականացնում է այն դեպքում, երբ օբյեկտը գտնվում է որոշակի մասնավոր վիճակում։ | Ոչ |
Կապակցող հատկանիշներ | Binding properties | Մի քանի դիտորդներին միացնում է իրար տարբեր օբյեկտների վերահսկումը սինքրոնիզացնելու և կոորդինացնելու համար[16]։ | Ոչ |
Մեկուսացում կրկնակի ստուգումով | Double checked locking | Քչացնում է կողպեքավորման համար պահանջվող ավելորդ ռեսուրսների օգտագործումը, եթե հնարավոր չէ այն ամբողջությամբ բացառել։
Որոշ լեզուների և սարքերի համար այս ձևանմուշը կարող է վատ հետևանքներ թողնել։ Երբեմն այս եղանակն անվանում են անտիձևանմուշ։ |
|
Դեպքից կախված ասինքրոն | Event-Based Asynchronous | Անրադառնում է բազմահոսքային ծրագրերի խնդիրների ասինքրոնիզացմանը[17]։ | Ոչ |
Պահպանվող կախոց | Guarded suspension | Վերահսկում է, որ մինչ օբյեկտի նկատմամբ գործողություն կատարվելը, այն կողպեքավորվի և համապատասխանի պահանջներին։ | Ոչ |
Ռեգիստրացնող | Join | Ռեգիստրացնող ձևանմուշն իրենից ներկայացնում է միաժամանկյա, զուգահեռ և բաշխիչ ծրագրերի միջով ստացված հաղորդագրությունը տեղափոխելու ձևանմուշ։ Ի տարբերություն հոսքերի (threads) և կողպեքներ, այս սա բարձր մակարդակի ծրագրավորման ձևանմուշ է։ | Ոչ |
Կողպեքավորող | Lock | Հոսքերից մեկը "կողպեք" է դնում ռեսուրսի վրա՝ կանխելով մյուս հոսքերի կողմից վերջինիս հասանելիությունը կամ փոփոխությունը[18]։ | Ոչ |
Հաղորդագրությունների | Messaging pattern | Թույլ է տալիս կատարել ինֆորմացիայի (հաղորդագրության) փոխանակում բաղադրիչների և ծրագրերի միջև։ | Ոչ |
Վերահսկվող | Monitor | Օբյեկտ, որի մեթոդները կարող են լինել փոխադարձ անջատող (mutex), միևնույն ժամանակ արգելելով մյուս օբյեկտների սխալմամբ կանչերով օգտագործումը։ | |
Ապագործող | Reactor | Ապահովում է ասինքրոն ինտերֆեյս ռեսուրսներին, որոնք պետք է մշակման ենթարկվեն սինքրոն կարգով։ | |
Ընթերցողներ-գրողի կողպեք | Read/write lock | Թույլ է տալիս միաժամանկյա գրելու հասանելիություն օբյեկտի համար, բայց պահանջում է բազմադաշտային գործողություններ գրման գործողության համար։ | Ոչ |
Պլանավորման | Scheduler | Բացահայտ կերպով վերահսկում է, թե երբ հոսքերը կարող են կատարել միահոսք կոդ։ | Ոչ |
Հոսքերի ավազան | Thread pool | Մի քանի խնդիրներ իրականացնելու համար ստեղծվում են հոսքեր, որոնք սովորաբար իրականացվում են հերթերի տեսքով։ Որպես կանոն խնդիրներն ավելի շատ են լինում, քան հոսքերը։ Այս ձևանմուշը կարելի է դիտարկել որպես ավազանային կաղապարի մասնավոր դեպք։ | Ոչ |
Հոսքերի լոկալ հիշողություն | Thread-Specific Storage | Լոկալ հոսքի (thread) համար տեղադրում է ստատիկ կամ գլոբալ հիշողություն։ |
Ծանոթագրություններ
խմբագրել- ↑ Martin, Robert C. «Design Principles and Design Patterns» (PDF). Վերցված է 2000-ին.
- ↑ Smith, Reid (1987 թ․ հոկտեմբեր). «Panel on design methodology». doi:10.1145/62138.62151.
{{cite web}}
: Missing or empty|url=
(օգնություն); Unknown parameter|book-title=
ignored (օգնություն); Unknown parameter|conference=
ignored (օգնություն), "Ward cautioned against requiring too much programming at, what he termed, 'the high level of wizards.' He pointed out that a written 'pattern language' can significantly improve the selection and application of abstractions. He proposed a 'radical shift in the burden of design and implementation' basing the new methodology on an adaptation of Christopher Alexander's work in pattern languages and that programming-oriented pattern languages developed at Tektronix has significantly aided their software development efforts." - ↑ Beck, Kent; Ward Cunningham (1987 թ․ սեպտեմբեր). «Using Pattern Languages for Object-Oriented Program». Վերցված է 2006 թ․ մայիսի 26-ին.
{{cite web}}
: Unknown parameter|book-title=
ignored (օգնություն); Unknown parameter|conference=
ignored (օգնություն) - ↑ Baroni, Aline Lúcia; Yann-Gaël Guéhéneuc and Hervé Albin-Amiot (2003 թ․ հունիս). «Design Patterns Formalization» (PDF). Nantes: École Nationale Supérieure des Techniques Industrielles et des Mines de Nantes. Վերցված է 2013 թ․ փետրվարի 19-ին.
- ↑ Judith Bishop. «C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems». C# Books from O'Reilly Media. Վերցված է 2012 թ․ մայիսի 15-ին. «If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.»
- ↑ Meyer, Bertrand; Karine Arnout (2006 թ․ հուլիս). «Componentization: The Visitor Example» (PDF). IEEE Computer. Institute of Electrical and Electronics Engineers. էջեր 23–30. doi:10.1109/MC.2006.227.
- ↑ Laakso, Sari A. (2003 թ․ սեպտեմբերի 16). «Collection of User Interface Design Patterns». University of Helsinki, Dept. of Computer Science. Արխիվացված է օրիգինալից 2008-02-21-ին. Վերցված է 2008 թ․ հունվարի 31-ին.
- ↑ Heer, J.; M. Agrawala (2006). «Software Design Patterns for Information Visualization». IEEE Transactions on Visualization and Computer Graphics. 12 (5): 853–60. doi:10.1109/TVCG.2006.178. PMID 17080809.
- ↑ Chad Dougherty; և այլք: (2009). Secure Design Patterns (PDF).
{{cite book}}
: Explicit use of et al. in:|author=
(օգնություն); Invalid|no-pp=Technical Report
(օգնություն) - ↑ Simson L. Garfinkel (2005). Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable.
{{cite book}}
: Invalid|no-pp=PhD Thesis
(օգնություն) - ↑ «Yahoo! Design Pattern Library». Արխիվացված է օրիգինալից 2008 թ․ փետրվարի 29-ին. Վերցված է 2008 թ․ հունվարի 31-ին.
- ↑ «How to design your Business Model as a Lean Startup?». Վերցված է 2010 թ․ հունվարի 6-ին.
- ↑ 13,0 13,1 13,2 McConnell, Steve (2004 թ․ հունիս). «Design in Construction». Code Complete (2nd ed.). Microsoft Press. էջ 104. ISBN 978-0-7356-1967-8. «Table 5.1 Popular Design Patterns»
- ↑ «Twin – A Design Pattern for Modeling Multiple Inheritance» (PDF).
- ↑ Schmidt, Douglas C.; Michael Stal; Hans Rohnert; Frank Buschmann (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 0-471-60695-2.
- ↑ Binding Properties
- ↑ Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, and Morgan Skinner (2008). «Event-based Asynchronous Pattern». Professional C# 2008. Wiley. էջեր 570–571. ISBN 0-470-19137-6.
{{cite book}}
: CS1 սպաս․ բազմաթիվ անուններ: authors list (link) - ↑ Lock Pattern