This document provides an introduction to design patterns. It defines what a design pattern is, discusses common types and classifications of patterns. It explains the benefits of using patterns such as reducing time to design applications and avoiding problems from inexperienced design decisions. Examples of specific patterns are described in detail including Elements of Identification, Catalytic Scenarios, and Mutable Code. Principles of object-oriented design like programming to an interface are covered. The differences between class and interface inheritance and composition vs inheritance are explained.
Tried putting things in the deck that I learnt about Extreme programming in XP Conference held in Bangalore. I have tried to keep it at very high level added with light moments, so that it doesn't getting boring and makes sense for most of us
Lecture 2 from the MHIT 603 course on Human Interface Technology. This lecture provides an introduction to Prototyping. Taught by Mark Billinghurst at the University of Canterbury, July 17th, 2014.
At the core, the job of a software developer is and has always been the same: writing good, elegant, sustainable and bug-free software that exceeds the expectations of your clients. But the context in which we do our job is changing and with it the skills required to be a great software developer. In this talk, I want to go through a couple of things that I think make the difference between a developer and a great developer. This includes some technical skills and practices, but also non-technical things that you might not consider relevant for a developer at first.
Tried putting things in the deck that I learnt about Extreme programming in XP Conference held in Bangalore. I have tried to keep it at very high level added with light moments, so that it doesn't getting boring and makes sense for most of us
Lecture 2 from the MHIT 603 course on Human Interface Technology. This lecture provides an introduction to Prototyping. Taught by Mark Billinghurst at the University of Canterbury, July 17th, 2014.
At the core, the job of a software developer is and has always been the same: writing good, elegant, sustainable and bug-free software that exceeds the expectations of your clients. But the context in which we do our job is changing and with it the skills required to be a great software developer. In this talk, I want to go through a couple of things that I think make the difference between a developer and a great developer. This includes some technical skills and practices, but also non-technical things that you might not consider relevant for a developer at first.
Software Engineering Best Practices @ NylasBen Gotow
Part of an introductory series given to new hires and interns, this talk is a crash course in design patterns and engineering best practices for new-grads with mostly academic computer science experience. Focuses on the things they don't teach you: naming things, working on a team, optimizing for maintainability.
I recently gave a talk at Architecting Innovation about going extreme with Extreme Programming. In these slides, I give a brief history of Extreme Programming, what are some of the guiding principles of Extreme Programming and why an organization might want to choose Extreme Programming over other software development methodologies.
Good software engineering practices are key to building quality and in this talk we’ll have a whistle stop tour of a range of techniques that often sit under the ‘XP’ umbrella such as TDD (Test Driven Development), Pair Programming, BDD (Behaviour Driven Development) and more generally Continuous Delivery.
XP in 10 Slides::Extreme Programming revisiting. A concise introduction to XP delivered at Agile Yorkshire in January 2012. CC-by-3.0 please download, reuse and remix.
Researchers in model-driven development (MDD) should be intimately familiar with how MDD is used in industry. If they are not, there is a danger that new methods and tools are developed without proper consideration for the way that MDD developers actually work and think. A thorough understanding of current MDD industrial practice can inform research problems and ensure that research solutions are actually adopted.
This talk will describe results from a year long study, which applied methods from social science to understand how MDD is actually used in industry. Based on a survey of over 400 MDD practitioners, in-depth interviews with 22 industry professionals from 17 different companies, and a small number of on-site observational studies, the talk will discuss the current state-of-practice in industrial use of MDD, and will offer some insights on current research gaps.
Software Engineering Best Practices @ NylasBen Gotow
Part of an introductory series given to new hires and interns, this talk is a crash course in design patterns and engineering best practices for new-grads with mostly academic computer science experience. Focuses on the things they don't teach you: naming things, working on a team, optimizing for maintainability.
I recently gave a talk at Architecting Innovation about going extreme with Extreme Programming. In these slides, I give a brief history of Extreme Programming, what are some of the guiding principles of Extreme Programming and why an organization might want to choose Extreme Programming over other software development methodologies.
Good software engineering practices are key to building quality and in this talk we’ll have a whistle stop tour of a range of techniques that often sit under the ‘XP’ umbrella such as TDD (Test Driven Development), Pair Programming, BDD (Behaviour Driven Development) and more generally Continuous Delivery.
XP in 10 Slides::Extreme Programming revisiting. A concise introduction to XP delivered at Agile Yorkshire in January 2012. CC-by-3.0 please download, reuse and remix.
Researchers in model-driven development (MDD) should be intimately familiar with how MDD is used in industry. If they are not, there is a danger that new methods and tools are developed without proper consideration for the way that MDD developers actually work and think. A thorough understanding of current MDD industrial practice can inform research problems and ensure that research solutions are actually adopted.
This talk will describe results from a year long study, which applied methods from social science to understand how MDD is actually used in industry. Based on a survey of over 400 MDD practitioners, in-depth interviews with 22 industry professionals from 17 different companies, and a small number of on-site observational studies, the talk will discuss the current state-of-practice in industrial use of MDD, and will offer some insights on current research gaps.
Dear students get fully solved assignments
Send your semester & Specialization name to our mail id :
help.mbaassignments@gmail.com
or
call us at : 08263069601
Dear students get fully solved assignments
Send your semester & Specialization name to our mail id :
help.mbaassignments@gmail.com
or
call us at : 08263069601
В рамках C/C++/Embedded місяця у GlobalLogic нещодавно відбувся Online TechTalk "Patterns in Embedded SW Design"
Спікер розібрав паттерни на кісточки: від поняття до практичного використання з прикладом проєктного коду.
У доповіді спеціаліст розглянув:
- Поняття патернів у програмному забезпеченні з акцентом на Embedded розробку.
- Основні переваги використання патернів.
- Класифікацію патернів для Embedded напрямку, деякі з них було розглянуто.
- Було наведено приклад використання на прикладі проєктного коду.
Деталі та відео заходу: https://bit.ly/3DaKx7t
In this three hour workshop I present an introduction to the UCD process, an overview of the basic technologies of the web and a survey of current Mobile Web Design trends.
Industry-Academia Communication In Empirical Software EngineeringPer Runeson
Researchers in software engineering must communicate with industry practitioners, both engineers and managers. Communication may be about collaboration buy-in, problem identification, empirical data collection, solution design, evaluation, and reporting. In order to gain mutual benefit of the collaboration, ensuring relevant research and improved industry practice, researchers and practitioners must be good at communicating. The basis for a researcher to be good at industry-academia communication is firstly to be “bi-lingual”. Understanding and being able to translate between these “languages” is essential. Secondly, it is also about being “bi-cultural”.Understanding the incentives in industry and academia respectively, is a basis for being able to find balances between e.g. rigor and relevance in the research. Time frames is another aspect that is different in the two cultures. Thirdly, the choice of communication channels is key to reach the intended audience.A wide range of channels exist, from face to face meetings, via tweets and blogs, to academic journal papers and theses; each having its own audience and purposes. The keynote speech will explore the challenges of industry-academia communication, based on two decades of collaboration experiences, both successes and failures. It aims to support primarily the academic side of the communication to help achieving industry impact through rigorous and relevant empirical software engineering research.
Macroeconomics- Movie Location
This will be used as part of your Personal Professional Portfolio once graded.
Objective:
Prepare a presentation or a paper using research, basic comparative analysis, data organization and application of economic information. You will make an informed assessment of an economic climate outside of the United States to accomplish an entertainment industry objective.
The Roman Empire A Historical Colossus.pdfkaushalkr1407
The Roman Empire, a vast and enduring power, stands as one of history's most remarkable civilizations, leaving an indelible imprint on the world. It emerged from the Roman Republic, transitioning into an imperial powerhouse under the leadership of Augustus Caesar in 27 BCE. This transformation marked the beginning of an era defined by unprecedented territorial expansion, architectural marvels, and profound cultural influence.
The empire's roots lie in the city of Rome, founded, according to legend, by Romulus in 753 BCE. Over centuries, Rome evolved from a small settlement to a formidable republic, characterized by a complex political system with elected officials and checks on power. However, internal strife, class conflicts, and military ambitions paved the way for the end of the Republic. Julius Caesar’s dictatorship and subsequent assassination in 44 BCE created a power vacuum, leading to a civil war. Octavian, later Augustus, emerged victorious, heralding the Roman Empire’s birth.
Under Augustus, the empire experienced the Pax Romana, a 200-year period of relative peace and stability. Augustus reformed the military, established efficient administrative systems, and initiated grand construction projects. The empire's borders expanded, encompassing territories from Britain to Egypt and from Spain to the Euphrates. Roman legions, renowned for their discipline and engineering prowess, secured and maintained these vast territories, building roads, fortifications, and cities that facilitated control and integration.
The Roman Empire’s society was hierarchical, with a rigid class system. At the top were the patricians, wealthy elites who held significant political power. Below them were the plebeians, free citizens with limited political influence, and the vast numbers of slaves who formed the backbone of the economy. The family unit was central, governed by the paterfamilias, the male head who held absolute authority.
Culturally, the Romans were eclectic, absorbing and adapting elements from the civilizations they encountered, particularly the Greeks. Roman art, literature, and philosophy reflected this synthesis, creating a rich cultural tapestry. Latin, the Roman language, became the lingua franca of the Western world, influencing numerous modern languages.
Roman architecture and engineering achievements were monumental. They perfected the arch, vault, and dome, constructing enduring structures like the Colosseum, Pantheon, and aqueducts. These engineering marvels not only showcased Roman ingenuity but also served practical purposes, from public entertainment to water supply.
Biological screening of herbal drugs: Introduction and Need for
Phyto-Pharmacological Screening, New Strategies for evaluating
Natural Products, In vitro evaluation techniques for Antioxidants, Antimicrobial and Anticancer drugs. In vivo evaluation techniques
for Anti-inflammatory, Antiulcer, Anticancer, Wound healing, Antidiabetic, Hepatoprotective, Cardio protective, Diuretics and
Antifertility, Toxicity studies as per OECD guidelines
Honest Reviews of Tim Han LMA Course Program.pptxtimhan337
Personal development courses are widely available today, with each one promising life-changing outcomes. Tim Han’s Life Mastery Achievers (LMA) Course has drawn a lot of interest. In addition to offering my frank assessment of Success Insider’s LMA Course, this piece examines the course’s effects via a variety of Tim Han LMA course reviews and Success Insider comments.
Embracing GenAI - A Strategic ImperativePeter Windle
Artificial Intelligence (AI) technologies such as Generative AI, Image Generators and Large Language Models have had a dramatic impact on teaching, learning and assessment over the past 18 months. The most immediate threat AI posed was to Academic Integrity with Higher Education Institutes (HEIs) focusing their efforts on combating the use of GenAI in assessment. Guidelines were developed for staff and students, policies put in place too. Innovative educators have forged paths in the use of Generative AI for teaching, learning and assessments leading to pockets of transformation springing up across HEIs, often with little or no top-down guidance, support or direction.
This Gasta posits a strategic approach to integrating AI into HEIs to prepare staff, students and the curriculum for an evolving world and workplace. We will highlight the advantages of working with these technologies beyond the realm of teaching, learning and assessment by considering prompt engineering skills, industry impact, curriculum changes, and the need for staff upskilling. In contrast, not engaging strategically with Generative AI poses risks, including falling behind peers, missed opportunities and failing to ensure our graduates remain employable. The rapid evolution of AI technologies necessitates a proactive and strategic approach if we are to remain relevant.
How to Make a Field invisible in Odoo 17Celine George
It is possible to hide or invisible some fields in odoo. Commonly using “invisible” attribute in the field definition to invisible the fields. This slide will show how to make a field invisible in odoo 17.
Synthetic Fiber Construction in lab .pptxPavel ( NSTU)
Synthetic fiber production is a fascinating and complex field that blends chemistry, engineering, and environmental science. By understanding these aspects, students can gain a comprehensive view of synthetic fiber production, its impact on society and the environment, and the potential for future innovations. Synthetic fibers play a crucial role in modern society, impacting various aspects of daily life, industry, and the environment. ynthetic fibers are integral to modern life, offering a range of benefits from cost-effectiveness and versatility to innovative applications and performance characteristics. While they pose environmental challenges, ongoing research and development aim to create more sustainable and eco-friendly alternatives. Understanding the importance of synthetic fibers helps in appreciating their role in the economy, industry, and daily life, while also emphasizing the need for sustainable practices and innovation.
Model Attribute Check Company Auto PropertyCeline George
In Odoo, the multi-company feature allows you to manage multiple companies within a single Odoo database instance. Each company can have its own configurations while still sharing common resources such as products, customers, and suppliers.
Francesca Gottschalk - How can education support child empowerment.pptxEduSkills OECD
Francesca Gottschalk from the OECD’s Centre for Educational Research and Innovation presents at the Ask an Expert Webinar: How can education support child empowerment?
Francesca Gottschalk - How can education support child empowerment.pptx
Class (1)
1. Software Engineering
Design Patterns -- Introduction
Mira Balaban
Department of Computer Science
Ben-Gurion university
Based on slides of:
F. Tip, J. Vlissides, J. Cooper, IBM T J Watson Research Center.
R. Whitney, San-Diego State University.
D.C. Schmidt, Vanderbilt University.
Software Engineering, 2005
Design Patterns – introduction
1
2. Sources:
1. Classical text: Design Patterns: Elements of Reusable
Object-Oriented Software, Gamma, Helm, Johnson,
Vlissides, (GoF), 1995
2. Java Design Patterns – A Tutorial, J.W. Cooper, 2000.
3. Applied Java Patterns, S. Stelting, O. Maassen, 2002.
4. Patterns home page: http://hillside.net/patterns/
5. Yearly conferences: Patterns Languages of Programs.
http://hillside.net/conferences/plop.htm
Software Engineering, 2005
Design Patterns – introduction
2
3. What is a Pattern? (R. Whitney)
"Each pattern describes a problem which occurs over and
over again in our environment, and then describes the core
of the solution to that problem, in such a way that you can
use this solution a million times over, without ever doing it
the same way twice“
"Each pattern is a three-part rule, which expresses a relation
between a certain context, a problem, and a solution"
Christopher Alexander on architecture patterns
A Pattern Language, Christopher Alexander, 1977
Software Engineering, 2005
Design Patterns – introduction
3
4. What is a Pattern? (R. Whitney)
"Patterns are not a complete design method; they
capture important practices of existing methods and
practices uncodified by conventional methods"
James Coplien
Software Patterns, James Coplien, 1996, 2000,
http://www1.belllabs.com/user/cope/Patterns/WhitePaper/
Software Engineering, 2005
Design Patterns – introduction
4
5. Example: A Place To Wait (Alexander 1977)
The process of waiting has inherent conflicts in it.
The context:
Waiting for doctor, airplane etc. requires spending time
hanging around doing nothing
Can not enjoy the time since you do not know when you
must leave
Classic "waiting room"
•
•
•
•
Dreary little room
People staring at each other
Reading a few old magazines
Offers no solution
Software Engineering, 2005
Design Patterns – introduction
5
6. Example: A Place To Wait (Alexander 1977)
Fundamental problem:
• How to spend time wholeheartedly" and
• Still be on hand when doctor, airplane etc arrive
The solution:
Fuse the waiting with other activity that keeps them in
earshot
• Playground beside Pediatrics Clinic
• Horseshoe pit next to terrace where people waited
Allow the person to become still meditative
•
•
•
•
A window seat that looks down on a street
A protected seat in a garden
A dark place and a glass of beer
A private seat by a fish tank
Software Engineering, 2005
Design Patterns – introduction
6
7. Example: A Place To Wait (Alexander 1977)
The Solution:
"In places where people end up waiting create a situation
which makes the waiting positive. Fuse the waiting with some
other activity - newspaper, coffee, pool tables, horseshoes;
something which draws people in who are not simple waiting.
And also the opposite: make a place which can draw a
person waiting into a reverie; quiet; a positive silence"
Software Engineering, 2005
Design Patterns – introduction
7
8. Example: Chicken and Egg (Anthony 1996)
The Problem
Two concepts are each a prerequisite of the other
To understand A one must understand B
To understand B one must understand A
A "chicken and egg" situation
Patterns for Classroom Education, Dana Anthony, pp. 391406, Pattern Languages of Program Design 2, Addison
Wesley, 1996
Software Engineering, 2005
Design Patterns – introduction
8
9. Example: Chicken and Egg (Anthony 1996)
Constraints and Forces
First explain A then B
Everyone would be confused by the end
Simplify each concept to the point of incorrectness to
explain the other one
People don't like being lied to
The Solution
Explain A & B correctly by superficially
Iterate your explanations with more detail each iteration
Software Engineering, 2005
Design Patterns – introduction
9
10. Example: A Pattern Language for the Preparation
of Software Demonstrations (Coram 1996)
The patterns:
Element Identification
2.
Catalytic Scenarios
3. Mutable Code
4. Prototyping Languages
5. Lightweight User Interfaces
6. Judicious Fireworks
7. Archive Scenarios
1.
Demo Prep: A Pattern Language for the Preparation of Software Demonstrations,
Todd Coram, pp. 407-416, Pattern Languages of Program Design 2, Addison
Wesley, 1996
Software Engineering, 2005
Design Patterns – introduction
10
11. Pattern 1: Element Identification (Coram 1996)
The Problem:
Selecting the right features to demo is a critical part of keeping the
customer's confidence
The Context
Have requirements
Working on demo to easy customers doubts about committing to or
continuing with the software project
Forces
Need to demonstrate your ability to deliver "things that work"
Need to show some level of functionality
Customer wants to see the product's face - the GUI
If customer is not happy with the demo, they are not likely to like the end
product
Demos build confidence and create anticipation
Software Engineering, 2005
Design Patterns – introduction
11
12. Pattern 1: Element Identification (Coram 1996)
The Solution:
Identify key areas that concern the customer
Talk to the customer
Listen carefully
Stay away from excessive animations or other visual
embellishments
Unless the product is a game, the product is to help the
customer get some work done not to entertain people
The product's face can be shown through Lightweight User
Interface (pattern 5)
Functionality can be addressed by Prototyping Languages
(pattern 4)
Software Engineering, 2005
Design Patterns – introduction
12
13. Pattern 2: Catalytic Scenarios (Coram 1996)
The Problem:
The customer has specified what they think they want
You don't want to build the wrong thing
The Context
Starting a project to develop software based on requirements and
specification that have already been agreed on
The Forces
Customer may not really know what they want
Requirements may not accurately reflect customer's requirements
Requirements may be ambiguous
Customer expects to be given vision of the finished product
Demos consume developer's resources
Software Engineering, 2005
Design Patterns – introduction
13
14. Pattern 2: Catalytic Scenarios (Coram 1996)
The Solution:
Use demonstrable scenarios as a catalyst to open a dialogue
between you and the customer
If the specs are ambiguous develop alternative scenarios
Do not demonstrate capabilities that will be hard to
incorporate into your design
If you do not want to change the spec make sure the demo
scenarios follow the spec
Keep demo scenarios simple and short
Software Engineering, 2005
Design Patterns – introduction
14
15. Pattern 3: Mutable Code (Coram 1996)
The Problem:
How much code should you write for the demo?
The Context
You have identified your Catalytic Scenarios and are evaluating the amount
of effort required to develop them
The Forces
Some demo code
• Can not be used in the end product
• Should not be used in the end product
Development time for demo impacts product development
Customer does not like to pay for developing something twice
Software Engineering, 2005
Design Patterns – introduction
15
16. Pattern 3: Mutable Code (Coram 1996)
The Solution:
Build modifiable code
Use tools that support a high level of abstraction
• GUI builders
• Scripting languages
Write as little code as possible for the demo
• Use as much real code as you can
If you build screens then use Lightweight User Interfaces
Prototyping Languages (pattern 4) discusses integrating
demo code into end product
Software Engineering, 2005
Design Patterns – introduction
16
17. What are design patterns? (J.W. Cooper)
Recurring solutions to design problems you see over and over. (Alpert
et al, 1998)
A set of rules describing how to accomplish certain tasks in the realm
of software development. (Pree, 1994)
Focus on reuse of recurring architectural design themes (Coplien and
Schmidt, 1995)
Address a recurring design problem that arises in a specific context
and presents a solution to it (Buschmann. et al, 1996)
Identify and specify abstractions that are above the level of single
classes or instances, or of components. (GoF)
Software Engineering, 2005
Design Patterns – introduction
17
18. More Paradigms of design patterns
Problem Analysis (Fowler)
Enterprise systems (Fowler)
Responsibility assignment in system design (Larman)
User interfaces.
Web site construction.
Software design (GoF, Coplien, and others)
Software Engineering, 2005
Design Patterns – introduction
18
19. What is a Software design pattern? (F.
Tip)
Related question: what is the difference between
experienced and inexperienced software designers?
• experienced designers know from experience what
works and what doesn’t
• able to recognize “standard” design problems and apply
“proven” solutions to them
Definition of a software design pattern:
a description of communicating classes and objects that
are customized to solve a general design problem in a
particular context
Software Engineering, 2005
Design Patterns – introduction
19
20. Benefits of Software Patterns (R. Whitney)
By providing domain expertise patterns
Reduce time to find solutions
Avoid problems from inexpert design decisions
Patterns reduce time to design applications
Patterns are design chunks larger than objects
Patterns reduce the time needed to understand a design
Software Engineering, 2005
Design Patterns – introduction
20
21. Patterns of Learning (D.C. Schmidt)
Successful solutions to many areas of human endeavor
are deeply rooted in patterns
– An important goal of education is transmitting patterns of learning
from generation to generation
Learning to develop good software is similar to learning to
play good chess
Software Engineering, 2005
Design Patterns – introduction
21
22. Becoming a Chess Master (D.C. Schmidt)
First learn the rules – e.g., names of pieces, legal movements, chess
board geometry and orientation, etc.
Then learn the Principles – e.g., relative value of certain pieces,
strategic value of center squares, power of a threat, etc.
However, to become a master of chess, one must study the
games of other masters – These games contain patterns that must
be understood, memorized, and applied repeatedly
There are hundreds of these patterns
Software Engineering, 2005
Design Patterns – introduction
22
23. Becoming a Software Design Master
(D.C. Schmidt)
First learn the rules
– e.g., the algorithms, data structures and languages of software
Then learn the principles
– e.g., structured programming, modular programming, object oriented
programming, generic programming, etc.
However, to become a master of software design, one must
study the designs of other masters
– These designs contain patterns that must be understood, memorized, and
applied repeatedly
There are hundreds of these patterns
Software Engineering, 2005
Design Patterns – introduction
23
25. Learn to apply design patterns to the
design process (J. Vlissides)
find the right patterns
understand (un)applicability
see when and how to bend a pattern
evaluate design trade-offs effectively
Learn by (counter) example
Software Engineering, 2005
Design Patterns – introduction
25
26. Common Forms for Writing Design Patterns
(R. Whitney)
Alexander
• Originated pattern literature
GOF (Gang of Four)
• Style used in Design Patterns text
Portland Form
• Form used in on-line Portland Pattern Repository
http://c2.com/cgi/wiki?PortlandPatternRepository
Coplien
Software Engineering, 2005
Design Patterns – introduction
26
27. Elements of Design Patterns (F. Tip)
a design pattern has 4 elements:
• a name (e.g, “Abstract Factory” or “Visitor”)
• the problem that the pattern addresses
• the solution: the program constructs that are part of
the pattern
• the consequences: the results and tradeoffs of
applying the pattern
other factors:
• problem & solution have been observed in practice
• choice of implementation language important
Software Engineering, 2005
Design Patterns – introduction
27
28. Classifying Design Patterns (F. Tip)
purpose: what a pattern does
• creational: concerned with creation of objects
• structural: related to composition of classes or objects
• behavioral: related to interaction and distribution of
responsibility
scope
• class-level: concerned with relationship between
classes and their subclasses
• object-level: concerned with object relationship (more
dynamic, may be changed at run-time)
Software Engineering, 2005
Design Patterns – introduction
28
30. Principles of Object-Oriented Design
(F. Tip)
Program to an interface, not an
implementation.
Favor object composition over class
inheritance.
Software Engineering, 2005
Design Patterns – introduction
30
31. Class vs. Interface Inheritance (F. Tip)
class inheritance defines an object’s
implementation in terms of another object’s
implementation
• mechanism for code & representation sharing
interface inheritance describes when an object
can be used in place of another
many languages (e.g., C++) don’t make this
distinction, but Java does
Software Engineering, 2005
Design Patterns – introduction
31
32. Class vs. Interface Inheritance (2) (F. Tip)
benefits of class inheritance
• extend an application’s functionality by reusing
functionality in parent classes
• lets you get new implementations almost for free,
inheriting most of what you need from existing classes
benefits of interface inheritance
• clients remain unaware of specific types of objects they
use, and of the classes that implement these objects
using interface inheritance greatly reduces
dependencies between subsystems
• reduces the impact of changes
Software Engineering, 2005
Design Patterns – introduction
32
33. Mechanisms for Reusing Functionality
(F. Tip)
class inheritance: define implementation of one class in
terms of another
• often referred to as white-box reuse: internals of parent class
visible to extending class
“class inheritance breaks encapsulation”
object composition: compose objects to get new, more
complex functionality
• implemented by giving objects references to other objects; access
these objects via interfaces
• requires that objects have well-defined interfaces
• often called black-box reuse: no internal details of objects are
visible to the class that uses them
“composition does not break encapsulation”
Software Engineering, 2005
Design Patterns – introduction
33
34. Pros & Cons of Class Inheritance (F. Tip)
Advantages:
• directly supported by the programming language, hence easy to
use
• makes it easy to modify the reused implementation (by simply
overriding a few methods)
Disadvantages:
• cannot change inherited functionality at run-time, because
inheritance is fixed at compile-time
• parent classes define at least part of their subclasses’ physical
representation, and subclasses are exposed to details of their
parent’s implementation
» implementation of subclass becomes very tightly coupled with
implementation of parent
» change in parent is likely to require changes in subclass
Software Engineering, 2005
Design Patterns – introduction
34
35. Delegation (F. Tip)
delegation is an alternative to inheritance:
• two objects are involved: a receiving object delegates
an operation to its delegate
• analogy: a subclass that defers a request to its parent
class
suppose an object of type C wants to delegate a
method f() to an object of type D:
• class D defines method f()
• class C needs to contain a reference field d to a Dobject, which needs to be initialized
• C needs a forwarding method f() that calls f() on d
Software Engineering, 2005
Design Patterns – introduction
35
36. Delegation: Example (F. Tip)
class Window delegates its
area() operation to
a Rectangle instance
public class Rectangle {
private int width;
private int height;
public int area(){ return width * height; }
}
public class Window {
private Rectangle rect;
public int area(){ return rect.area(); }
}
public class WindowClient {
void someOperation(Window w){ ... w.area() ... }
}
Software Engineering, 2005
Design Patterns – introduction
36
37. (Ab)use inheritance for the same purpose
(F. Tip)
public class Rectangle {
private int width;
private int height;
public int area(){ return width * height; }
}
public class Window extends Rectangle {
private Rectangle rect;
// method area() inherited from superclass
}
public class WindowClient {
void someOperation(Window w){ ... w.area() ... }
}
Software Engineering, 2005
Design Patterns – introduction
37
38. Why use delegation? (F. Tip)
inheritance can be more convenient:
• only define method f() once
• no need to forward calls
• somewhat more efficient
however, it is less flexible:
• cannot change the implementation of f() after creating
the object
• in languages with single inheritance, you can only
inherit methods from one superclass
Software Engineering, 2005
Design Patterns – introduction
38
39. True delegation (F. Tip)
with inheritance, the method in the superclass
can use dynamic dispatch to invoke methods in
a subclass
with delegation, this requires some extra work:
• pass receiving object’s this pointer as an argument to
the delegate
• delegate invokes methods on this reference when it
needs to invoke methods on receiving object
this form of delegation is called true delegation
for an example of true delegation, see the “State”
design pattern
Software Engineering, 2005
Design Patterns – introduction
39
40. When to use inheritance? (F. Tip)
generally speaking, use inheritance for:
• is-a relationships that don’t change over time
• situations where the class containing the actual
operation is abstract
generally speaking, use delegation for:
•
•
•
•
has-a, part-of relationships
is-a-role-played-by relationships
relationships that change over time
situations where multiple inheritance would be needed
(if language doesn’t allow MI)
Software Engineering, 2005
Design Patterns – introduction
40
41. Designing for change (F. Tip)
many design patterns introduce flexibility to
avoid common causes of redesign such as:
•
•
•
•
•
•
•
•
creating an object by specifying a class explicitly
dependence on specific operations
dependence on hardware/software platform
dependence on object representations or
implementations
algorithmic dependencies
tight coupling
extending functionality by subclassing
inability to alter classes conveniently
Software Engineering, 2005
Design Patterns – introduction
41
42. Designing for change (R. Whitney)
Some common design problems that GoF patterns that
Address:
• Creating an object by specifying a class explicitly
Abstract factory, Factory Method, Prototype
Dependence on specific operations
Chain of Responsibility, Command
Dependence on hardware and software platforms
Abstract factory, Bridge
Dependence on object representations or
implementations
Abstract factory, Bridge, Memento, Proxy
Software Engineering, 2005
Design Patterns – introduction
42
43. Designing for change (R. Whitney)
Algorithmic dependencies
Builder, Iterator, Strategy, Template Method, Visitor
Tight Coupling
Abstract factory, Bridge, Chain of Responsibility,
Command, Facade, Mediator, Observer
Extending functionality by subclassing
Bridge, Chain of Responsibility, Composite, Decorator,
Observer, Strategy
Inability to alter classes conveniently
Adapter, Decorator, Visitor
Software Engineering, 2005
Design Patterns – introduction
43