Scribd
Upload
270 views

Design Patterns in Smalltalk MVC

The document discusses the Model-View-Controller (MVC) pattern used in Smalltalk. It describes MVC as consisting of three types of objects: the Model stores application data, the View displays the data, and the Controller handles user input. MVC decouples views and models through a subscribe/notify protocol, allowing views to update dynamically when the model changes. The example diagram shows a model communicating with multiple views to display data in different formats.

Uploaded by

jenetpraba
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
270 views

Design Patterns in Smalltalk MVC

The document discusses the Model-View-Controller (MVC) pattern used in Smalltalk. It describes MVC as consisting of three types of objects: the Model stores application data, the View displays the data, and the Controller handles user input. MVC decouples views and models through a subscribe/notify protocol, allowing views to update dynamically when the model changes. The example diagram shows a model communicating with multiple views to display data in different formats.

Uploaded by

jenetpraba
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 23

Design patterns in

Smalltalk MVC
Design Patterns in Smalltalk
MVC
 The Model/View/Controller (MVC) triad of
classes is used to build user interfaces in
Smalltalk-80.
 Design patterns inside MVC should help
you see what we mean by the term
"pattern.”
 MVC consists of three kinds of objects
 The Model is the application object
 The View is its screen presentation,
 The Controller defines the way the user
interface reacts to user input
 MVC decouples views and models by
establishing a subscribe/notify protocol
between them.
 A view must ensure that its appearance
reflects the state of the model.
 Whenever the model's data changes, the
model notifies views that depend on it.
 In response, each view gets an opportunity to
update itself.
 You can also create new views for a model
without rewriting it.
Diagram of a model and three
views
 The diagram shows a model and three views.
 The model contains some data values, and
the views defining a spreadsheet, histogram,
and pie chart display these data in various
ways.
 The model communicates with its views
when its values change, and the view
communicate with the model to access these
values.
 This example reflects a design that
decouples views from models.
 The design is applicable to a more general
problem: decoupling objects so that changes
to one can affect any number of others
without requiring the changed object to know
details of the others
 This more general design is described by the
Observer (page 326) design pattern.
 Another feature of MVC is that views can be
nested.
 MVC supports nested views with the
Composite View class, a subclass of View.
 CompositeView objects act just like View
objects;
 a composite view can be used wherever a
view can be used, but it also contains and
manages nested views.
 The View-Controller relationship is an
example of the Strategy design pattern.
 A Strategy is an object that represents an
algorithm.
 It's useful when you want to replace the
algorithm either statically or dynamically,
when you have a lot of variants of the
algorithm, or when the algorithm has complex
data structures that you want to encapsulate.
 MVC uses other design patterns, such as
Factory Method (121) to specify the default
controller class for a view and Decorator
(196) to add scrolling to a view.
Describing Design
Patterns
How do we describe design
patterns?
 Graphical notations, while important and
useful, aren't sufficient.
 They simply capture the end product of the
design process as relationships between
classes and objects.
 To reuse the design, we must also record the
decisions, alternatives, and trade-offs that led
to it.
 We describe design patterns using a
consistent format
 Each pattern is divided into sections
according to the following template.
 The template lends a uniform structure to the
information, making design patterns easier to
learn, compare and use.
Pattern Name and Classification
 The pattern's name conveys the essence of
the pattern succinctly.
 A good name is vital, because it will become
part of your design vocabulary.
 The pattern's classification reflects the
scheme
Intent
A short statement that answers the following
questions:
 What does the design pattern do?

 What is its rationale and intent?

 What particular design issue or problem


does it address?
Also Known As
 Other well-known names for the pattern, if any.

Motivation
 A scenario that illustrates a design problem and
how the class and object structures in the
pattern solve the problem.
 The scenario will help you understand the more
abstract description of the pattern that follows.
 Applicability
 What are the situations in which the design
pattern can be applied?
 What are examples of poor designs that the
pattern can address?
 How can you recognize these situations?
Structure
 A graphical representation of the classes in
the pattern using a notation based on the
Object Modeling Technique (OMT) [RBP+91].
 We also use interaction diagrams [JCJO92,
Boo94] to illustrate sequences of requests and
collaborations between objects.
 Appendix B describes these notations in
detail.
Participants
 The classes and/or objects participating in
the design pattern and their responsibilities.
Collaborations
 How the participants collaborate to carry out
their responsibilities.
Consequences
 How does the pattern support its objectives?

 What are the trade-offs and results of using


the pattern?
Implementation
 What pitfalls, hints, or techniques should you
be aware of when implementing the pattern?
 Are there language-specific issues?
Sample Code
 Code fragments that illustrate how you might
implement the pattern in C++ or Smalltalk.
Known Uses
 Examples of the pattern found in real
systems.
 We include at least two examples from
different domains.
Related Patterns
 What design patterns are closely related to
this one?
 What are the important differences?

 With which other patterns should this one be


used?

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy