SDP Lab

Dr. Md Samiullah
Assistant Professor
Department of Computer Science and Engineering
University of Dhaka
Outline
● Classical Mistakes in Software Engineering
● Software Engineering Principles
● Introduction to Software Design Patterns
● List of Patterns
● Patterns to be covered in this lab
Classical Mistakes in Software Engineering
● Undermined motivation

● Uncontrolled problem employees

● Noisy, Crowded Office

● Abandoning planning under pressure

● Shortchanging upstream activities

● Shortchanging quality assurance to improve development speed

Classical Mistakes in Software Engineering …
● Lack of feature-creep control

● Silver-bullet syndrome

● Wasting time in the “fuzzy front end.”

● Insufficient user input

● Overly aggressive schedules

● Adding developers to a late project

Classical Mistakes in Software Engineering …
● Burden your best/mighty employee

● Ignoring the estimated time

● No risk management

● Accumulating work loads in later stages on failing to catch earlier ones

● Not using version control system

● ………
Software Engineering Principles
● KISS (Keep It Simple Stupid)

● DRY (Don’t Repeat Yourself)

● YAGNI (You Are Not Gonna Neet It)

● To change a class there should never be more than one reason

● Favor object composition over inheritance

● Program to an interface not an implementation

Software Engineering Principles …
● SOLID
○ Single responsibility (One class/method one responsibility)

○ Open Close Principle (Open for extension Close for Modification)

○ Liskov’s Substitution (Objects should be replaceable by instances of its

subtype - Polymorphism)

○ Interface Segregation (Client-specific interfaces are better than one

general-purpose interface)

○ Dependency Inversion (Depend on Abstraction not on concrete classes)

Law’s of Software Development
● If something goes wrong, it will

● Any piece of software reflects the organizational structure that produced it

● Be conservative in what you send, be liberal in what you accept

● 80% of consequences stem from 20% of the causes

● Given enough eyeball, all bugs are shallow

● First 90% of the code takes 10% of the time

● Premature optimization is the root of all evil

Introduction to Software Design Patterns

● Design patterns represent the best practices used by experienced object-oriented

software developers.
● Design patterns are solutions to general problems that software developers faced
during software development.
● These solutions were obtained by trial and error by numerous software developers
over quite a substantial period of time.
● Two usages:
○ Best practices
○ Common Platform for developers
Types and List of Patterns
● Creational Patterns
○ Abstract Factory ○ Prototype
○ Builder ○ Singleton
○ Factory Method
● Structural Patterns
○ Adapter ○ Facade
○ Composite ○ Flyweight
○ Bridge ○ Proxy
○ Decorator
● Behavioral Patterns
○ Chain of Responsibility ○ Memento
○ Command ○ Observer
○ Interpreter ○ State
○ Iterator ○ Strategy
○ Mediator ○ Template Method
● J2EE Patterns ○ Visitor
Simple Factory
Scenario:
A man planned to sell two kinds of pizzas, i.e., Veggie and Cheese. All pizzas
need some elements, e.g. dough, sauce and toppings. The pizzas become
popular and customers are looking for chicken, beef and other types too.

The problem to be solved:

We need a system that is ever extensible and cope up with the changes of
requirement by customers.
Simple Factory …

ছিব ১: অ্যাবস্ট্রাক্ট িপৎজা সুপার ক্লাস।

Simple Factory …

ছিব ২: শুধু চীজ টিপংস দয়া চীজ িপৎজা

ছিব ৩: বিশ বিশ সবিজ িদেয় বানােনা ভিজ িপৎজা

Simple Factory …

ছিব ৪: দাকােন অডর্তিার নয়ার জন্য লখা ক্লাস আর তার মথড

Simple Factory …
Requirement change alert: A set of new changes comes in. Customers are
looking for other types of pizzas, e.g., Beef, Chicken, and etc.

Solution:
Definitely we need separate new subclasses for other types of pizzas. Along
with a new “else if” in the method “orderPizza” in the class
“OriginalPizzaGhor”.

HOWEVER, THIS IS NOT A GOOD STRATEGY.

HOW TO ALLOW THE NEW CHANGES WITHOUT STOPPING THE WORKING SYSTEM/CODE.
Simple Factory …

ছিব ৫: িসম্পল ফ্যাক্টির - যখােনই তরী হেব সব মজার িপৎজা

Simple Factory …

ছিব ৬: নতু ন িপৎজা ঘর কাড। িপৎজা এখন ফ্যাক্টির থেক বািনেয় আনা হয়।
Simple Factory …

This is not a Design pattern !?!?

(Honorable mention for a Design Pattern: Head First Design Pattern)

This is a technique to “Separation of Concern”

Factory Method
Scenario:

A friend of the pizza shop owner want a franchise for another city, say, “Sylhet”. He
wants a little change though in the condiments of pizza and elements. A little
thicker dough,more cheese and pieces of “Satkora”.

So, pizza from your factory will not be popular (will not work) in Sylhet.

Solution: GIVE THE PIZZA RECIPE TO YOUR FRIEND AND ALLOW HIM TO
MAKE SOME CHANGES AS HE FIND SUITABLE.
Factory Method …

ছিব ৭: সাতকরা দয়া িসেলটি ভিজ িপৎজা

Factory Method …
Requirement change alert: (i) The sylhetty pizza house is a large place and
they don’t need a separate factory.
(ii) Your customers like fresh and in-house (pizza house) bake pizzas.
(iii) You change your mind to open several branches in your current city,
“Dhaka”.

Solution:
Now, the factory is no more needed. Location-wise different pizzas will be
baked by different subclasses.
Factory Method …

ছিব ৮: অ্যাবস্ট্রাক্ট িপৎজা ঘর। অডর্তিার কাড আেগরটাই, িকন্তু য যার িপৎজা িনেজরাই বানােব
Factory Method …

ছিব ৯: িসেলটি িপৎজা ঘর! "আমরার িফৎজা আমরাউ বানাইমু"

Factory Method …

ছিব ১০: পিরবিতর্তি ত মূল িপৎজা ঘেরর কাড।

Abstract Factory
Scenario:

Everything was going well. A greedy manager started mixing some low quality
materials and degrading the quality of the pizzas. How to make sure a controlled
change in subclasses? Another friend from “Noakhali” wants a franchise. How to
ensure high quality in all the branches (subclasses)?

Solution:

Ask your friends/managers not to do that?

Abstract Factory …

● Elements and condiments have to be of a specific/defined brand/type

● Making it mandatory for all subclasses is called Abstract Factory.

Abstract Factory …
Abstract Factory …
Decorator
● Joshua Bloch: Composition should be preferred over inheritance

● Inheritance vs composition
Decorator … (How inheritance may introduce problem?)
● Introduces dependency

● Less control over the inherited code

● Example:

○ The HashSet Class has a method “size()” that return the elements in a hashSet

○ HashSet keeps unique elements and duplicate entries are not inserted

○ Say, we want to count the number of attempts to add numbers instead of the number of

elements in the set

○ How can we code this?

Decorator … (How inheritance may introduce problem?)
● Implement own class by extending HashSet and override Add() and AddAll()
methods!!!
Decorator … (How inheritance may introduce problem?)

● Looks all good?

● There will be a problem in Calling “AddAll()”
● AddAll() of subclass increase the count and the supe class
AddAll() calls its own Add() method inherently
● The problem is by “dynamic dispatch”, Add() of subclass is called
that increase the count again
● Solution???
○ Don’t override AddAll()
○ All good?- Not yet !!!
○ If in a new release of Java, the AddAll() method in HashSet is changed, then
…
Decorator … (How inheritance may introduce problem?)

● More problems:
○ If HashSet class gets a new method addFront(),
■ it subclass needs an overridden method
○ If subclass has a method not available in HashSet and later
HashSet gets such a method
■ The subclass will not compile unless “@override” is not
added

● So, always keep an eye on the superset

○ Such dependency is the worst nightmare of a developer
Decorator …
Decorator …
Decorator …
Composite
When a structure or scenario can be thought recursively as a tree, it must be
implemented or solved with a composite design pattern.

Scenario:
● First imagine a building that can be entered and exited through a door.
○ Buildings may have multiple floors.
● A floor like a building can be entered or exited (perhaps through an elevator) door.
○ Each floor can have several rooms.
● Each room can be entered or exited through its door.
Thus, a building can be thought of as a composite or combination of different floors and
rooms. Similarly, a floor can be thought of as a composite of several rooms. But a room is
just a room, no need to think of a room as a composite. A room is a leaf node here in a
hierarchy tree.
Composite …
Another scenario:
Let's say you are implementing a playlist of songs in Java.
Requirement: A playlist will contain many songs. But a playlist can also contain another
playlist.
● A playlist (where many songs are listed), and a single song - what can be the
common function between these two?
○ Both can actually be 'played'.
● Think of the attributes, the common attribute would be name.
○ Because just like a song has a name, we can give a playlist a name (like a playlist of patriotic songs).
● What can be the different functions or attributes between the two
○ A song can be 'added' or 'removed' in the playlist.
○ A song has a singer (singer name), a playlist does not have a singer.
Composite …
Composite …
Composite …
Composite …

The Composite Patter allows you to compose

objects into tree structures to represent part-whole
hierarchies. Composite lets clients treat individual
objects and compositions of objects uniformly
Singleton
A class that should have only one object is called Singleton.

Scenario:

Any system usually needs only one database controller or file management
controller. Their implementation is done using the singleton design pattern.
Singleton …
Singleton …
Singleton …
Singleton …
Singleton …
Singleton …
Observer
Scenario:

A celebrity comes live quite often on FB and you want to know about such live
sessions asap. Your option is to “Like” his page. Otherwise, you have to check
time-to-time in his page for an update or latest videos. In this scenario, you may
also miss some live sessions.

How is this like/subscribe/Bell-icon systems work and implemented?

Observer …
● There are two actors/roles
○ Subject (Celebrity)
○ Observer (Follower)

● Subject needs
○ A register method
○ An unregister method
○ Notify all

● Observer
○ An update method to get notifications
Observer …

ছিব ১: জাভা ইন্টারেফস - িনয়ম ঠিক কের দয়ার দািয়ত্ব যার।

ছিব ২: ব্যািরস্টিার সুমেনর ফইসবুক পইজ যভােব Subject - ক ইমিপ্লিেমন্ট কের
Observer …
Observer …

ছিব ৩: পাগলােট ফ্যােনর পইজ

Observer …

ছিব ৪: টিস্টিং কাড।

Observer …

ছিব ৫: কােডর আউটপুট। মজনু- মিফজ িজন্দাবাদ!

Conclusions
● Three (3) assessed tasks for the lab

● Learn other patterns if needed

● Solve the problems:

○ Find appropriate patterns to solve the problems

○ Draw UML diagrams to design the solution
○ Implement using Java, C++, or Python
○ Draw Class diagram
○ Write reports
References
1. https://stevemcconnell.com/articles/classic-mistakes/

2. https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

3. GOF (Gang of Four)

4. HFDP (Head First Design Pattern)

5. Ishtiaque bhai’s blog-post