Patterns¶ ↑
: subtitle
in Software Engineering
: author
Giovanni Sakti
: institution
Starqle
% : content-source % id_ruby % : date % 2017-11-01 : theme
starqle
Patterns¶ ↑
(('tag:center'))What is Patterns?
properties¶ ↑
: hide-title true
Patterns¶ ↑
# blockquote # title = Christopher Alexander Patterns describes a problem, which occurs over and over again in our environment and then desribes the core of the solution to that problem...
Patterns¶ ↑
# blockquote # title = Christopher Alexander ...in such a way that you can use this solution a million times over without ever doing it the same way twice.
Patterns¶ ↑
(('tag:center'))Okay, but who is Christopher Alexander?
properties¶ ↑
: hide-title true
Patterns¶ ↑
# image # src = images/christopher_alexander.jpg # keep_ratio = true # width = 300
(('tag:center'))Christopher Alexander is an ((Architect))
properties¶ ↑
: hide-title true
Patterns¶ ↑
(('tag:center'))He authored widely-influential book in 1977.
properties¶ ↑
: hide-title true
Patterns¶ ↑
# image # src = images/a_pattern_language.jpg # keep_ratio = true # height = 400
properties¶ ↑
: hide-title true
Patterns¶ ↑
(('tag:center'))The book influences multiple disciplines including software engineering.
properties¶ ↑
: hide-title true
Patterns¶ ↑
(('tag:center'))So, what is patterns from the viewpoint of software engineering?
properties¶ ↑
: hide-title true
Patterns¶ ↑
(('tag:center'))Patterns are ((*distilled commonalities*)) that you find in software.
Patterns¶ ↑
(('tag:center'))It allows us to deconstruct a large complex structure and build using the pattern itself.
Patterns¶ ↑
(('tag:center'))Patterns contain solution that have ((developed)) and ((evolved)) over time.
Patterns¶ ↑
(('tag:center'))It is rarely designs that people tend to get initially.
Reusability¶ ↑
(('tag:center'))We know that designing software is ((hard)).
properties¶ ↑
: hide-title true
Reusability¶ ↑
(('tag:center'))Designing software with reusable components are even ((harder)).
properties¶ ↑
: hide-title true
Reusability¶ ↑
(('tag:center'))Your design should be ((specific)) to the problem at hand, but ((*general enough*)) to address future problems and requirements.
properties¶ ↑
: hide-title true
Reusability¶ ↑
(('tag:center'))Reusable & flexible design is ((difficult)), if not ((impossible)), to get “right” the first time.nn Even for experienced designer.
properties¶ ↑
: hide-title true
Reusability¶ ↑
(('tag:center'))Instead, experienced designer won't try to solve every problem from scratch.
Reusability¶ ↑
(('tag:center'))They will try to ((reuse)) existing solution instead.
Reusability¶ ↑
(('tag:center'))So, patterns help designer gets a design “right” ((faster)).
Expectations¶ ↑
(('tag:center'))What can learning patterns help you?
properties¶ ↑
: hide-title true
Expectations¶ ↑
(('tag:center'))Common design vocabulary
Expectations¶ ↑
(('tag:center'))Documentation and learning aid # help in understanding complex system
Expectations¶ ↑
(('tag:center'))An adjunct to existing methods # adjunct == supplementary
Expectations¶ ↑
(('tag:center'))A target for refactoring
Expectations¶ ↑
-
Common design vocabulary
-
Documentation and learning aid
-
An adjunct to existing methods
-
A target for refactoring
Patterns Essential Elements¶ ↑
(('tag:center'))Patterns Essential Elements
properties¶ ↑
: hide-title true
Patterns Essential Elements¶ ↑
(('tag:center'))An excellently documented patterns will have several elements attached to it.
Patterns Essential Elements¶ ↑
(('tag:center'))Which you can use to learn more about them.
Patterns Essential Elements¶ ↑
-
Name
-
Intent
-
Sketch
Patterns Essential Elements (cont'd)¶ ↑
-
Problem
-
Solution
-
Consequence(s)
Patterns Essential Elements (cont'd)¶ ↑
-
When to Use It
-
Example(s)
Patterns Categories¶ ↑
(('tag:center'))Patterns Categories
properties¶ ↑
: hide-title true
Patterns Categories¶ ↑
(('tag:center'))There are several categories of patterns, based on the ((level)) in which they reside.
Patterns Categories¶ ↑
From “lowest” level to “highest” leveln
-
Programming Paradigms
-
Design Patterns
-
Architectural Patterns
Patterns Categories¶ ↑
(('tag:center'))We'll try to discuss it one-by-one.
Programming Paradigms¶ ↑
(('tag:center'))Programming paradigms
properties¶ ↑
: hide-title true
Programming Paradigms¶ ↑
(('tag:center'))Programming paradigms((-Such as: OO, Functional or Procedural-)), in a way, is a pattern.
Programming Paradigms¶ ↑
(('tag:center'))To be precise, programming paradigms is the ((smallest)) and ((lowest)) level of patterns possible.
Programming Paradigms¶ ↑
(('tag:center'))Programming paradigms are most likely to ((influence)) patterns that reside above it.
Programming Paradigms¶ ↑
(('tag:center'))And because programming paradigms are ((*tightly coupled*)) to programming language..
Programming Paradigms¶ ↑
(('tag:center'))..our pick of programming language may ((influence)) the way we design our software.
Design Patterns¶ ↑
(('tag:center'))Design Patterns
properties¶ ↑
: hide-title true
Design Patterns¶ ↑
(('tag:center'))Design patterns are code-level commonalities.
Design Patterns¶ ↑
(('tag:center'))Providing schemes for refining & building smaller subsystems.
Design Patterns¶ ↑
(('tag:center'))Design patterns are ((*medium-scale tactics*)) that flesh out some of the structure & behaviour of entities and their relationships.
Design Patterns¶ ↑
(('tag:center'))As we discuss previously, design patterns may be ((influenced)) by programming paradigms.
Design Patterns¶ ↑
(('tag:center'))Some design patterns can be very ((important)) or pale to ((insignificance)) due to language that we use.
Design Patterns¶ ↑
(('tag:center'))Design patterns can be categorized further.
Design Patterns¶ ↑
(('tag:center'))But first let us discuss about the last category of pattern.
properties¶ ↑
: hide-title true
Architectural Patterns¶ ↑
(('tag:center'))Architectural Patterns
properties¶ ↑
: hide-title true
Architectural Patterns¶ ↑
(('tag:center'))Architectural patterns on the other hand, are commonalities at ((*higher level*)) than design patterns.
Architectural Patterns¶ ↑
(('tag:center'))Architectural patterns are ((*high level strategies*)).
Architectural Patterns¶ ↑
Architectural patterns concerns:
-
Large-scale components
-
Global properties
-
Mechanism of a system
Architectural Patterns¶ ↑
(('tag:center'))One of the most well-known architectural pattern is the ((*MVC architecture*)).
MVC Architecture¶ ↑
(('tag:center'))MVC intents are to promote efficient code reuse and parallel development.
MVC Architecture¶ ↑
# image # src = images/mvc_sketch.png # keep_ratio = true # width = 550
MVC Architecture¶ ↑
(('tag:center'))It tries to solve the problem of tightly-coupled relation between UI codes and logic that hinders reusability.
MVC Architecture¶ ↑
(('tag:center'))It does so by separating codes into ((*three concerns*)): models, views and controllers.
MVC Architecture¶ ↑
(('tag:center'))Notice that we already discuss about the name, intent, sketch, problem and solution provided by a pattern.
Design Patterns Categories¶ ↑
(('tag:center'))Design Patterns Categories
properties¶ ↑
: hide-title true
Design Patterns Categories¶ ↑
(('tag:center'))In arguably the most influential book on design patterns (The ((*GoF book*))),
Design Patterns Categories¶ ↑
# image # src = images/design_patterns_gof.jpg # keep_ratio = true # height = 400
Design Patterns Categories¶ ↑
the authors categorize design patterns into three categoriesn
-
Creational
-
Structural
-
Behavioural
Creational Patterns¶ ↑
(('tag:center'))Creational Patterns
properties¶ ↑
: hide-title true
Creational Patterns¶ ↑
(('tag:center'))Creational patterns concern about object creation.
Creational Patterns¶ ↑
(('tag:center'))It ((abstract)) the ((instantiation)) process.
Creational Patterns¶ ↑
(('tag:center'))They help make a system ((independent)) on how its objects are created, composed and represented.
Creational Patterns¶ ↑
(('tag:center'))Useful when creating objects with particular behaviour ((*requires more*)) than simply instantiation a class.
Creational Patterns¶ ↑
(('tag:center'))Favour system that prefer to use ((*object composition*)) instead of class inheritance.
Creational Patterns¶ ↑
(('tag:center'))Example: Abstract Factory
Abstract Factory¶ ↑
(('tag:center'))Provide an interface for creating families of related or dependent objects without specifying their concrete class.
Abstract Factory¶ ↑
# image # src = images/abstract_factory.png # keep_ratio = true # width = 640
properties¶ ↑
: hide-title true
Structural Patterns¶ ↑
(('tag:center'))Structural Patterns
properties¶ ↑
: hide-title true
Structural Patterns¶ ↑
(('tag:center'))Structural patterns deal with the ((compositions)) of classes or objects to ((*form larger structures*)).
Structural Patterns¶ ↑
(('tag:center'))Example: Adapter
Adapter¶ ↑
(('tag:center'))((*Convert the interface*)) of a class into another interface clients expect.
Adapter¶ ↑
(('tag:center'))Adapter lets classes ((*work together*)) that ((*couldn't otherwise*)) because of incompatible interfaces.
Adapter¶ ↑
# image # src = images/adapter_pattern.png # keep_ratio = true # width = 550
properties¶ ↑
: hide-title true
Behavioural Patterns¶ ↑
(('tag:center'))Behavioural Patterns
properties¶ ↑
: hide-title true
Behavioural Patterns¶ ↑
(('tag:center'))Behavioural patterns characterize the way in which classes or objects ((interact)) and ((*distribute responsibility*)).
Behavioural Patterns¶ ↑
(('tag:center'))Not just patterns of classes and objects but also the patterns of ((communication)) between them.
Behavioural Patterns¶ ↑
(('tag:center'))Example: Observer or Pub-Sub
Observer¶ ↑
(('tag:center'))Define ((*one-to-many dependency*)) between objects.
Observer¶ ↑
(('tag:center'))When one object change state, all its ((*dependents are notified*)) and updated automatically.
Observer¶ ↑
# image # src = images/observer_pattern.png # keep_ratio = true # width = 720
properties¶ ↑
: hide-title true
Design Patterns Categories¶ ↑
(('tag:center'))There are no limits in defining design pattern categories, what we just discussed is just a (famous) example.
Utilizing Patterns¶ ↑
(('tag:center'))How to Utilize Patterns Properly?
properties¶ ↑
: hide-title true
Utilizing Patterns¶ ↑
(('tag:center'))Consider how patterns solve the problems
Utilizing Patterns¶ ↑
(('tag:center'))Scan intent and sketch sections
Utilizing Patterns¶ ↑
(('tag:center'))Study how patterns relate with each other
Utilizing Patterns¶ ↑
(('tag:center'))Study patterns of like purpose
Utilizing Patterns¶ ↑
(('tag:center'))Examine a cause of redesign
Utilizing Patterns¶ ↑
(('tag:center'))Consider what should be variable in your design
Anti-patterns¶ ↑
(('tag:center'))Anti-patterns
properties¶ ↑
: hide-title true
Anti-patterns¶ ↑
(('tag:center'))There are also patterns that have negative consequences when it is present in our software
Anti-patterns¶ ↑
(('tag:center'))It is called the ((anti-patterns))
Anti-patterns¶ ↑
(('tag:center'))Anti-patterns are common response to a recurring problem that is usually ((ineffective)) and risks being highly ((counterproductive)).
Anti-patterns¶ ↑
(('tag:center'))Example: Big ball of mud
Big ball of mud¶ ↑
(('tag:center'))Software system that ((lacks)) a perceivable ((architecture)).
Big ball of mud¶ ↑
(('tag:center'))Although undesirable from a software engineering PoV, such systems are common in practice.
Big ball of mud¶ ↑
(('tag:center'))Due to business pressure, developers turnover and code entropy.
Thanks¶ ↑
(('tag:center'))Thanks!
properties¶ ↑
: hide-title true
# Some extra notes
# Art of creating patterns # To divide up many pieces of advice into relatively independent chunks so that you can refer to them and discuss them more or less separately
# Some common causes of redesign: # - Creating an object by specifying a class explicitly # - Dependence on specific operations # - Dependence on hardware or software platform # - Dependence on object representations or implementations # - Algorithmic dependencies # - Tight coupling # - Extending functionality by subclassing # - Inability to alter class conveniently
# Patterns are sometimes embedded in framework: # - People who know the patterns gain insight into framework faster # - People who don't know get benefit from patterns that was enforced by the framework