Design Patterns Final

Front 1

Category: Interface Patterns

Back 1

Adapter

Facade

Composite

Bridge

Front 2

Category: Responsibility Patterns

Back 2

Observer

Singleton

Chain of Responsibility

Flyweight

Mediator

Front 3

Category: Construction Patterns

Back 3

Factory

Builder

Proxy

Abstract Factory

Prototype

State(?)

Front 4

Adapter Pattern

Back 4

Combines ability of two separate interfaces. A bridge between 2 incompitable interfaces.

Front 5

Facade Pattern

Back 5

Used to hide complexity of the system. Provides a simple interface to make the subsystem easy to use.

"Simplifier"

Front 6

Composite Pattern

Back 6

For treating a group of objects in a similar way to a single object. Creates a class that contains groups of its own (Files & Folders for examples)

Front 7

Bridge Pattern

Back 7

Decouple an abstraction from its implementation so the two can vary independently.

Example: Replacing existing version, but keeping older version running. Client code won't have to change, but has to say which version to use.

Front 8

Observer Pattern

Back 8

Used when there is one-to-many relationship between object, such as if one object is modified, its dependent objects are to be notified automatically.

Push and pull-notifications for example.

Front 9

Singleton Pattern

Back 9

Involves a single class which is responsible to create an object while making sure that only a single object gets created.

Front 10

Chain of Responsibility (CoR) Pattern

Back 10

Normally each receiver contains a reference to another. If one object cannot handle the request, it passes the request to the next receiver.

Front 11

Flyweight Pattern

Back 11

Decreases the amount of memory used and processing requried by saving intrinsic data in a common object.

For example, saving recurring information separately.

Front 12

Mediator Pattern

Back 12

Reduces communication complexity between multiple objects or classes by handling all communication between them.

Front 13

Factory Pattern

Back 13

Creates the object without exposing the creation logic to the client and refer to newly created objects using a common episode.

Front 14

Category: Structural Patterns

Back 14

Decorator

Front 15

Category: Operation Patterns

Back 15

Strategy

Front 16

Category: Extension Patterns

Back 16

Iterator

Template(?)

Front 17

Builder Pattern

Back 17

Allows the creation of a complex object by providing the information on only its type and content, keeping the details of the object creation transparent to the client. This allows the same construction process to produce different representations of the object.

Front 18

Proxy Pattern

Back 18

The intent of the this pattern is to provide a surrogate or placeholder for another object to control access to it.

Front 19

Abstract Factory Pattern

Back 19

This pattern is a class that provides an interface to produce a family of objects. In the context, there exist suites or families of related, dependent classes.

Front 20

Prototype Pattern

Back 20

This pattern is a construction Pattern which addresses the same problem as the Factory Method and Abstract Factory patterns but offers a different, more flexible way of achieving the same result.

Front 21

State Pattern

Back 21

This pattern is useful in designing an efficient structure for a class, a typical instance of which can exist in many different capacities and exhibit different behavior depending on the state it is in. In other words, in the case of an object of such a class, some or all of its behavior is completely influenced by its current form.

Front 22

Decorator Pattern

Back 22

This is a structural Pattern that extends the functionality of an object in a manner that is transparent to its clients without using inheritance.

Front 23

Strategy Pattern

Back 23

Thispattern is categorized as a Operations pattern. The pattern allows each of a family of related algorithms to be encapsulated into a set of different subclasses of a common superclass.

Front 24

Command Pattern

Back 24

This is an Operation Pattern. It allows a request to be encapsulated into an object giving control over request queuing, sequencing and undoing.

Front 25

Iterator Pattern

Back 25

This is an extension Pattern. The pattern allows a client to access the contents of an aggregate object (collection of objects) in some sequential manner, without having any knowledge about the internal representation of its contents.

Front 26

Template Pattern

Back 26

This pattern is used in situations when there is an algorithm, some steps of which could be implemented in multiple different ways.

Front 27

Visitor Pattern

Back 27

This is an extension Pattern. The pattern allows an operation to be defined across a collection of different objects without changing the classes of objects on which it operates.

Front 28

Software testing

Back 28

Execution of part of a system or systems to detect failures and improve quality. Ensures that software requirements are met. Involves code inspection and document review.

Front 29

Test Scenario

Back 29

Executing a number of test cases in a sequence such that outputs of test case(s) are used as input of other test case(s).

Front 30

1: Testing

2: Debugging

Back 30

Comparison:

1: Involves detecting possible failures

2: Involves localizing defects and correcting them

Front 31

Test Suite

Back 31

A complete set of test cases that can be run at any time. Requires a lot of programming effort but improves software quality by reducing defects in the software and makes it more maintainable and refactorable.

Front 32

JUnit

Back 32

The set of classes that form a framework that enables you to write and run tests for each method.

Front 33

Test Naming Convention

Back 33

Test classes should be named with the same name as the class being tested as suffix. Should have the word "Should", name should explain what the test does.

Front 34

Annotation: @Test

Back 34

Annotation: Identifies a test method

Front 35

Annotation: @Test (expected = Exception.class)

Back 35

Annotation:Identifies a test method that should throw a named exception.

Front 36

Annotation:@Test(timeout=100)

Back 36

Annotation:Identifies a test method that should execute within 100 milliseconds.

Front 37

Annotations: @Before, @After

Back 37

Two annotations: Identifies a method that should be executed before or after each test to prepare or clean up test environment

Front 38

Annotations: @BeforeClass, @AfterClass

Back 38

Two annotations: Identifies a static method that is executed once, before start or after the end of all tests

Front 39

Annotation: @Ignore

Back 39

Identifies a test method that should be ignored.

Front 40

Assert class

Back 40

Methods of this class in Junit test framework can be used to check if the expected output is created by the tested method. Most method take three arguments: error message, expected output, and actual output. Methods throws an <This word>Exception if the actual output is not as expected.

Front 41

Statement: fail(String)

Back 41

Fails atest method. String argument is optional.

Front 42

Statement: assertTrue([message], boolean condition)

Back 42

Tests if a boolean condition in a test method is true.

Front 43

Statement: assertFalse([message], boolean condition)

Back 43

Tests if a boolean condition in a test method is false.

Front 44

Statement: assertEquals([String message], expected, actual)

Overloaded:

Statement: assertEquals([String message], expected, actual, tolerance)

Back 44

Tests if two values in a test method are equal. Has overloading method for number of decimals to compare.

Front 45

Statement: assertNull([message], object)

Back 45

Tests if object in a test method is null.

Front 46

Statement: assertNotNull([message], object)

Back 46

Tests if object in a test method is not null.

Front 47

Statement: assertSame([String], expected, actual)

Back 47

Tests if both references in a test method point to the same object.

Front 48

Statement:assertNotSame([String], expected, actual)

Back 48

Test if references in a test method point to different objects.

Front 49

* Be public

* Return void

* Have no arguments

Back 49

A test method needs to do/be these three things to run as a test case.