Design Patterns : Elements of Reusable Object-Oriented Software



Download 4,06 Mb.
Pdf ko'rish
bet31/288
Sana07.04.2022
Hajmi4,06 Mb.
#535140
1   ...   27   28   29   30   31   32   33   34   ...   288
Bog'liq
GOF Design Patterns
Копасов Игорь (1), Т Е Л Е Ф О Н О Г Р А М М А ЗООМ, 20201546 п.80 использ., Oliy matematika, презентация индустрия мутакил иши, 3000 most common words in English, Sun'iy intellekt, 1638511850 AE, 1638511850 AE, Hisob-raqan (Patent boji), O'RQ-600 23-MODDA, Talabaning haftalik hisoboti namunasi , iikinchi hafta amaliyoti., Таҳлил тест
Designing for Change 
The key to maximizing reuse lies in anticipating new requirements and changes 
to existing requirements, and in designing your systems so that they can evolve 
accordingly. 
To design the system so that it's robust to such changes, you must consider how 
the system might need to change over its lifetime. A design that doesn't take 
change into account risks major redesign in the future. Those changes might involve 
class redefinition and reimplementation, client modification, and retesting. 


Design Patterns: Elements of Reusable Object-Oriented Software 
37 
Redesign affects many parts of the software system, and unanticipated changes 
are invariably expensive. 
Design patterns help you avoid this by ensuring that a system can change in specific 
ways. Each design pattern lets some aspect of system structure vary independently 
of other aspects, thereby making a system more robust to a particular kind of 
change. 
Here are some common causes of redesign along with the design pattern(s) that 
address them:
1.
Creating an object by specifying a class explicitly.
Specifying a class 
name when you create an object commits you to a particular implementation 
instead of a particular interface. This commitment can complicate future 
changes. To avoid it, create objects indirectly.
Design patterns: Abstract Factory (99), Factory Method (121), Prototype 
(133). 
2.
Dependence on specific operations.
When you specify a particular operation, 
you commit to one way of satisfying a request. By avoiding hard-coded 
requests, you make it easier to change the way a request gets satisfied 
both at compile-time and at run-time.
Design patterns: Chain of Responsibility (251), Command (263). 
3.
Dependence on hardware and software platform.
External operating system 
interfaces and application programming interfaces (APIs) are different on 
different hardware and software platforms. Software that depends on a 
Download 4,06 Mb.

Do'stlaringiz bilan baham:
1   ...   27   28   29   30   31   32   33   34   ...   288




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©hozir.org 2022
ma'muriyatiga murojaat qiling

    Bosh sahifa
davlat universiteti
ta’lim vazirligi
axborot texnologiyalari
maxsus ta’lim
zbekiston respublikasi
guruh talabasi
O’zbekiston respublikasi
nomidagi toshkent
o’rta maxsus
texnologiyalari universiteti
toshkent axborot
davlat pedagogika
xorazmiy nomidagi
rivojlantirish vazirligi
pedagogika instituti
Ўзбекистон республикаси
tashkil etish
haqida tushuncha
vazirligi muhammad
таълим вазирлиги
O'zbekiston respublikasi
toshkent davlat
махсус таълим
respublikasi axborot
kommunikatsiyalarini rivojlantirish
vazirligi toshkent
saqlash vazirligi
fanidan tayyorlagan
bilan ishlash
Toshkent davlat
Ishdan maqsad
sog'liqni saqlash
uzbekistan coronavirus
respublikasi sog'liqni
fanidan mustaqil
coronavirus covid
koronavirus covid
vazirligi koronavirus
covid vaccination
qarshi emlanganlik
risida sertifikat
sertifikat ministry
vaccination certificate
o’rta ta’lim
matematika fakulteti
haqida umumiy
fanlar fakulteti
pedagogika universiteti
ishlab chiqarish
moliya instituti
fanining predmeti