Patterns2015
.pdfМинистерствообразованиянаукиРФ Федеральноегосударствеобразовательноебюджетн
учреждениевысшегопрофессиональногообразования Алтайскийгосударствтехническийуниверситетнный
им.И..Ползунова
КрючковаЕ.Н. Старолетов.М.
Архитектурноепроектированиепаттерны программирования
Учебнометодическоепособие длястудентовнаправления231000.62
«Программнаяинженерия»
Барнаул2015
КрючковаЕ.Н. |
, Старолетов.М. |
Архитектурнпроектирпаттеование |
рны |
||
программирования: Учебно-методическое пособие. |
— Барнаул:АлтГТУ, 2015 |
. – 109c. |
|||
Учебно-методическоепос свящархитектурномубиепроективсферованиюе |
|
|
|
||
программобеспечениболееизатрагчастоиваетяспользуемыепрограммной |
|
|
|
|
|
инженериипатт |
ерны (шаблоны) |
программирования.Приобученииприменяетсяпроблемно |
- |
||
ориентирподх.Пособиепредванныйдназначеностудентовля |
|
|
|
направления231000.62 |
|
«Программнаяинженерия» |
. |
|
|
|
|
(с)АлтГТУ, 2015
2
Содержание |
|
|
|
|
|
|
Введение ............................................................................................................................................ |
|
|
|
|
|
4 |
1Диаграммаклассов |
|
|
......................................................................................................................... |
|
|
4 |
2Анализкода( |
|
code review) ........................................................................................................... |
10 |
|||
2Критерии.1 ,котмоиспрыежноприанализельзкодавть |
.............................................. |
10 |
||||
2Пример.2анализастуденческогокодадругими |
студентами ............................................... |
12 |
||||
3Базовыешаблоныпроектирования |
|
............................................................................................ |
18 |
|||
3Что.1такое |
|
GoF и GRASP ...................................................................................................... |
18 |
|||
3Классификац.2 шаблпроектновирования ........................................................................ |
20 |
|||||
3Делегир.3 |
ование( |
Delegation) .................................................................................................. |
21 |
|||
3Модель.4событий,основанннаделегатах( я |
|
Delegation Event Model) ............................. |
28 |
|||
3Заместитель.5 ( |
|
Proxy)............................................................................................................... |
28 |
|||
3Зад.6краниязделу3 |
|
|
|
............................................................................................................... |
31 |
|
4Структуршаблоные |
|
|
|
................................................................................................................ |
32 |
|
4.1 Адаптер( |
Adapter) |
.................................................................................................................. |
32 |
|||
4Декоратор.2 объектовилиОбертка( |
|
|
Decorator или Wrapper) .............................................. |
36 |
||
4Мост.3( |
Bridge) ......................................................................................................................... |
|
|
40 |
||
4Компоновщик.4 ( |
|
Composite) ................................................................................................... |
43 |
|||
4Приспособленец.5 ( |
|
Flyweight) ................................................................................................ |
46 |
|||
4Итератор.5 ( |
|
Iterator).................................................................................................................. |
49 |
|||
4Информационный.7 эксперт( |
|
Information Expert) ................................................................. |
51 |
|||
4Зад.8краниязделу4 |
|
|
|
............................................................................................................... |
52 |
|
5Порождающиешаблоны |
|
|
|
............................................................................................................. |
54 |
|
5Фабричный.2 метод( |
|
|
|
Factory method) .................................................................................... |
57 |
|
5Абстрактн.3 фабрик( ая |
|
|
Abstract factory ) ............................................................................ |
61 |
||
5Прототип.3 ( |
Prototype) ............................................................................................................. |
62 |
||||
5Строитель.4 ( |
|
Builder) ............................................................................................................... |
64 |
|||
5Одиночка.5 ( |
Singleton) ............................................................................................................. |
66 |
||||
5Пул.6объектов( |
|
Object Pool) ................................................................................................... |
68 |
|||
5Зад.7краниязделу5 |
|
|
|
............................................................................................................... |
69 |
|
6Поведенческиешаблоны |
|
|
............................................................................................................. |
70 |
||
6.1 Состояние............................................................................................................................... |
|
|
|
71 |
||
6Наблюдатель.2 ( |
Observer)........................................................................................................ |
75 |
||||
6Хранитель.3 ( |
|
Memento)............................................................................................................ |
80 |
|||
6Команда.4 ( |
|
Command).............................................................................................................. |
82 |
|||
6Посетитель.5 ( |
|
Visitor) .............................................................................................................. |
86 |
|||
6Перенаправление.6 ( |
|
Indirection).............................................................................................. |
89 |
|||
6Цепочкаобязанностей.7 ( |
|
Chain of Responsibility)................................................................. |
90 |
|||
6Посредник.8 ( |
|
Mediator) ............................................................................................................ |
92 |
|||
6Стратегия.9 ( |
Strategy)............................................................................................................... |
93 |
||||
6.10 Интерпретатор (Interpreter)................................................................................................. |
95 |
|||||
6.11 Шаблонный метод (Template Method)............................................................................... |
96 |
|||||
6.12 Контроллер (Controller)....................................................................................................... |
96 |
|||||
6.13 Искусственный (Pure Fabrication) ..................................................................................... |
96 |
|||||
6Не.14разговаривайтеснеизвестными( |
Don't talk to strangers) ........................................... |
97 |
||||
6Зад.15краниязделу6 |
|
|
|
............................................................................................................. |
97 |
|
7Концепция |
MVC........................................................................................................................... |
|
|
99 |
||
7Классический.1 |
MVC ............................................................................................................... |
99 |
||||
7.2 Понятиефреймв |
|
|
орка........................................................................................................... |
107 |
||
7.3 MVVM .................................................................................................................................. |
|
|
|
|
107 |
|
Списреколитературыкмендуемой |
|
|
........................................................................................... |
109 |
3
Введение |
|
|
|
|
|
Архитектурнинженериипроектирвпрограммнойва ие |
|
|
– частьпроцессаразработки,в |
||
которметобъмдеомктнойомпозициивыделяютсяклассыпредметнойобласти, |
|
|
|
||
определяютсяихсвязипровмоделибудущейитсяпросиваниеграммнойстемы |
|
|
|
||
использовдиаграммкласс.Тпроцекойнив обхмдляссосистемдимжных,приэтом |
|
|
|
||
сначалапроводпроектиров,толькопотомсяпишетсякод,анеаоборотие. |
|
|
|
||
Начинающиепрогр |
|
аммистыобычнопишуткодсразубезвсякпрогоектирования,что |
|
||
приводсистемыкреали,кодзациикоторойнавпислохомстиле,асасистеман |
|
|
|
||
изобилуетошибками,являетсяплохорасширяподдтакойсиемойржкасложнатемы. |
|
|
|
||
Паттерны (шабл)проектировны |
аниявпрограммнойинженерии |
– готорешениявые |
|||
сфереархитектурногопроектированияпрограммногообеспечения,которыеразработаны |
|
|
|
||
одобреныпрограммистсксообществодлярешенразлзадач.имячных |
|
|
|
||
Вданнпособмосновныераныиизвестныепаттерны, |
|
|
ричемприменяется |
||
проблемныйподход |
, |
ипаттернповозможностиопи ледующимываетсяобразом: |
|
|
|
Проблема-варешенияиант |
-диаграммаклассов |
-код-результат-преимущес/недоста. тваки |
КодприведеннаязыкеС++.
1Диаграммаклассов |
|
|
|
|
|
UML |
(Unified |
modeling |
language, унифицированныйязыкмоделирования |
) – |
|
стандартизованныйграфическийязык,созданныйдляпервоначальнпроектированияго |
|
|
|||
программобеспечениянаосновего |
|
диаграмм, |
понятныхкакпрограммист |
ам,таки |
|
заказчикам. |
|
|
|
|
|
UML диаграммаклассовсодержит |
сущности |
и отношения междуними,атакже |
|
||
комментариидругуювспомогательнуюинформаци. |
|
|
|
||
Наэтапепроектированияобычноневажно,накакомязыкепрогрдаммированиялее |
|
|
|||
будетреализованаданнаясистема, |
|
CASE средстваUMLобычнопозвпотомляют |
|
||
сгенерироватькод |
истемыинтерфейс( классовбезреализации)наыбранномязыке |
|
|
||
программированияподиаграмме. |
|
|
|
|
|
Такжевозможносгенеридиагклассоврпооватьимеющемусядеревуисходным |
|
|
|
||
кодомавтома.Одн,притакоическигенерации,какйправило,будсг нерированат |
|
|
|
||
диаграммасовсемивнутренниобъектамипромежуточныметодами, поля,что |
|
|
|
||
можетперегрузитьдиаграммуусложЦенностьеепонимание. диаграммыклассов |
тольковажныесущности |
|
|
||
том,чтонанейможнопоказать |
|
,ихсодержанисвязидругиеми |
|
||
сущностями,которыеактув атемльныкзаущей.хдачи |
|
|
|
||
|
|
|
4 |
|
|
Сущности (entity) выражаютсяклассахиинтерфейсах.Сущнмоделируютбъектысти
предметнобластимогутвп сйохранятьледствиисвоезначениебазеданных. |
|
|
|
|
|
Сущносзадаесвойствамиповедениемсяь. |
|
Свойства (илиатрибуты) |
– |
этоп ля |
|
объектаиликласса,значимыеданнойстадиипроектирования. |
|
Поведение – этометоды |
|||
классаиобъекта,которыевзаимодействудругобъектамименясостояниеют |
|
|
|
|
|
объектови сейисте.С иойстваметодыUMLдиаграм |
|
меклассов,какиООП |
|
-языках |
|
программирования,могутиметьразнуюобластьвидимости |
|
: |
|
|
|
• публичная( |
public),обозначаетсякак“+” |
, |
элементы стак ойобластьювидимости |
|
|
доступнычерезинтерфейссущностибезограничений |
|
; |
|
|
|
• скрытая(private),обозначаетсякак |
“-”, |
элементыскрытиисподльзуются |
|
|
|
внутреннихцелей; |
|
|
|
|
|
• защищенная( |
protected),обозначаетсякак“#” |
|
,элементыдоступнывэкземплярах |
|
|
классовиихпотомках. |
|
|
|
|
|
Поведен,служащиедлядоступазвнеякскрытымсвойствам,путемобъявленияетодов |
|
|
длявозвращения |
значенсвойствилустания поойствпереданномувкиновомуих |
|
значению,называются,соответственно, |
геттерами (getter) и сеттерами (setter). |
|
Преимущестакпо,вотличиехгодапубличвомдоступакосновнымсвойствамого |
|
|
класса,являетсято,чтопри |
|
озданиигеттерсеттероввозможноконтролировать |
изменениязначенийсвойствследитьзавнутреннимсостояниемкласса. |
|
Сущнможеделирсобычныйтьобъекиливапитсыватьнтерфейс. |
|
|
Интерфейс – этокласс,экземплярыкоторнесоздаются, гон |
лужитдляконтрактного |
|
описаниясвойствповедения.Впрограммобъесоздкпроизводныетыакютсяхот |
|
|
класбазовые,расширяяклассы( |
генерализация),кромеэтого,ониследоватьгутнеким |
|
интерфейсам( |
имплементировать их),т.е.обязатсодсвельноржать |
ойстваиреализовывать |
поведен,присущиезаданнымнтерфейсамя.Внекоторыхязыкахвводитсяпонятие |
|
|
абстрклассактного |
какинтерфейса,котодреыйржнекоторыхализациидля |
|
5
методов. |
В UMLабстрклобознактныйссклсаименемссомчаеткла,оформлсяса |
|
|
енный |
||
курсивом. |
|
|
|
|
|
|
Абстрактныйметод |
(обозначаетсякурсив)декларируетп мве,котдоениелжнорое |
|
|
|
||
бытьреализованоклассе |
-потомкеиливреализацииинтерфейса. |
|
|
|
||
Рассмотримдля |
примерамодельстудента( |
|
Student).Онумеетспа ь |
(sleep),есть (eat) и |
||
учиться (study).Причемэтиповедения |
берпутимплементациися |
трехин |
терфейсов, |
|||
которыеэтидействиязадают( |
|
Sleeper, Eater, Studier).П рипоявлновогодействиянии |
|
|||
достаточнобудетимплементировадругойинтерфейс.Устуденподклассаимеетсядва ь |
|
|
|
|
||
(потомка ) – бакалавримагистр.Ониреализуютпо |
|
-сводействиямуsleep,study,eat |
|
кроме |
||
этого,магистружеустнаоилсяаб,п действийтумимообычногостудента, |
|
|
|
|
||
имплеминтерфейснтирует |
Woker иреализуетметод |
work(). |
|
|
||
ДиаграммаклассовязыкаUML |
|
: |
|
|
|
Свойстваиповедениямогутпринкакобъедл,такикласжать.Впервомтуслучаедля |
|
|
|
каждоговып бъекталняющегосоздаетсяло альнаяопсвойств,иизменениеих |
|
|
|
действуеттольконаданныйобъект.Вовторомслучае, |
свойствапринадлежатвсемуклассу |
|
|
ихзнач ениядоступнывсемэкземплярамданклассанчтениеогоизм нение |
|
(следует |
|
учесть, |
чтоэтаоперацияобычнопотоконе |
безопасданныхиприводиткгон)ке. |
Методы, |
принадлежащиеклассу,могиметьдоступолькостатичесвойклассаимогуткимтв |
|
|
|
бытьв |
ызваныбезсозданияэкземпляракла.Такссавойстваиметодыназываются |
|
|
статическими.ОниобозначаютсявUMLподчеркнутойлинией. |
|
|
|
• Статическприменяюсвойстлибовкачеспоствеличинсяоянных,когда |
|
|
|
|
требуетсяобъяконсвклассеи,тнапримерьнту, |
дляпередачиосмысленного |
|
|
параводинизметодоветракл,либоссакачествебщихпердляподсчетаменных |
|
|
|
чего-то,связанногоэкземпданногол.ассаярами |
|
|
6
•Статическиеметодыпримдляреализацииняютсяшаблпроектированиянов,обычно
вслучаях,когдасо зданиеэкземпляраклассапроизводитст тичеметоде. скомя
Дляпримера |
предп,чтнекийолУниверситетожимасспревращает |
|
студентов- |
бакалавровМ |
агиприсэт,количестворыомсозданныхстранестудентовучиты ается |
|
|
путемсозданиявкластудентстатсе |
ическогополяcount. |
Введметод |
bachelor2master, |
котсонужныйздаетрыйобъект,увелчистуденслочиваетов |
-магистровуменьшаетчисло |
|
студентов-бакалавров:
Master * University::bachelor2master (Bachelor *student) {
Master * next = new Master (student);
Master::count++;
Bachelor::count---; return next;
}
Диагрклассовт позволяеткжемма |
промоделироватьосновныеотношениямежду |
|
классами,это |
: |
|
•использование;
•ассоциация;
•агрегация;
•композиция.
7
Отношение использования (<<use>>) моделируетситуацию,к |
огдавкодекакого |
-то |
||||
методаодногоклсоздаетсяссаииспользуетсяэкземплярдругого |
|
|
(впримерес |
|||
Университетом,БакалМаклврагистрамисс |
|
ниверситетиспользуетБакалавра |
и |
|||
возвращаетМ |
агистра,класс Магистримеетконструктор,принимающийБакалавра) |
|
. |
|
||
Ассоциация – в общемслучае,зависимостьмеждудвумяклассамизаданной |
|
|
|
|||
мощностью.Ассоциможетбытьаправленнойциянадиаграмме( ристрелкауется, |
|
|
|
|
||
указывающаянапр),т можкжевлимние.новаться |
|
|
|
|
||
Мощотношениясть |
– поаналогиисбазд нныхми |
|
задаетвозможноеколичество |
|
||
объектпоотнодншениювстосвязийроныкколичествуобъекдругойто,этвоны |
|
|
|
|
||
один-ко-мног,одинм |
-к-одному,много |
-ко-многимобыч( за наеняетсядвесвязиоодин |
-ко- |
|||
многимссозданиемдополнительногокласса)В. UMLприм |
|
|
еняютсятакжемощностивида |
|
||
0или..10указыв..*,нато,чтосзаданнющиесторсвязиобъектайныможетнебы ь |
|
|
|
|
||
(например,вС++указательобъектклассапосвязиможетбытьNULL) |
|
|
.К |
асаемо |
||
реализации, существуетсвязьодин |
|
-ко-мн,товклассег,им |
|
меющимнасвоейстороне |
|
|
мощность “много” |
объявляконтейнерспис( ,мнтсяи.д.жество),содержащийобъекты |
|
|
|
||
связанногоклас.Чабывает,чтобъекоторый, кладевконтейн, акжесяимеетр |
|
|
|
|
||
ссылкународительскийобъект,вэтомслучаеговорят |
|
|
|
озвратномотношении. |
|
|
Направленнаяассоциацсозданиямоделоперациюруетэкземпляракласса,т.. |
|
|
|
|
||
ассоциациястрелотобъектаАобъектуойозначаетB ,что |
|
|
“A создаетэкземпляр |
B”. |
||
Такдиаграммадляпредыдущслучаябудетболправильнойе:его |
|
|
|
|
Замечание: некоторые UML редакторы дляотображеннаправленияассоциациисуют |
|
|||
стрелкунадсамойассоциацией,рядомееописанием.Другойвариант |
|
– стрелканаконце |
||
ассоциа.Ассонецибязателнаправленнойдолжнаациябыть,т.к.говоритпрежде |
|
|
||
всего заимосвязиоднклассатноситегодругогосогласмощьнотношения. сти |
|
|
||
Агрегация – этослучайассоциации,когдатребуетсяпромоделироватьоперацию |
|
|||
включенияодногообъекдругой(тношениеацелое |
-частьцелого)Например. , |
кока-кола |
||
включаетводу |
,крас итель имножествохимическихэлементов,а |
в университет включает |
||
перподавателейистудентов |
.Отношениеагрегациирипустымуетсяромбом.При |
ер |
UML |
|
диаграммыдля |
|
университета,агрегирующего |
преподавателейистудентов |
: |
8
Композиция – случай агрегации,ко |
гдавключаемыйобъектнеможетсуществоватьсам |
|
|
|||
посебебезсвоегоконтейнераили(класса |
|
|
-родителя,класса,агрегирующегоданныйкласс). |
|
|
|
ДляC++классовэтообыозначаетчт, нодеструагрегируемогоклассаторвызываетсяпри |
|
|
|
|
|
|
вызоведеструктораагрегирующег |
|
окласса.Пример |
- объект “глаз” |
неможетсуществовать |
||
отдельнообъекта |
“человек” |
,приэтомчеловекагрегируетдваобъекта |
|
“глаз” |
,вэтом |
|
случаеговорят,чточеловекявляетсякомпдлдвухозитомбъектовглаз.НаUML |
|
|
|
|
|
|
диаграммекомпозициярисуетс |
|
|
регация,носзакромбомашенным: |
|
|
Для отрисовки диаграммыклассовнеобходимоиспольз вать |
векторныйредакторUML |
|
диаграмм. |
Вданномпособиииспользовалсякросс |
-платформенныйредакторVisual Paradigm |
for UML Community edition. |
|
9
2Анализкода( |
code review) |
|
|
|
Всовременнпрограмкоддостатмсложногоирпроектаобычнованиипишется |
|
|
||
команде.Полезнымупражнением,котповысроежеткачествокодаиуровеньть |
|
|
||
разработчика, являетсяанализчужогокода.Приэтомдругаяпараглможетнайзошибки |
|
|
||
во рганизациипр,ошибкиектакаквреализацииалгоритмовнанижнемуро,такне |
|
|
||
проектировасейистемынауроввзаинииме еждуклассамодейств,..навысокомия |
|
|
||
уровне. |
|
|
|
|
ВкомпанияхпромышленнойразрабПОтакойпросмкодаткеявляетсябычнойтр |
|
|
||
практикойприемеканаработудиоценкедаегонавы,такжеов |
|
для контроля |
||
работыразрабнапролидертахтчиком,ковасредмикндборьбысошибкамитво. |
|
|
||
Приначалезнакомствастудентовархитектурнымпроектированием |
|
собственный анализ |
||
чужого кодаиполучанализар(е)книявьюодругихдатстудентовгруппынакакой |
|
-то |
||
предыдущийпроект |
|
(курсовуюаб)п бзволиттудущемуразработчикуувидетьсвои |
|
|
чужошибкинписатьетакимобразом |
|
код далее. |
|
|
Еслииспользоватьсистемуконтверсийоля |
|
общийрепозиторий, можно |
увидеть |
|
осноошибкивсехдругныестудентовиханализ. |
|
|
|
|
Процесс анализакода |
тесносвязанрефакторингом |
иявляетсяегодвижущейчастью. |
|
Внутренний ефакторинг – этоулучшениявнутреннейструктурыкодаклбезссов изменения внешнихинтерфейсов.
2Критерии.1 ,котможноиспрыеприанализельзкодавть |
|
|
|
|
1. |
Наличиеорганизациипроектаввидеклассов |
|
|
. |
2. |
Наликомментариевзначимыхинтерфейсукласса |
|
. |
|
3. |
Наличиекоммр ализациинтариевметодов |
|
|
. |
4. |
Недолжнобытьзак мментированны |
хучастккодавпр,котоектевпередаетсяый |
||
|
напросмотрдругим |
. |
|
|
5. |
Следованиекодакакому |
-тоопредесоглокоденномуаш( нию |
code convention). |
|
|
Важно,чтобыкодбылнаписанедино,чтклассыоб,методыразноипеременные |
|
|
|
|
называлисьсогласединомустилю( |
|
апример,чтобыневстрпеременныхчалось |
|
|
variable, Variable, variableName, variable_name, VariableName, var, v одновременно |
|||
|
одномпроекте). |
Примерсоглашениякода |
|
Google дляС++можпосмотретьна |
|
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html Приэтом,важноне |
|||
|
следованиекакому |
-токонкретномустилю,ато,чтостилькодавовсемпроекте |
у |
|
|
разработчика одинаков. |
|
|
10