Application Development Flashcards by Hot Dog

there are three (3) important characteristics of a bad design architecture that should be avoided:

Rigidity, Fragility, Immobility

How well did you know this?

Not at all

Perfectly

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

Rigidity

How well did you know this?

Not at all

Perfectly

When applying changes, unexpected parts of the software breaks..

Fragility

How well did you know this?

Not at all

Perfectly

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

Immobility

How well did you know this?

Not at all

Perfectly

s are a set of guidelines
to be followed that helps developers arrange methods and data structures into classes,

Design principles

How well did you know this?

Not at all

Perfectly

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)

How well did you know this?

Not at all

Perfectly

S-O-L-I-D

(SRP), (OCP) , (LSP) , (ISP) , (DIP)

How well did you know this?

Not at all

Perfectly

This is one of the basic principles most developers apply to build robust and
maintainable software.

S: Single Responsibility Principle (SRP)

How well did you know this?

Not at all

Perfectly

This suggests that each software module, class, or interface should have only one (1) reason to
change.

S: Single Responsibility Principle (SRP)

How well did you know this?

Not at all

Perfectly

This states that for a software to be easy to change,

O: Open-Closed Principle (OCP)

How well did you know this?

Not at all

Perfectly

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)

How well did you know this?

Not at all

Perfectly

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)

How well did you know this?

Not at all

Perfectly

This principle advises software designers to avoid depending on things that they don’t use.

I: Interface Segregation Principle (ISP)

How well did you know this?

Not at all

Perfectly

This principle suggests that flexible software are those with classes that depend on abstract classes or interfaces.

D: Dependency Inversion Principle (DIP)

How well did you know this?

Not at all

Perfectly

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)

How well did you know this?

Not at all

Perfectly

The accounting personnel is responsible
for computing the salary of an employee.
It should use the calculatePay()
method

Single Responsibility Principle (SRP)

How well did you know this?

Not at all

Perfectly

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)

How well did you know this?

Not at all

Perfectly

The database administrator is
responsible for saving an employee’s
details. It should use the
saveEmployee() method.

Single Responsibility Principle (SRP)

How well did you know this?

Not at all

Perfectly

The blank states that software modules, interfaces, or classes should be open for extension but closed
for modification.

Open-Closed Principle (OCP)

How well did you know this?

Not at all

Perfectly

For every newly added method, the unit testing of the software should
be done again.

Open-Closed Principle (OCP)

How well did you know this?

Not at all

Perfectly

When a new requirement is added, the maintenance and adding
function may take time.

Open-Closed Principle (OCP)

How well did you know this?

Not at all

Perfectly

Adding a new requirement might affect the other functionality of
software even if the new requirement works.

Open-Closed Principle (OCP)

How well did you know this?

Not at all

Perfectly

To blank , use an interface,
an abstract class, or abstract methods to
extend the functionality of the class

Implement the OCP

How well did you know this?

Not at all

Perfectly

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)

How well did you know this?

Not at all

Perfectly

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