Lecture 11 - Design Patterns

Διάλεξη 11η --- Πρότυπα Σχεδίασης
Τεχνολογία Λογισμικού
-Πρότυπα Σχεδίασης
Δομικά Πρότυπα
Πρότυπα Συμπεριφοράς
Δημιουργικά πρότυπα
Ανδρέας Λ. Συμεωνίδης
Τμήμα Ηλεκτρολόγων Μηχ/κών
&
Μηχ/κών Υπολογιστών, Α.Π.Θ.
Email:asymeon@eng.auth.gr
ΤΗΜΜΥ – ΑΠΘ Άνοιξη 2010
Είναι αυτό καλό μοντέλο;

public interface SeatImplementation {
public int GetPosition();
public void SetPosition(int newPosition);
}
public class Stubcode implements SeatImplementation {
public int GetPosition() {
// stub code for GetPosition
}
...
}
Εξαρτάται!
public class AimSeat implements SeatImplementation {
// actual call to the AIM simulation system
}
….
}
public class SARTSeat implements SeatImplementation {
// actual call to the SART seat simulator
}
...
}
Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 2
ΤΗΜΜΥ - ΑΠΘ 11-1

Ένα παιχνίδι: Πάρε-15
Ξεκινήστε με εννέα νούμερα: 1,2,3,4,5,6,7,8 και 9.

Εσείς και ο αντίπαλός σας διαλέγετε νούμερα εναλλάξ
Κάθε αριθμός μπορεί να επιλεγεί μόνο μια φορά.
Ο πρώτος ο οποίος έχει 3 αριθμούς με άθροισμα 15 κερδίζει.
Παράδειγμα:
Εσύ:
1 5 3 8
Ο αντίπαλος
Ο αντίπαλος:
6 9 7 2 κερδίζει!
Χαρακτηριστικά του Πάρε-15

Δύσκολο παιχνίδι!
– Το παιχνίδι είναι ιδιαίτερα δύσκολο, ιδίως αν δεν
επιτρέπεται να γράφεις τίποτα.
Γιατί;
– Πρέπει να σαρωθούν όλοι οι αριθμοί για να ελέγξεις αν
κέρδισες/ έχασες
– Είναι δύσκολο να προβλέψεις τι θα επιλέξει ο αντίπαλος αν
επιλέξετε συγκεκριμένο αριθμό
– Η επιλογή του αριθμού εξαρτάται από όλα τα προηγούμενα
νούμερα
– Δεν είναι εύκολο να επινοήσει κανείς έστω και μια απλή
στρατηγική

Ένα άλλο παιχνίδι: Τρίλιζα
Source: http://boulter.com/ttt/index.cgi
Περίπτωση ισοπαλίας

Στρατηγική καθορισμού της

νικητήριας κίνησης
Νικητήριες καταστάσεις στην Τρίλιζα
Πρότυπα
που κερδίζουν

Η Τρίλιζα είναι “Εύκολη”…

Μείωση της πολυπλοκότητας μέσα από πρότυπα και συμμετρίες
Πρότυπα: Γνωρίζοντας τα παρακάτω μοτίβα, ο παίκτης μπορεί να
προβλέψει τις κινήσεις του αντιπάλου.
Συμμετρίες:
• Ο παίκτης χρειάζεται να θυμάται μόνο αυτά τα τρία μοτίβα
για να αντιμετωπίσει 12 διαφορετικές καταστάσεις
Ο παίκτης πρέπει να απομνημονεύσει 3 αρχικές

κινήσεις και τις αποκρίσεις τους
Το Πάρε-15 και η Τρίλιζα είναι ταυτόσημα

προβλήματα
Οποιαδήποτε τρία νούμερα λύνουν το Πάρε-15, λύνουν και
την Τρίλιζα.
Οποιαδήποτε λύση της Τρίλιζας, λύνει και το Πάρε-15.
Για να παρατηρήσετε τη σχέση των δυο παιχνιδιών,
τακτοποιούμε τα 9 ψηφία με το ακόλουθο μοτίβο:
8 1 6
3 5 7
4 9 2

Εσύ: 1 5 3 8
Ο αντίπαλος: 6 9 7 2
8 1 6 8 1 6
3 5 7 3 5 7
4 9 2 4 9 2
Μοντελοποιώντας Ευριστικά
Η μοντελοποίηση πρέπει να είναι συμβατή με τους νοητικούς

μας περιορισμούς:
– Η βραχυπρόθεσμη μνήμη μας έχει περιορισμένη χωρητικότητα (7 ± 2)
Τα καλά μοντέλα ικανοποιούν αυτές τις απαιτήσεις καθώς:
– Δεν κουράζουν το μυαλό
Ένα καλό μοντέλο απαιτεί ελάχιστη προσπάθεια για να γίνει κατανοητό
– Μειώνουν την πολυπλοκότητα
Μετατρέπουν τα σύνθετα προβλήματα σε απλά (με σωστή επιλογή
αναπαράστασης)
Χρησιμοποιούν συμμετρίες
– Είναι αφαιρετικά
Οντολογίες και ταξονομίες
– Έχουν οργανωτική δομή:
Οι περιορισμοί μνήμης ξεπερνιόνται με κατάλληλη αναπαράσταση (“φυσικό
μοντέλο”)

Πρότυπα (Μοτίβα) Σχεδίασης
Ένα πρότυπο σχεδίασης περιγράφει ένα

πρόβλημα το οποίο συμβαίνει ξανά και ξανά στο
περιβάλλον μας.
Επίσης, περιγράφει τον πυρήνα της λύσης στο
πρόβλημα αυτό με τέτοιο τρόπο, ώστε να μπορείτε
να επαναχρησιμοποιήσετε τη λύση αυτή, χωρίς να
την ξανα-υλοποιήσετε.
Διάρθρωση της διάλεξης σε

Πρότυπα Σχεδίασης
Πρότυπα Σχεδίασης
– Χρησιμότητα προτύπων σχεδίασης
– Κατηγορίες προτύπων σχεδίασης
Πρότυπα
– Composite: Μοντελοποιεί δυναμικές συναθροίσεις
– Facade: Ορίζει τις διεπαφές ανάμεσα σε υποσυστήματα
– Adapter: Ορίζει τις διεπαφές σε υπάρχοντα συστήματα (legacy systems)
– Bridge: Ορίζει τις διεπαφές σε υπάρχοντα και μελλοντικά συστήματα
– Proxy: Παρέχει διαφάνεια ως προς την τοποθεσία
– Command: Εμπεριέχει ροή ελέγχου
– Observer: Παρέχει μηχανισμό εκδότη/συνδρομητή (publisher/subscriber)
– Strategy: Υποστηρίζει μια οικογένεια από αλγορίθμους, διαχωρίζει ανάμεσα
στην πολιτική και τον μηχανισμό
– Template: Χρησιμοποιείται για να μειώσει την επικάλυψη
– Abstract Factory: Παρέχει ανεξαρτησία από τον κατασκευαστή
– Builder: Αποκρύπτει μια σύνθετη διαδικασία

Ορίζοντας το πρότυπο σχεδίασης…
Ένα πρότυπο σχεδίασης είναι…

…μια πρότυπη λύση σε ένα επαναλαμβανόμενο πρόβλημα
σχεδίασης
– Ελέγξτε πριν ξανα-εφεύρετε τον τροχό
…επαχρησιμοποιήσιμη γνώση σχεδίασης
– Σε ανώτερο επίπεδο από τις κλάσεις ή τις δομές δεδομένων
(συνδεδεμένες λίστες, δυαδικά δένδρα...)
– Σε χαμηλότερο επίπεδο από τα εργαλεία ανάπτυξης εφαρμογών
…ένα παράδειγμα τροποποιήσιμης σχεδίασης
– Το να μάθεις να σχεδιάζεις αρχίζει με τη μελέτη άλλων σχεδιάσεων
Γιατί είναι σημαντική η τροποποιήσιμη

σχεδίαση;
Μια τροποποιήσιμη σχεδίαση επιτρέπει…
…έναν επαναληπτικό και προοδευτικό κύκλο ανάπτυξης
– Ταυτοχρονισμένη ανάπτυξη
– Διαχείριση ρίσκου
– Ευελιξία στην αλλαγή
…τη μείωση εισαγωγή νέων προβλημάτων κατά την επίλυση των

παλιών
…την παραγωγή περισσότερης λειτουργικότητας μετά το πρώτο

πρωτότυπο

Τι κάνει μια σχεδίαση τροποποιήσιμη;
Χαμηλή σύζευξη και υψηλή συνεκτικότητα

Ξεκάθαρες εξαρτήσεις
Σαφώς ορισμένες υποθέσεις
Πώς βοηθούν σε αυτό τα πρότυπα σχεδίασης;
Είναι γενικευμένα από τα υπάρχοντα συστήματα

Παρέχουν ένα κοινό λεξιλόγιο στους σχεδιαστές
Παρέχουν παραδείγματα τροποποιήσιμων σχεδιάσεων
– Abstract κλάσεις
– Εξουσιοδότηση
Κατηγοριοποίηση των Προτύπων Σχεδίασης
– μειώνουν τη σύζευξη ανάμεσα σε δυο ή περισσότερες κλάσεις
– εισάγουν μια abstract κλάση για μελλοντικές επεκτάσεις
– εμπεριέχουν σύνθετες δομές
Πρότυπα συμπεριφοράς
– επιτρέπουν επιλογή ανάμεσα σε αλγορίθμους και ορισμό ευθυνών
ανάμεσα σε αντικείμενα (“Ποιος κάνει τι;”)
– χαρακτηρίζουν σύνθετες ροές ελέγχου, οι οποίες είναι δύσκολο να
παρακολουθηθούν κατά την εκτέλεση
Δημιουργικά Πρότυπα
– επιτρέπουν την αφαίρεση από σύνθετες διαδικασίες αρχικοποίησης
– κάνουν το σύστημα ανεξάρτητο από τον τρόπο με τον οποίο
δημιουργούνται, συνθέτονται και αναπαριστώνται τα αντικείμενα.

Μια ταξονομία Προτύπων
Πρότυπο
Πρότυπο
Δομικό Συμπεριφοράς Δημιουργικό
Πρότυπο Πρότυπο
Command Observer Strategy

Abstract Builder
Factory Pattern
Template
Composite Adapter Bridge Facade Proxy
Πρότυπο
Πρότυπο

Abstract Builder
Template Factory Pattern

Τι είναι κοινό ανάμεσα στους δυο

αυτούς ορισμούς;
Ορισμός ενός συστήματος λογισμικού
– Ένα σύστημα λογισμικού αποτελείται από υποσυστήματα που είναι είτε
υποσυστήματα, είτε μια συλλογή από κλάσεις
Ορισμός του κύκλου ζωής του λογισμικού

– Ο κύκλος ζωής του λογισμικού αποτελείται από δραστηριότητες
ανάπτυξης που είναι είτε άλλες δραστηριότητες, είτε μια συλλογή
από εργασίες
Αναδρομή!!!
Αναδρομή:
- Μια ορισμένη αφαίρεση η οποία χρησιμοποιείται μέσα στον
ίδιο τον ορισμό της
- Πιο γενικά: Περιγραφή μιας αφαίρεσης βασισμένη σε αυτό-
ομοιότητα.
Τι είναι κοινό ανάμεσα στους δυο

αυτούς ορισμούς; (συν.)
Ορισμός ενός συστήματος λογισμικού
– Ένα σύστημα λογισμικού αποτελείται από υποσυστήματα που είναι
είτε υποσυστήματα, είτε μια συλλογή από κλάσεις
– Σύνθετη περίπτωση: Υποσύστημα
Ένα σύστημα λογισμικού αποτελείται από υποσυστήματα, που
αποτελούνται από υποσυστήματα, που αποτελούνται από ….
– Βασική περίπτωση: Κλάση
Ορισμός του κύκλου ζωής του λογισμικού

– Ο κύκλος ζωής του λογισμικού αποτελείται από δραστηριότητες
ανάπτυξης που είναι είτε άλλες δραστηριότητες, είτε μια συλλογή
από εργασίες
– Σύνθετη περίπτωση: Δραστηριότητα
Ο κύκλος ζωής του λογισμικού αποτελείται από δραστηριότητες, που
αποτελούνται από δραστηριότητες, που αποτελούνται από…
– Βασική περίπτωση: Εργασία

Μοντελοποιώντας το Σύστημα Λογισμικού
Σύστημα *
Λογισμικού
Κλάση Υποσύστημα
Παιδιά
Μοντελοποιώντας τον κύκλο ζωής του

λογισμικού
Software *
Lifecycle
Εργασία Δραστηριότητα
Παιδιά

Παρουσιάζοντας το Πρότυπο Σύνθεσης

(Composite Pattern)
Μοντελοποιεί δενδρικές δομές οι οποίες αναπαριστούν
ιεραρχίες μερικό-όλο, με αυθαίρετο βάθος και πλάτος.
Το πρότυπο Σύνθεσης επιτρέπει τον πελάτη να χειρίζεται με
ενιαίο τρόπο ξεχωριστά αντικείμενα και συνθέσεις αυτών
Client Component *
Leaf Composite
Children
Operation() Operation()
AddComponent
RemoveComponent()
GetChild()
Το πρότυπο Σύνθεσης μοντελοποιεί

δυναμικές συναθροίσεις
Καθορισμένη Δομή: Car
** **
Doors Wheels Battery Engine
Οργανόγραμμα (μεταβλητό επίπεδο συνάθροισης):
** ** Department
University School
Composite
Δυναμικό δένδρο (αναδρομική συνάθροιση):
Program
Pattern
Dynamic tree (recursive aggregate):
**
** Block
Compound Simple
Statement Statement

Οι γραφικές εφαρμογές χρησιμοποιούν

πρότυπα σύνθεσης
• Η κλάση Graphic αναπαριστά και τα
βασικά στοιχεία (Γραμμή, Κύκλος) και τα
containers τους (Εικόνα)
Client Graphic *
Picture
Line Circle
Children
Draw()
Draw() Draw() Add(Graphic g)
RemoveGraphic)
GetChild(int)
Παράδειγμα: Ένα πιο σύνθετο μοντέλο ενός

έργου Λογισμικού
Βασικές Αφαιρέσεις
Ταξονομίες
Equipment
Project
* Facility
Resource Fund
* Organi-
Work
Πρότυπα Σύνθεσης Breakdown
zation
Structure des- Work
Schedule cribes Package
con- *
* * sumes *
produces Organizational
Outcome Work respon- Unit
* * sible *
for plays
depends
Role
Set of Work Work
Activity Task Participant Staff
Products Product
Internal Project
Project Function Department Team
Work Product Deliverable

Το πρότυπο Προσαρμογέας
(Adapter Pattern)
“Μετασχηματίστε τη διεπαφή της κλάσης στη διεπαφή που
περιμένει ο πελάτης.”
Το πρότυπο του Προσαρμογέα επιτρέπει τη συνεργασία
κλάσεων που αλλιώς δεν θα μπορούσαν, λόγω ασύμβατων
διεπαφών
Χρησιμοποιείται για να παρέχει μια νέα διεπαφή σε υπάρχοντα
συστήματα (legacy components).
Είναι γνωστό και ως wrapper
Δυο είδη προτύπων Προσαρμογέα:
– Προσαρμογέας κλάσης (Class adapter):
Εφαρμόζει πολλαπλή κληρονομικότητα για να προσαρμόσει μια διεπαφή σε
μια άλλη
– Προσαρμογέας αντικειμένου (Object adapter):
Εφαρμόζει απλή κληρονομικότητα και εξουσιοδότηση
Πρότυπο Adapter Νέο σύστημα Σύστημα Legacy

(Παλιό σύστημα)
ClientInterface LegacyClass
Client
Request() ExistingRequest()
adaptee Εξουσιοδότηση
Κληρονομικότητα
Adapter
Request()
Η εξουσιοδότηση χρησιμοποιείται για να συνδέσει έναν Adapter με έναν Adaptee

Η κληρονομικότητα διεπαφής χρησιμοποιείται για να καθορίσει τη διεπαφή της
κλάσης Adapter
Οι Target και Adaptee (συνήθως legacy system) προϋπάρχουν του Adapter.
Η Target μπορεί να υλοποιηθεί ως διεπαφή σε μια γλώσσα προγραμματισμού (π.χ.
Java).

Εφαρμογή του προτύπου Adapter στο

πρόβλημα Set
Client Set Hashtable
add(element) put(key,element)
adaptee
MySet
add(element)
Εφαρμογή του προτύπου Adapter για την

ταξινόμηση Strings σε έναν Πίνακα
Array Comparator MyString

greaterThan()
compare() equals()
adaptee
MyStringComparator
compare()

Παράδειγμα προτύπου Adapter

/* Existing target interface */ /* New adapter class */
interface Comparator { class MyStringComparator
int compare(Object o1, Object implements Comparator {
o2); /* ... */
/* ... */ int compare(Object o1, Object
} o2) {
/* Existing client */ int result;
class Array { if (o1.greaterThan(o2)) {
static void sort(Object [] a, result = 1
Comparator c); }
/* ... */ else if (o1.equals(o2)) {
} result = 0;
/* Existing adaptee class */ }
class MyString extends String { else {
boolean equals(Object o); result = -1;
boolean greaterThan }
(MyString s);
return result;
/* ... */
}
}
}
Το πρότυπο Γέφυρας
(Bridge Pattern)
Χρησιμοποιήστε μια γέφυρα για να “αποσυζεύξετε μια

αφαίρεση από την υλοποίησή της, ώστε να μπορούν να
υπάρχουν ανεξάρτητα”. [Gamma et al 1995]
Γνωστό και ως το πρότυπο Handle/Body.
Επιτρέπει τη δυναμική σύνδεση μια από τις πολλές
υλοποιήσεις μιας διεπαφής με έναν πελάτη
Η σχεδιαστική απόφαση μπορεί να πραγματοποιηθεί σε
οποιαδήποτε φάση κατά την εκτέλεση του συστήματος
– Συνήθως όμως, η σύνδεση γίνεται κατά την αρχικοποίηση
του συστήματος (π.χ. στη συνάρτηση αρχικών συνθηκών
της κλάσης διεπαφής)

Χρησιμοποιώντας τη Γέφυρα
Το πρότυπο γέφυρας χρησιμοποιείται για να παρέχει πολλές υλοποιήσεις
κάτω από την ίδια διεπαφή.
Παράδειγμα: Διεπαφή σε ένα τμήμα λογισμικού που είναι ημιτελές, μη
γνωστό, ή μη διαθέσιμο κατά τον έλεγχο του λογισμικού
Το έργο JAMES: αν τα δεδομένα για τη θέση πρέπει να αναγνωστούν,
αλλά η κλάση seat δεν έχει υλοποιηθεί ακόμη, ή έχει μόνο προσομοιωθεί,
υλοποιήστε μια γέφυρα:
Seat
(in Vehicle Subsystem) imp
VIP SeatImplementation
GetPosition()
SetPosition()
Stub Code AIMSeat SARTSeat
Η υλοποίηση της Seat

public interface SeatImplementation {
public int GetPosition();
public void SetPosition(int newPosition);
}
public class Stubcode implements SeatImplementation {
// stub code for GetPosition
}
...
}
public class AimSeat implements SeatImplementation {
// actual call to the AIM simulation system
}
….
}
public class SARTSeat implements SeatImplementation {
// actual call to the SART seat simulator
}
...
}

Το πρότυπο Γέφυρας
Client
Abstraction Implementor
imp
Operator() OperationImpl()
Imp ‐> OperationImp();
Refined Abstraction 1 Refined Abstraction 2 Concrete Implementor A Concrete Implementor B
Operation() Operation() OperationImpl() OperationImpl()
Ταξονομία στο Ταξονομία στο

Πεδίο Εφαρμογής Πεδίο Λύσης
Εφαρμογή του προτύπου Γέφυρας για

διαφορετικούς τύπους Βάσεων Δεδομένων
Arena
imp
LeagueStore LeagueStoreImplementor
Stub Store XML Store JDBC Store

Implementor Implementor Implementor

Adapter vs Bridge
Ομοιότητες:
– Χρησιμοποιούνται για να κρύψουν της λεπτομέρειες της υλοποίησης.
Διαφορές:
– Το πρότυπο προσαρμογέα προσανατολίζεται στο να βάλει
ασυσχέτιστα τμήματα λογισμικού να δουλέψουν μαζί
Εφαρμόζεται σε συστήματα αφού έχουν σχεδιαστεί (reengineering, interface
engineering).
– Το πρότυπο γέφυρας, από την άλλη, εφαρμόζεται εκ των προτέρων για
να διαχωρίσει τις αφαιρέσεις από τις υλοποιήσεις.
Εξουσιοδότηση που ακολουθείται από κληρονομικότητα
Το πρότυπο Πρόσοψης
(Facade Pattern)
Παρέχει μια ενοποιημένη διεπαφή σε ένα σετ από αντικείμενα σε ένα
υποσύστημα.
Ένα facade ορίζει μια υψηλού επιπέδου διεπαφή, η οποία κάνει το
υποσύστημα πιο εύκολο στη χρήση
Τα πρότυπα Facade μας επιτρέπουν να παρέχουν κλειστές
αρχιτεκτονικές

Παράδειγμα του προτύπου Facade
Compiler Compiler
compile(s)
CodeGenerator Lexer
create()
getToken()
Optimizer Parser
create() generateParseTree()
ParseNode
create()
Παράδειγμα σχεδίασης
Το υποσύστημα 1 μπορεί να κοιτά μέσα Subsystem 1

στο υποσύστημα 2 και να καλεί
οποιοδήποτε τμήμα ή μέθοδο κλάσης
θέλει.
Η σχεδίαση αυτή είναι “Ravioli”!!!
Γιατί είναι καλή; Subsystem 2
– Επίδοση
Γιατί είναι κακή; Seat
– Δεν μπορεί να περιμένετε το Card
υποσύστημα που καλεί να καταλαβαίνει
πώς λειτουργεί το άλλο υποσύστημα.
AIM SA/RT
– Είμαστε σχεδόν βέβαιοι ότι για το
υποσύστημα 2 θα γίνει κακή χρήση, και
ο κώδικας θα είναι δύσκολο να
μεταφερθεί, τροποποιηθεί

Υλοποιώντας μια αδιαφανή αρχιτεκτονική

χρησιμοποιώντας το πρότυπο Facade
Το υποσύστημα αποφασίζει VIP Subsystem
ακριβώς τον τρόπο
προσπέλασής του.
Δεν χρειάζεται να
ανησυχούμε για κακή χρήση
Εάν χρησιμοποιηθεί ένα
Vehicle Subsystem API
façade, το υποσύστημα
μπορεί να χρησιμοποιηθεί σε
ένα αρχικό έλεγχο Seat Card
ολοκλήρωσης
– Χρειάζεται να γράψουμε
AIM
μόνο έναν driver SA/RT
Σχεδίαση υποσυστημάτων με τα Façade,

Adapter, Bridge
Η ιδανική δομή ενός υποσυστήματος αποτελείται από:
– Ένα αντικείμενο διεπαφής
– Ένα σετ από αντικείμενα του πεδίου εφαρμογής (αντικείμενα
οντοτήτων), τα οποία μοντελοποιούν πραγματικές οντότητες ή
υπάρχοντα συστήματα
Κάποια από τα αντικείμενα αυτά είναι διεπαφές σε υπάρχοντα συστήματα
– Ένα ή περισσότερα αντικείμενα ελέγχου
Μπορούμε να χρησιμοποιήσουμε πρότυπα σχεδίασης για να
υλοποιήσουμε αυτή την δομή υποσυστημάτων
Υλοποίηση του αντικειμένου διεπαφής ⇒ Facade
– Παρέχει τη διεπαφή στο υποσύστημα
Διεπαφή σε υπάρχοντα συστήματα ⇒ Adapter ή Bridge
– Παρέχουν τη διεπαφή σε ένα υπάρχον σύστημα (legacy system), το
οποίο δεν ακολουθεί (αναγκαστικά) αντικειμενοστραφή λογική!

Το πρότυπο Εντολοδόχος
(Proxy Pattern): Το κίνητρο
Είναι 15:00 το μεσημέρι. Κάθομαι πίσω από την

10MBps σύνδεσή μου και ανεβάζω φωτογραφίες
στο Facebook. Είναι ώρα αιχμής, οπότε η ταχύτητά
μου δεν ξεπερνά τα 50 KBps
Τι μπορώ να κάνω;
Το πρότυπο Proxy
Πρόβλημα Σχεδίασης: Τι είναι ιδιαίτερα πολυέξοδο στα

αντικειμενοστρεφή συστήματα;
– Η δημιουργία αντικειμένων
– Η αρχικοποίηση αντικειμένων
Λύση:
– Διαχωρίστε τις φάσεις αυτές μέχρι τη στιγμή που χρειάζεστε το
αντικείμενο
Το πρότυπο Proxy:
– Μειώνει το κόστος προσπέλασης αντικειμένων
– Χρησιμοποιεί ένα άλλο αντικείμενο (“το proxy”) το οποίο λειτουργεί ως
αντικαταστάτης του πραγματικού αντικειμένου
– Ο proxy δημιουργεί το πραγματικό αντικείμενο μόνο όταν το ζητήσει το
χρήστης

Το πρότυπο Proxy
Subject
Request()
Proxy RealSubject
realSubject
Request() Request()
Η κληρονομικότητα διεπαφών χρησιμοποιείται για τον καθορισμό των

διεπαφών που χρησιμοποιούνται από τον Proxy και το RealSubject.
Εξουσιοδότηση χρησιμοποιείται για να συλλάβει και να προωθήσει
δικαιώματα πρόσβασης στο RealSubject (αν αυτό είναι επιθυμητό)
Τα πρότυπα Proxy μπορούν να χρησιμοποιηθούν για απομακρυσμένη
κλήση.
Εφαρμοσιμότητα του προτύπου Proxy
Caching πληροφορίας (“Remote Proxy”)

– To Proxy αντικείμενο είναι ο τοπικός αντιπρόσωπος ενός αντικειμένου σε άλλο
χώρο διευθύνσεων
– Καλό αν η πληροφορία δεν αλλάζει συχνά
Αντ’αυτού (“Virtual Proxy”)
– Το αντικείμενο είναι πολύ ακριβό για να δημιουργηθεί ή πολύ ακριβό για να
«κατέβει»
– Καλό αν το δεν γίνεται προσπέλαση του πραγματικού αντικειμένου συχνά
Έλεγχος πρόσβασης (“Protection Proxy”)
– Το αντικείμενο proxy παρέχει ασφάλεια για το πραγματικό
– Καλό όταν διάφοροι δράστες πρέπει να έχουν διαφορετικά δικαιώματα
πρόσβασης και όψεων για το ίδιο αντικείμενο
– Παράδειγμα: Η πληροφορία των βαθμών των εξετάσεων, όπως την
προσπελαύνουν οι διαχειριστές του συστήματος, οι διδάσκοντες και οι φοιτητές

Παράδειγμα Virtual Proxy
Image
boundingBox()
draw()
ProxyImage RealImage
boundingBox()
realSubject
boundingBox()
draw() draw()
Εικόνες αποθηκεύονται και φορτώνονται ξεχωριστά από το κείμενο

Εάν μια RealImage δεν φορτώνεται, ο ProxyImage δείχνει ένα γκρι
ορθογώνιο στη θέση της εικόνας
Ο πελάτης δεν μπορεί να αντιληφθεί ότι έχει να κάνει με ProxyImage
Το πρότυπο proxy μπορεί εύκολα να συνδυαστεί με Γέφυρα
Πριν

Ελέγχοντας την πρόσβαση
Μετά

Πρότυπα Συμπεριφοράς
Πρότυπο
Πρότυπο

Abstract Builder
Factory Pattern
Template
Το πρότυπο Command: Κίνητρο
Θέλετε να φτιάξετε ένα περιβάλλον διεπαφής χρήστη

Θέλετε να παρέχετε μενού
Θέλετε το περιβάλλον διεπαφής να είναι
επαναχρησιμοποιήσιμο και να μπορεί να εφαρμοστεί σε
διάφορες εφαρμογές
– Δεν μπορείτε να περάσετε στον κώδικα (hardcode) τις
έννοιες των μενού για τις διάφορες εφαρμογές
– Μόνο οι εφαρμογές γνωρίζουν τι ακριβώς πρέπει να γίνει
όταν επιλεγεί ένα μενού
Ένα τέτοιο μενού μπορεί να υλοποιηθεί εύκολα με το πρότυπο
Command

Πρότυπο Command
Command
Invoker
execute()
Client
<<binds>>
Receiver
ConcreteCommand
action()
execute()
Ο Πελάτης δημιουργεί ένα ConcreteCommand και το συνδέει με έναν

Receiver.
Ο Πελάτης παραδίδει το ConcreteCommand στον Invoker ο οποίος το
αποθηκεύει.
Ο Invoker είναι υπεύθυνος για την εκτέλεση της εντολής (“execute” ή “undo”).
Σχόλια στο πρότυπο Command
Η Command abstract κλάση δηλώνει τη διεπαφή που υποστηρίζεται από

όλες τις ConcreteCommands.
Ο πελάτης είναι μια κλάση σε έναν σχεδιαστή διεπαφής χρήστη ή μια
κλάση που εκτελείται κατά την αρχικοποίηση της εφαρμογής που χτίζει το
περιβάλλον διεπαφής.
Ο πελάτης δημιουργεί concreteCommands και τις συνδέει σε
συγκεκριμένους Receivers (μπορες να είναι “commit”, “execute”,
“undo”).
– Όλες οι ορατές από τον χρήστη εντολές είναι υποκλάσεις της abstract
κλάσης Command.
Ο invoker – η κλάση στην εφαρμογή που προσφέρει το μενού των
εντολών ή τα κουμπιά – εκκινεί την concreteCommand βασισμένη
στην εντολή που δόθηκε και τη σύνδεση ανάμεσα σε action και
ConcreteCommand.

Αποσυνδέει οριακά αντικείμενα από

αντικείμενα ελέγχου
Το πρότυπο command μπορεί να αποσυζεύξει τα οριακά από

τα αντικείμενα ελέγχου:
– Τα οριακά αντικείμενα όπως τα στοιχεία του μενού και τα κουμπιά,
στέλνουν μηνύματα αποστολής στα αντικείμενα εντολών (δηλ. τα
αντικείμενα ελέγχου)
– Μόνο να αντικείμενα εντολών τροποποιούν τα αντικείμενα οντοτήτων
Όταν αλλάζει το περιβάλλον διεπαφής χρήστη, μόνο τα οριακά
αντικείμενα τροποποιούνται
Εφαρμόζοντας το πρότυπο Command σε

σετ εντολών
ReplayedMatch Match *
Move
nextMove() play()
previousMove() execute()
replay()
«binds»
GameBoard TicTacToeMove
ChessMove

Το πρότυπο Παρατηρητής
(Observer Pattern)
Πρόβλημα:
– Έχουμε ένα αντικείμενο που αλλάζει την κατάστασή του ιδιαίτερα
συχνά
Παράδειγμα: Ένα πορτφόλιο μετοχών
– Θέλουμε να παρέχουμε πολλές όψεις της τρέχουσας κατάστασης του
πορτφόλιο
Παράδειγμα: Όψη ιστογράμματος, πίτας, γραμμής χρόνου κτλ
Απαιτήσεις:
– Το σύστημα πρέπει να διατηρεί τη συνοχή ανάμεσα στις όψεις, όποτε
και αν αλλάζει η κατάσταση του παρατηρούμενου αντικειμένου
– Η σχεδίαση του συστήματος πρέπει να είναι ιδιαίτερα επεκτάσιμη
Πρέπει να παρέχεται η δυνατότητα να προστίθενται νέες όψεις χωρίς να
χρειάζεται η επανα-μεταγλώττιση του αντικειμένου ή της όψης του
Πρότυπο Παρατηρητή
Observers
Αντικείμενο
9DesignPatterns2.ppt

Το πρότυπο Παρατηρητή: Αποσυνδέει μια

αφαίρεση από τις όψεις της
Subject
observers *
subscribe(subscriber) Observer
subscribe(subscriber) update()
notify()
subject ConcreteObserver
ConcreteSubject
subjectState observerState
getState()
setState(newState) update()
Το Subject (“Publisher”) αναπαριστά το αντικείμενο οντότητα

Οι Observers (“Subscribers”) συνδέονται στο Subject καλώντας την subscribe()
Κάθε Observer έχει μια διαφορετική όψη της κατάστασης του αντικειμένου οντότητα:
– Η κατάσταση περιέχεται στην υποκλάση ConcreteSubject
– Η κατάσταση μπορεί να επιστραφεί και να οριστεί από υποκλάσεις του τύπου
ConcreteObserver.
Υλοποίηση του Observer προτύπου σε Java

// import java.util;
public class Observable extends Object {

public void addObserver(Observer o);
public void deleteObserver(Observer o);
public boolean hasChanged();
public void notifyObservers();
public void notifyObservers(Object arg);
}
public abstract interface Observer {

public abstract void update(Observable o, Object arg);
}
public class Subject extends Observable{
public void setState(String filename);
public string getState();
}

Εφαρμόζοντας το πρότυπο Observer για να

διατηρήσουμε τη συνοχή ανάμεσα στις MatchViews.
observers
Subject Observer
1 *
subscribe(Subscriber) update()
unsubscribe(Subscriber)
notify()
GameBoard MatchView
state gameBoard
getState() update()
playMove()
Πρότυπο Στρατηγικής
(Strategy Pattern)
Υπάρχουν πολλοί αλγόριθμοι για την ίδια εργασία
– Μπορούμε να εναλλάξουμε ανάμεσα σε αλγορίθμους σε χρόνο
εκτέλεσης
Παραδείγματα:
– Διαφορετικές στρατηγικές σύγκρουσης αντικειμένων σε video games
– Ταξινόμηση μιας λίστας πελατών (Bubble sort, mergesort, quicksort)
– Εφαρμογή διαφορετικού αλγορίθμου Εξόρυξης Δεδομένων πάνω στο
ίδιο σετ
Διαφορετικοί αλγόριθμοι είναι κατάλληλοι σε διαφορετικές περιπτώσεις
Αν χρειαζόμαστε έναν νέο αλγόριθμο, θέλουμε να μπορούμε να τον
προσθέσουμε εύκολα, χωρίς να χρειάζεται να ξανασχεδιάσουμε ολόκληρη
την εφαρμογή

Πρότυπο Στρατηγικής
Policy
Context * Strategy
ContextInterface() AlgorithmInterface
ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC
AlgorithmInterface() AlgorithmInterface() AlgorithmInterface()
Policy αποφασίζει ποια Strategy είναι καλύτερη δεδομένου του τρέχοντος

Context
Εφαρμόζοντας το πρότυπο Στρατηγικής σε

μια ταξινόμηση
Database Strategy
Strategy *
Search() Sort()
Sort()
BubbleSort QuickSort MergeSort
Sort() Sort() Sort()

Πρότυπο Template: Κίνητρο
Πολλές υποκλάσεις μοιράζονται τον ίδιο αλγόριθμο, αλλά

διαφέρουν στις λεπτομέρειες
Τα κοινά βήματα δεν πρέπει να επαναλαμβάνονται στις
υποκλάσεις
– Εκτέλεση μιας σειράς από πειράματα ελέγχου
– Άνοιγμα, ανάγνωση, και εγγραφή σε αρχεία διαφορετικών τύπων
Προσέγγιση:
– Τα κοινά βήματα βγαίνουν έξω, σε μια abstract κλάση
Abstract μέθοδοι καθορίζονται για κάθε βήμα
– Οι υποκλάσεις προσφέρουν διαφορετικές υλοποιήσεις για κάθε ένα
από τα βήματα.
Πρότυπο Template
AbstractClass
templateMethod()
step1()
step2()
step3()
ConcreteClass
step1()
step2()
step3()

Παράδειγμα: Σενάρια Ελέγχου
TestCase
run()
setUp() setUp();
runTest() try {
tearDown() runTest();
}
catch (Exception e){
recordFailure(e);
MyTestCase }
setUp() tearDown();
runTest()
tearDown()
Παράδειγμα: Άνοιγμα Αρχείων
Application
openDocument()
canOpenFile(f:File)
createDocument(f:File):Doc if (canOpenFile(f)) {
aboutToOpenDocument(d:Doc) Doc d;
d = createDocument(f);
aboutToOpenDocument(d);
d.open();
MyApplication
}
canOpenFile(f: File)
createDocument(f:File):Doc
aboutToOpenDocument(d:Doc)

Δημιουργικά Πρότυπα
Πρότυπο
Πρότυπο

Abstract Builder
Factory Pattern
Template
Το Πρότυπο Abstract Factory: Κίνητρο
Θεωρήστε μια εργαλειοθήκη γραφικών περιβαλλόντων διεπαφής

που υποστηρίζει διάφορα look-n-feels, όπως Linux, Windows κτλ
– Πώς μπορώ να γράψω ένα περιβάλλον διεπαφής και να το κάνω
φορητό ανάμεσα στα διάφορα look and feels;
Θεωρήστε την υποδομή του έξυπνου σπιτιού, η οποία

υποστηρίζει διάφορα συστήματα ελέγχου όπως Siemens’
Instabus, Johnson & Control Metasys ή το Zumtobe’s standard.
– Πώς μπορώ να γράψω ένα σύστημα ελέγχου, ανεξάρτητο από τον
κατασκευαστή;

Το πρότυπο Abstract Factory
AbstractFactory AbstractProductA
Client
CreateProductA
CreateProductB
ProductA1 ProductA2
ConcreteFactory1 AbstractProductB
CreateProductA
CreateProductB
ProductB1 ProductB2
ConcreteFactory2
CreateProductA Συσχέτιση αρχικοποίησης:

CreateProductB Η κλάση ConcreteFactory2 αρχικοποιεί τις
συσχετισμένες κλάσεις ProductB2 και ProductA2
Εφαρμοσιμότητα του Abstract Factory

Ανεξαρτησία από Αρχικοποίηση ή Αναπαράσταση:
– Το σύστημα πρέπει να είναι ανεξάρτητο από το πώς δημιουργούνται,
συνθέτονται, ή αναπαρίστανται τα αντικείμενα
Ανεξαρτησία από Κατασκευαστή:
– Ένα σύστημα πρέπει να παραμετροποιηθεί για μια οικογένεια προϊόντων, ενώ
θα μπορούσε κανείς να επιλέξει από διάφορες οικογένειες προϊόντων.
– Θέλετε να παρέχετε μια βιβλιοθήκη κλάσεων, αλλά δεν θέλετε να αποκαλύψετε
το συγκεκριμένο προϊόν που χρησιμοποιείτε.
Περιορισμοί σε σχετικά προϊόντα
– Μια οικογένεια προϊόντων σχεδιάζεται για να χρησιμοποιείται από κοινού και
εσείς θέλετε να ενισχύσετε τον περιορισμό
Ανοχή στην επερχόμενη αλλαγή:
– Χρησιμοποιείτε μια συγκεκριμένη οικογένεια προϊόντων, αλλά γνωρίζετε ότι η
τεχνολογία που θα χρησιμοποιείται σε λίγο θα είναι διαφορετική.

Παράδειγμα: Η υποδομή διαχείρισης για το

έξυπνο σπίτι
IntelligentWorkplace
Facility LightBulb
Mgt InitLightSystem
System InitBlindSystem
InitACSystem
SiemensLight ZumbobelLight
Controller Controller
Blinds
SiemensFactory
InitLightSystem
InitBlindSystem
InitACSystem
SiemnensBlind ZumtobelBlind
Controller Controller
ZumtobelFactory
InitLightSystem
InitBlindsystem
InitACSystem
Το πρότυπο Builder: Κίνητρο
Η κατασκευή ενός σύνθετου αντικειμένου είναι συχνή

Παράδειγμα
– Μετασχηματισμός ενός εγγράφου σε άλλους τύπους
τα βήματα εγγραφής ενός εγγράφου παραμένουν τα ίδια
οι λεπτομέρειες κάθε βήματος εξαρτώνται από τον τύπο
Προσέγγιση
– Ο αλγόριθμος κατασκευής καθορίζεται από μια κλάση (τον “director”)
– Τα αφηρημένα βήματα του αλγορίθμου (ένα για κάθε βήμα)
καθορίζονται από μια διεπαφή (τον “builder”)
– Κάθε αναπαράσταση παρέχει μια στιβαρή υλοποίηση της διεπαφής (οι
“concrete builders”)

Το Πρότυπο Builder
Director Builder
Construct() BuildPart()
For all objects in Representation B

Structure {
Builder->BuildPart()
}
ConcreteBuilderB
BuildPart()
GetResult()
ConcreteBuilderA
BuildPart()
GetResult() Representation A
Παράδειγμα: Μετατρέποντας ένα RTF

έγγραφο σε διάφορους τύπους
RTFReader
Parse() TextConverter
ConvertCharacter()
ConvertFontChange
ConvertParagraph()
While (t = GetNextToken()) {
Switch t.Type {
CHAR: builder->ConvertCharacter(t.Char)
FONT: bulder->ConvertFont(t.Font)
PARA: builder->ConvertParagraph
} }
TexConverter AsciiConverter HTMLConverter

ConvertCharacter() ConvertCharacter() ConvertCharacter()
ConvertFontChange ConvertFontChange ConvertFontChange
ConvertParagraph() ConvertParagraph() ConvertParagraph()
GetASCIIText() GetASCIIText() GetASCIIText()
TeXText AsciiText HTMLText

Πότε χρησιμοποιούμε το πρότυπο Builder;
Η δημιουργία ενός πολύπλοκου προϊόντος πρέπει να είναι

ανεξάρτητη των τμημάτων που αποτελούν το προϊόν
– Συγκεκριμένα, η διαδικασία δημιουργίας δεν πρέπει να γνωρίζει
πληροφορίες για τη διαδικασία συναρμολόγησης
Η διαδικασία δημιουργίας πρέπει να επιτρέπει διαφορετικές
αναπαραστάσεις του αντικειμένου που κατασκευάζεται.
– Ένα σπίτι με 1 όροφο, 3 δωμάτια, 2 διαδρόμους, 1 γκαράζ and 3
πόρτες.
– Ένας ουρανοξύστης με 50 ορόφους, 15 γραφεία and 5 διαδρόμους σε
κάθε όροφο. Η διαρρύθμιση των γραφείων διαφέρει ανά όροφο.
Οι μη-λειτουργικές απαιτήσεις μπορούν να

δώσουν ένα στοιχείο κατάλληλου προτύπου
Διαβάστε τη διατύπωση του προβλήματος ξανά

Χρησιμοποιείστε στοιχεία στο κείμενο για να αναγνωρίσετε
σχεδιαστικά πρότυπα (παρόμοιος τρόπος με την τεχνική του
Abbot στην Ανάλυση Απαιτήσεων)
– Κείμενο: “ανεξάρτητο κατασκευαστή”, “ανεξάρτητο συσκευής”,
“πρέπει να υποστηρίζει μια οικογένεια προϊόντων” =>
Abstract Factory Pattern
– Κείμενο: “πρέπει να επικοινωνεί με ένα ήδη
εγκατεστημένο αντικείμενο” => Adapter Pattern
– Κείμενο: “πρέπει να επικοινωνεί με πολλά συστήματα,
μερικά από τα οποία θα αναπτυχθούν στο μέλλον”,
“πρέπει να αναπτυχθεί ένα πρωτότυπο νωρίς” => Bridge
Pattern

Στοιχεία στο κείμενο για μη λειτουργικές

απαιτήσεις
– Κείμενο: “σύνθετη δομή”, “πρέπει να έχει μεταβλητό βάθος
και πλάτος” => Composite Pattern
– Κείμενο: “πρέπει να επικοινωνεί με ένα σετ από ήδη
εγκατεστημένα αντικείμενα” => Façade Pattern
– Κείμενο: “πρέπει να είναι ανεξάρτητο της τοποθεσία
(location transparent)” => Proxy Pattern
– Κείμενο: “πρέπει να είναι επεκτάσιμο”, “πρέπει να είναι
κλιμακούμενο” => Observer Pattern
– Κείμενο: “πρέπει να έχει πολιτική ανεξάρτητη από το
μηχανισμό” => Strategy Pattern
Σύνοψη
Τα πρότυπα σχεδίασης αποτελούν μερικές λύσεις σε κοινά

προβλήματα όπως
– Τον διαχωρισμό μιας διεπαφής από έναν αριθμό διαφορετικών
υλοιποιήσεων
– Την ενσωμάτωση (wrapping) παλιών (legacy) κλάσεων
– Την προστασία του καλούντος από αλλαγές που σχετίζονται με
συγκεκριμένες πλατφόρμες.
Ένα πρότυπο σχεδίασης αποτελείται από ένα μικρό αριθμό
κλάσεων
– Χρησιμοποιεί εξουσιοδότηση και κληρονομικότητα
– Παρέχει μια εύρωστη και τροποποιήσιμη λύση.
Οι κλάσεις στα πρότυπα σχεδίασης μπορούν να
προσαρμοστούν και να συγκεκριμενοποιηθούν για το εκάστοτε
σύστημα.

Σύνοψη (συν.)
Composite, Adapter, Bridge, Façade, Proxy
(Δομικά Πρότυπα)
– Στόχος: Σύνθεση αντικειμένων για τη δημιουργία μεγαλύτερων
δομών
Υλοποιούν νέα λειτουργικότητα από την παλιά
Παρέχουν ευελιξία και επεκτασιμότητα
Command, Observer, Strategy, Template
(Πρότυπα Συμπεριφοράς)
– Στόχος: Αλγόριθμοι και ανάθεση ευθυνών στα αντικείμενα
Αποφεύγουν την στενή σύζευξη σε συγκεκριμένες λύσεις
Abstract Factory, Builder (Δημιουργικά Πρότυπα)
– Στόχος: Δημιουργία σύνθετων αντικειμένων
Αποκρύπτουν πώς τα σύνθετα αντικείμενα δημιουργούνται και
συναρμολογούνται
Σύνοψη (συν.)
Πρότυπα σχεδίασης
– Παρέχουν λύσεις σε κοινά προβλήματα.
– Οδηγούν σε επεκτάσιμα μοντέλα και κώδικα.
– Μπορούν να χρησιμοποιηθούν αυτούσια ή ως
παραδείγματα κληρονομικότητας διεπαφών ή εξιοδότησης.
– Εφαρμόζουν τις ίδιες αρχές στη δομή και στη
συμπεριφορά.
Τα πρότυπα σχεδίασης ΔΕΝ επιλύουν όλα τα προβλήματα

σας στην τεχνολογία λογισμικού!!! Είναι όμως ένα καλό σημείο
για να αρχίσετε ☺…

Αναφορές
Διαφάνειες του Bernd Bruegge για σχεδίαση λογισμικού

Design Patterns: Elements of Reusable Object-Oriented
Software, Gamma et. al, 94.
Παραδείγματα προτύπων σχεδίασης από:
http://www.fluffycat.com/Java-Design-Patterns/

Lecture 11 - Design Patterns

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 11 - Design Patterns

Uploaded by

Copyright:

Available Formats

Διάλεξη 11η --- Πρότυπα Σχεδίασης

ΤΗΜΜΥ – ΑΠΘ Άνοιξη 2010

Είναι αυτό καλό μοντέλο;

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 2

ΤΗΜΜΥ - ΑΠΘ 11-1

Ένα παιχνίδι: Πάρε-15

Ξεκινήστε με εννέα νούμερα: 1,2,3,4,5,6,7,8 και 9.

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 3

Χαρακτηριστικά του Πάρε-15

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 4

ΤΗΜΜΥ - ΑΠΘ 11-2

Ένα άλλο παιχνίδι: Τρίλιζα

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 5

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 6

ΤΗΜΜΥ - ΑΠΘ 11-3

Στρατηγική καθορισμού της

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 7

Νικητήριες καταστάσεις στην Τρίλιζα

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 8

ΤΗΜΜΥ - ΑΠΘ 11-4

Η Τρίλιζα είναι “Εύκολη”…

Ο παίκτης πρέπει να απομνημονεύσει 3 αρχικές

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 9

Το Πάρε-15 και η Τρίλιζα είναι ταυτόσημα

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 10

ΤΗΜΜΥ - ΑΠΘ 11-5

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 11

Η μοντελοποίηση πρέπει να είναι συμβατή με τους νοητικούς

ΤΗΜΜΥ - ΑΠΘ 11-6

Πρότυπα (Μοτίβα) Σχεδίασης

Ένα πρότυπο σχεδίασης περιγράφει ένα

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 13

Διάρθρωση της διάλεξης σε

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 14

ΤΗΜΜΥ - ΑΠΘ 11-7

Ορίζοντας το πρότυπο σχεδίασης…

Ένα πρότυπο σχεδίασης είναι…

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 15

Γιατί είναι σημαντική η τροποποιήσιμη

…τη μείωση εισαγωγή νέων προβλημάτων κατά την επίλυση των

…την παραγωγή περισσότερης λειτουργικότητας μετά το πρώτο

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 16

ΤΗΜΜΥ - ΑΠΘ 11-8

Τι κάνει μια σχεδίαση τροποποιήσιμη;

Χαμηλή σύζευξη και υψηλή συνεκτικότητα

Πώς βοηθούν σε αυτό τα πρότυπα σχεδίασης;

Είναι γενικευμένα από τα υπάρχοντα συστήματα

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 17

Κατηγοριοποίηση των Προτύπων Σχεδίασης

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 18

ΤΗΜΜΥ - ΑΠΘ 11-9

Μια ταξονομία Προτύπων

Command Observer Strategy

Composite Adapter Bridge Facade Proxy

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 19

Command Observer Strategy

Composite Adapter Bridge Facade Proxy

Α.Λ. Συμεωνίδης Τεχνολογία Λογισμικού 20

ΤΗΜΜΥ - ΑΠΘ 11-10

Τι είναι κοινό ανάμεσα στους δυο

Ορισμός του κύκλου ζωής του λογισμικού

Τι είναι κοινό ανάμεσα στους δυο

Ορισμός του κύκλου ζωής του λογισμικού

ΤΗΜΜΥ - ΑΠΘ 11-11