APP DEV MIDTERM REVIEWER

• Rigidity – The software is hard to change because every applied change will affect many parts
of the software.

• Fragility – When applying changes, unexpected parts of the software breaks.

• Immobility – The modules of the software are hard to reuse ins another software because
these cannot be extracted from the current software.

• Design principles - are a set of guidelines to be followed that helps developers arrange
methods and data structures into classes, and how those classes should be interconnected,
which can adapt to the changes in requirements without major code rewrite.

• SOLID Principles of object-oriented design are applied to software development projects to

make software easier to change when requirements changes.

• Single Responsibility Principle (SRP) – This is one of the basic principles most developers
apply to build robust and maintainable software. This suggests that each software module,
class, or interface should have only one (1) reason to change.

• Open-Closed Principle (OCP) – This states that for a software to be easy to change, the
software classes must be designed to allow the behavior of those classes to be changed by
adding new code rather than changing existing code.

• Liskov Substitution Principle (LSP) – Barbara Liskov introduced this principle which states
that the derived classes should be substitutable for their base classes to build a software
from interchangeable modules or classes.

• Interface Segregation Principle (ISP) – This principle advises software designers to avoid
depending on things that they don’t use.

• Dependency Inversion Principle (DIP) – This principle suggests that flexible software are
those with classes that depend on abstract classes or interfaces

A. High-level classes should not be dependent on low-level classes. Both of them

should depend on abstractions. This means a high-level class is a class that does
something significant in the application, while a low-level class is a class that does
secondary work.

B. Abstractions should not depend upon details. Details should depend upon
abstractions. This means that developers must design the abstract class by looking at
the needed details of the class.
 • Design Patterns
o Are the reusable solutions to commonly occurring problems in software design.
o Are used as templates or blueprints that any developer can customize to solve a
recurring design problem on codes.
o Are not a specific piece of code, but a general concept for solving a particular
problem.

• Pattern Name – This is the name of a pattern that can be used to describe a design problem,
its solution, and consequences.

• Problem – This describes when to use the pattern. It explains the problem and its context.

• Solution – This describes the elements that make up the design, their relationships,
responsibilities, and collaborations. The pattern provides an abstract description of a design
problem and how a general arrangement of element solves it.

• Consequences – These are the results and interchanges of applying the pattern to the
problem. They include time and space tradeoffs, but also flexibility, extensibility, and
portability, among others.

Categories of Patterns

• Creational Patterns – These patterns deal with when and how objects are created. These
provide object creation mechanisms that increase flexibility and reuse of existing codes.

• Structural Patterns – These describe how objects are composed into larger groups and
explain how to assemble objects and classes into larger structures while keeping their
structures flexible and efficient.

• Behavioral Patterns – These describe how responsibilities are distributed between objects
in the design and how communication happens between objects.

Creational Patterns:

• Singleton Pattern – This design pattern lets developers ensure that a class has only one (1)
instance while providing a global access point to the instance.

• Factory Method Pattern – This provides an interface for creating objects in a superclass but
allows subclasses to alter the type of object that will be created.

• Prototype Pattern – This creational design pattern lets a developer copy existing objects
without making his code dependent on their classes.
 • Abstract Factory Pattern - This allows developers to produce families of related objects
without specifying their concrete classes. A family of objects that are usually used together
or a set of objects that are dependent on each other in some way.

• Builder Pattern – This creational design pattern allows developers to construct complex
objects step by step. The pattern allows developers to produce different types and
representations of an object using the same construction code.

Structural Pattern:

• Adapter Pattern – This structural design pattern allows objects with incompatible interfaces
to collaborate. This pattern converts the interface of a class into another interface as
expected by the client application.

• Bridge Pattern – This allows the developers to split a large class or a set of closely related
classes into two (2) separate hierarchies, which are abstraction and implementation, that
can be developed independently of each other.

• Composite Pattern – This design pattern allows developers to compose objects into tree
structures and then work with these structures treating them as individual objects.

• Decorator Pattern – This allows developers to attach new behaviors to objects by placing
these objects inside special wrapper objects that contain the behaviors.

• Facade Pattern – This provides a simplified interface to a library, a framework, or any other
complex set of classes.

• Flyweight Pattern – This allows developers to fit more objects into the available amount of
RAM by sharing common parts of state between multiple objects instead of keeping all of the
data in each other.

o The state stored inside a flyweight is called “intrinsic.” The state passed to the
flyweight’s methods is called “extrinsic.”

• Proxy Pattern – This design pattern allows developers to provide a substitute or placeholder
for another object. A proxy controls access to the original object, allowing developers to
perform something before or after the requests gets through to the original object.
Behavioral Pattern:

• Iterator Pattern – This design pattern allows developers to traverse elements of a collection
without exposing its underlying representation, such as list, stack, and tree. This pattern is
used for sequentially iterating and accessing items from a collection of items.

• Observer Pattern – This design pattern allows developers to define a subscription

mechanism to notify multiple objects about any events that happen to the object they are
observing. This means that when an object changes state, all of its dependents are notified
and updated automatically.

o The object that notifies other objects about the changes to its state is called
publisher.
o All other objects that want to track changes to the publisher’s state are called
subscribers.

• Strategy Pattern – This allows developers to define a family of algorithms, put each of them
into a separate class, and make their objects interchangeable.

o The Strategy pattern suggests defining the class that does a specific task in several
different methods and extracts all of these algorithms into separate classes called
strategies.

o The original class called context must have a field of storing a reference to one of the
strategies.