BLIDA University, Algeria Faculty of Science, Department of Computer Science

Implementation methods and

technologies
SIR M1 S1
Mm ZERF Nadjat
n_zerf@esi.dz
2023/2024
 Outline…
➢Software Engineering
➢Design Patterns
➢Reminder: Object Oriented Programming (OOP)
Software engineering
• Process of designing and
creating software.
• This includes all stages of the
software:
• Planning and analysis process,
• design,
• Implementation,
• Deployment, maintenance,
• testing.
Software engineering
 Components of Software Engineering
• Describe: requirements, specifications, documentation...
•Implement: modeling, programming,
• Assess: testing and other V&V techniques,
• Manage: plans, schedules, communication,
• Operate: deployment, installation...
 Software Engineers
• Use of modeling techniques distinguishes a software
engineer from a programmer.
• The earlier you start to code the longer it takes to complete
the program.
• A good modeler is a good programmer; a good programmer is
not always a good modeler.
• Learning a programming language is easy, learning how to
program is difficult.
• Software engineers are problem solvers at heart.
 Model…
•A model represents reality for a given purpose;
the model is an abstraction of reality in the
sense that it cannot represent all aspects of
reality.
•This allows us to deal with the world in a
simplified manner, avoiding the complexity,
danger, and irreversibility of reality.
 What is a Design Pattern?
➢"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“. Christopher Alexander, A Pattern
Language.

➢"A pattern is a recurring solution to a problem

in a context."
 In software engineering…
▪Design pattern is a general repeatable solution to a
commonly occurring problem in software design.
• It is a description or template for how to solve a problem that
can be used in many different situations
• It describes how to structure our code to solve common
design problems using best practices.
• It is important to note that a design pattern is a high-level
solution; it doesn't focus on implementation details such as
algorithms and data structures
A pattern has four essential elements…
1. The pattern name. Helps in building the pattern vocabulary.
2. The problem. Explains the problem and its context.
3. The solution.
• Describes the elements that make up the design, their
relationships, responsibilities, and collaborations.
• It doesn't describe a particular concrete design or
implementation, because a pattern is like a template that can
be applied in many different situations.
4. The consequences. The results and trade-offs of applying the
pattern are critical for evaluating design alternatives and for
understanding the costs and benefits of applying the pattern.
Design Pattern Classification Gangs of Four (GoF)

•By purpose…reflects what a pattern does.

➢Creational patterns
➢Structural patterns
➢Behavioral patterns
•By scope …specifies whether the pattern applies
primarily to classes or to objects.
➢Class Patterns
➢Object Patterns
Purpose Classification…Gangs of Four (GoF)
Creational patterns:
• To facilitate the work of creating, initializing, representing, and
configuring objects and classes.
• Create things: other classes, interface implementations, attributes, or
any other structural type.
• They basically act as factories, builders, configuration constructs, or
class initializers.
• These types of patterns are useful when we need to render instances of
objects, store these objects, perform complex initialization of objects,
or create copies of objects.
❑Use Class Diagram.
Purpose Classification… Gangs of Four (GoF)

Structural patterns
• To facilitate the work of changing the structural
associations of classes, class associations, and
hierarchies of class structures.
• Provide mechanisms to organize classes and objects to
build larger structures of the software.

❑Use Class Diagram

Purpose Classification… Gangs of Four (GoF)
Behavioral patterns
• Facilitate the work of algorithmic calculations and communication
between classes and objects (objects interact and distribute
responsibility).
• They define and produce process and run-time flow and identify
hierarchies of classes and when and where they become instantiated
in code.
➔Define class instance and state,
➔Hand off work from one class to another,
➔Provide placeholders for other functionality.
❑Use inheritance heavily to control code flow➔ Use Class Diagram
and Sequence Diagram.
Scope Classification … Gangs of Four (GoF)

➢Class Patterns➔ Inheritance

▪Deal with relationships between classes and their
subclasses.
▪These relationships are established through
inheritance, so they are static—fixed at compile-time.
➢Object Patterns➔ Composition
▪Deal with object relationships, which can be changed at
run-time and are more dynamic.
 Use patterns…
➢Patterns are best used to communicate that you are
following a well-understood design approach .
➢Don't implement a pattern if your language supports a
direct solution.
➢Don't try to retrofit everything in terms of patterns.
➢Use a pattern only if it is the most elegant solution in your
context.
➢Don't be afraid to create new patterns.
Why use design patterns?
1) Speed the development process by applying a proven solution to a
common problem.
2) Using design patterns can prevent the occurrence of delicate issues
which in return can cause major defects.
3) Simplify the maintainability of the system.
4) Improve your code quality.
5) Ease the complexity of code readability and understandability since
every developer should be familiar with them.
6) Using design patterns can facilitate the communication and
collaboration between team members and can ease integration
since they are well-known, common, and easy to recognize.
How to apply patterns to specific
problems…
Before Diving Into the Design Patterns
• What is good software design?
• How would you measure it?
• What practices would you need
to follow to achieve it?
• How can you make your
architecture flexible, stable and
easy to understand?
 Features of Good Design Pattern
Code reuse / Flexibility
• Cost and time are two of the most valuable metrics when
developing any software product. Code reuse is one of the
most common ways to reduce development costs.
• Instead of developing something over and over from scratch,
why don’t we reuse existing code in new projects?

• Tight coupling between components, Reduce the flexibility of

• Dependencies on concrete classes instead of
the code and make it
interfaces,
• Hardcoded operations harder to reuse it.
 Features of Good Design Pattern
2. Extensibility / Maintainability
• The ability to extend software and the level of effort required
to implement the extension.
• Extensions can be through the addition of new functionality
or through modification of existing functionality.
• Change is the only constant thing in a programmer’s life.
Design Pattern Principles
1. Encapsulation
• Identify the aspects of your application that vary and separate
them from what stays the same.
• Minimize the effect caused by changes.
Problem: Imagine that the program is a ship, and changes are mines
that linger underwater. Struck by the mine, the ship sinks.
Solution: We can divide the ship’s hull into independent
compartments that can be safely sealed to limit damage to a single
compartment. Now, if the ship hits a mine, the ship as a whole
remains afloat.
Design Pattern Principles
Encapsulation on a method level
 Design Pattern Principles
Encapsulation on a class level
 Design Pattern Principles
2. Program to an Interface, not an Implementation
• Depend on abstractions, not on concrete classes.
• The design is flexible if you can easily extend it without breaking any existing
code.
• Working with objects through interfaces is more beneficial than depending
on their concrete classes.
• Example:
if cond1: obj = new A();
elseif cond2: obj = new B();
elseif cond3: obj = new C() ;
Design Pattern Principles
➢Concrete Class vs Abstract Class?
• Concrete Class has all its methods implemented.
• Concrete classes can extend abstract class or implement
interfaces but they must implement all the methods of
the abstract class or interface they inherit.
• A concrete class is an abstract class if it has even one
abstract method.
 Design Pattern Principles
➢Example:
Problem: The Company class
is tightly coupled to concrete
classes of employees.
Solution: We can generalize
various work-related
methods and then extract a
common interface for all
employee classes.
 Design Pattern Principles
Problem: The Company class
remains coupled to the
employee classes.
Solution: We declare the
method for getting employees
as abstract. Each concrete
company will implement this
method differently, creating
only those employees that it
needs.
 Design Pattern Principles
➢Achieve code reuse and
extensibility
• We can extend this class and
introduce new types of
companies and employees
while still reusing a portion
of the base company class.
• Extending the base company
class doesn’t break any
existing code that already
relies on it.
Design Pattern Principles
3. Favor Composition Over Inheritance
Inheritance represents the “is a” relationship
between classes.
➢Inheritance problems
- A subclass can’t reduce the interface of the
superclass.
- There is a lot of duplicate code between
subclasses.
- Subclasses are tightly coupled to superclasses.
- Inheritance breaks the encapsulation of the
superclass
- When overriding methods you need to make sure
that the new behavior is compatible with the base
one.
 Design Pattern Principles
3. Favor Composition Over Inheritance
The composition represents the “has a”.
Solution: We can solve these problems with
composition and aggregation.
• Instead of car objects implementing a behavior on
their own, they can delegate it to other objects.
• The added benefit is that you can replace a behavior
at runtime.
• You can replace an engine object linked to a car
object just by assigning a different engine object to
the car.