Application Development Flashcards
there are three (3) important characteristics of a bad design architecture that should be avoided:
Rigidity, Fragility, Immobility
The software is hard to change because every applied change will affect many parts of the software.
Rigidity
When applying changes, unexpected parts of the software breaks..
Fragility
The modules of the software are hard to reuse ins another software because these cannot be extracted from
the current software
Immobility
s are a set of guidelines
to be followed that helps developers arrange methods and data structures into classes,
Design principles
Martin assembled a set of five (5) software design principles, and Michael Feathers arranged these principles into an acronym
called SOLID.
(SRP), (OCP) , (LSP) , (ISP) , (DIP)
S-O-L-I-D
(SRP), (OCP) , (LSP) , (ISP) , (DIP)
This is one of the basic principles most developers apply to build robust and
maintainable software.
S: Single Responsibility Principle (SRP)
This suggests that each software module, class, or interface should have only one (1) reason to
change.
S: Single Responsibility Principle (SRP)
This states that for a software to be easy to change,
O: Open-Closed Principle (OCP)
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.
O: Open-Closed Principle (OCP)
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.
L: Liskov Substitution Principle (LSP)
This principle advises software designers to avoid depending on things that they don’t use.
I: Interface Segregation Principle (ISP)
This principle suggests that flexible software are those with classes that depend on abstract classes or interfaces.
D: Dependency Inversion Principle (DIP)
The blank instructs developers to design each module, interface, or class of a software system to
have only one (1) responsibility.
Single Responsibility Principle (SRP)
The accounting personnel is responsible
for computing the salary of an employee.
It should use the calculatePay()
method
Single Responsibility Principle (SRP)
The human resource personnel is
responsible for creating a report of hours
of an employee. It should use the
reportHours() method.
Single Responsibility Principle (SRP)
The database administrator is
responsible for saving an employee’s
details. It should use the
saveEmployee() method.
Single Responsibility Principle (SRP)
The blank states that software modules, interfaces, or classes should be open for extension but closed
for modification.
Open-Closed Principle (OCP)
For every newly added method, the unit testing of the software should
be done again.
Open-Closed Principle (OCP)
When a new requirement is added, the maintenance and adding
function may take time.
Open-Closed Principle (OCP)
Adding a new requirement might affect the other functionality of
software even if the new requirement works.
Open-Closed Principle (OCP)
To blank , use an interface,
an abstract class, or abstract methods to
extend the functionality of the class
Implement the OCP
The blank suggests that when creating a new derived class of an existing class, make sure that the
derived class can be a substitute for its base class.
Liskov Substitution Principle (LSP)
The blank should be extended to the level of architecture. A simple violation of substitution can cause a system’s architecture to
break.
LSP
The blank suggests avoiding depending on things that are not used.
Interface Segregation Principle (ISP)
This means that clients
should not be forced to implement interfaces they don’t use. I
Interface Segregation Principle (ISP)
The blank suggests that the most flexible software systems are those in which source code
dependencies refer only to abstractions, not to concretions.
Dependency Inversion Principle (DIP)
software engineer, blank are the reusable solutions to commonly occurring problems in software design.
design patterns
Design patterns are said to have four (4) essential features:
Pattern Name, Problem, Solution, Consequences
This is the name of a pattern that can be used to describe a design problem, its solution, and consequences.
Pattern Name
This describes when to use the pattern. It explains the problem and its context.
Problem
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.
Solution
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.
Consequences
3 Categories of Patterns
Creational Patterns, Structural Patterns, Behavioral Patterns
These patterns deal with when and how objects are created. These provide object creation
mechanisms that increase flexibility and reuse of existing codes.
Creational 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.
Structural Patterns
These describe how responsibilities are distributed between objects in the design and how communication happens between objects.
Behavioral Patterns
are all about class instantiation. These are patterns that deal with object creation mechanisms, trying
to create objects in a manner suitable to a certain situation.
Creational design patterns
This design pattern lets developers ensure that a class has only one (1) instance while providing a global
access point to the instance.
Singleton Pattern
Ensure that a class has just a single instance. This is to control access to some shared resource—for example, a database
or a file.
Singleton Pattern
. Make the default constructor private to prevent other objects from using the new operator with a Singleton class
Singleton Pattern
the Singleton class declares the static method
getInstance() that returns the same instance of its own class.
Singleton Pattern
This provides an interface for creating objects in a superclass but allows subclasses to alter the
type of object that will be created.
Factory Method Pattern
A developer is creating a logistics management application.
Factory Method Pattern
The Factory Method pattern suggests that he replace direct object construction using the new operator with calls to a
special factory method.
Factory Method Pattern
Product declares the interface, which is
common to all objects that can be produced by the
creator and its subclasses.
Factory Method Pattern
This creational design pattern lets a developer copy existing objects without making his code
dependent on their classes
Prototype Pattern
When a developer wants to create an exact copy of an object, s/he has to create a new object of the same class.
Prototype Pattern
The Prototype pattern delegates the cloning process to the actual objects being cloned
Prototype Pattern
, the Prototype interface declares the cloning methods. In
most cases, it is a single clone method.
Prototype Pattern
This allows developers to produce families of related objects without specifying their concrete classes.
Abstract Factory Pattern
A developer is creating a furniture shop simulator.
Abstract Factory Pattern
Explicitly declare interfaces for each distinct product of the product family.
Abstract Factory Pattern
the Abstract Products declare
interfaces for a set of distinct but related
products which make up a product family.
Abstract Factory 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.
Builder Pattern
When creating an object that requires complex step-by-step initialization of many fields and nested objects, the
initialization of an object will usually contain lots of parameters or will scatter all over the client code.
Builder Pattern
The Builder design pattern suggests that developers must extract the object construction code out of its own class and
move it to separate objects called builders.
Builder Pattern
the Builder interface declares product construction
steps that are common to all types of builders. ConcreteBuilder
classes provide different implementations of the construction steps.
Builder Pattern
deal with the arrangement and relationship between the classes in the software system.
Structural design patterns
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
Adapter Pattern
For example, a developer developed a stock monitoring software for a certain client.
Adapter Pattern
In the Adapter pattern, a developer can create a special object called adapter that converts the interface of one (1) object
so that another object can understand it
Adapter Pattern
the Client class contains the existing business
logic of the program.
Adapter 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
Bridge Pattern
For example, a developer created a Shape class with a pair of subclasses: Circle and Square.
Bridge Pattern
The given problem occurs because the developer is trying to extend the shape classes in two (2) different dimensions: by
form and by color.
Bridge Pattern
the Abstraction provides high-level
control logic. It relies on the implementation object
to do the actual low-level task.
Bridge Pattern
Composite Pattern – This design pattern allows developers to compose objects into tree structures and then work with
these structures treating them as individual objects
Composite Pattern
A developer created two (2) types of objects named Products and Boxes.
Composite Pattern
The Composite pattern suggests that a developer must work with Products and Boxes through a common interface which
declares a method for calculating the total price.
Composite Pattern
the Component interface describes operations that are common
to both simple and complex elements of the tree.
Composite Pattern
This allows developers to attach new behaviors to objects by placing these objects inside special
wrapper objects that contain the behaviors
Decorator Pattern
A developer is working on a notification library that lets other programs notify their users about important events.
Decorator Pattern
The Decorator pattern suggests creating a wrapper object that can be linked with some target object.
Decorator Pattern
the Component declares the common interface for
both wrappers and wrapped objects.
Decorator Pattern
This provides a simplified interface to a library, a framework, or any other complex set of classes
Facade Pattern
A developer is creating a code that works with a broad set of objects that belong to a sophisticated library or framework.
Facade Pattern
A facade is a class that provides a simple interface to a complex subsystem which contains lots of moving parts.
Facade Pattern
the provides convenient access to a particular part of the subsystem’s functionality. It knows where
to direct the client’s request and how to operate all the moving parts.
Facade 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
Flyweight Pattern
A developer creates a video game with realistic particle system of multiple bullets, missiles, and explosions
Flyweight Pattern
The Flyweight pattern suggests creating an object that is divided into two (2) parts: the state-dependent part and the stateindependent part.
Flyweight Pattern
the pattern is merely an
optimization. Before applying it, make sure that a
program does have the RAM consumption problem
related to having a massive number of similar objects
in memory at the same time.
Flyweight Pattern
This design pattern allows developers to provide a substitute or placeholder for another object.
Proxy Pattern
controls access to the original object, allowing developers to perform something before or after the requests gets through
to the original object
Proxy Pattern
Developers want to control access to an object. For example, a developer
has a large object that consumes a tremendous amount of system
resources
Proxy Pattern
The Proxy pattern suggests creating a new proxy class with the same
interface as an original service object and updating the application
Proxy Pattern
the Service Interface declares the interface of the Service. The proxy must follow this interface to be
able to disguise itself as a service object.
Proxy Pattern
are concerned with how classes and objects behave in a system software and how objects
communicate with each other
Behavioral design patterns
This design pattern allows developers to traverse elements of a collection without exposing its underlying
representation, such as list, stack, and tree.
Iterator Pattern
A developer is creating a system with a search feature.
Iterator Pattern
The main idea of the Iterator pattern is to extract the search behavior of a collection into a separate object called an
iterator
Iterator Pattern
the Iterator interface declares the operations
required for traversing a collection: fetching the next element,
retrieving the current position, restarting iteration, etc.
Iterator 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
Observer Pattern
A developer created two (2) types of objects named Customer and Store
Observer Pattern
The object that notifies other objects about the changes to its state is called publisher
Observer Pattern
the Publisher class issues events of interest to
other objects.
Observer Pattern
This allows developers to define a family of algorithms, put each of them into a separate class, and make
their objects interchangeable.
Strategy Pattern
A developer created a navigation application for travelers
Strategy Pattern
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
Strategy Pattern
the Context class maintains a reference to
one of the concrete strategies and communicates with this
object only through the Strategy interface
Strategy Pattern
