Design Pattern Flashcards

1
Q

These are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code.

A

Design Patterns

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

This pertains to what the object has

A

Object Composition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

what the object is

A

object inheritance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

DRY

A

Don’t Repeat Yourself

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

KISS

A

Keep It Simple Stupid

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

YAGNI

A

You ain’t gonna need it

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Classes you create should have exactly one responsibility

A

Single Responsibility Principle (SRP)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

OPEN for extension, CLOSED for modification

extend, override, overload

A

Open/Closed Principle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

child classes or subclasses should be able to be used as substitute to parent class

if you replace an object of the parent class with an object of the subclass, the code should still work correctly

A

Liskov Substitution Principle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

clients should not be forced to depend on methods they do not use

clients: methods / classes that use the interface

should be narrow enough, that the client don’t implement the ones it does not need

A

Interface Segregation Principle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

High - level classes should not depend on low - level classes.

Both depend on abstractions.

Abstraction should not depend on details. Details depend on abstraction.

High - level classes: deals with overall functionality, directs low - level classes

Low - level classes: classes with specific details

A

Dependency Inversion Principle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Handles the creation of objects

These patterns provide various object creation mechanisms, which increase flexibility and reuse of existing code.

A

Creational Design Patterns

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

These patterns explain how to assemble objects and classes into larger structures while keeping these structures flexible and efficient.

uses interfaces to add functionality to objects

A

Structural Design Patterns

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

These patterns are concerned with algorithms and the assignment of responsibilities between objects.

A

Behavioral Design patterns

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created.

A

Factory Method

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

a creational design pattern that lets you produce families of related objects without specifying their concrete classes.

A

Abstract Factory

17
Q

a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code.

A

Builder

18
Q

a creational design pattern that lets you copy existing objects without making your code dependent on their classes.

A

Prototype

19
Q

a creational design pattern that lets you ensure that a class has only one instance, while providing a global access point to this instance.

A

Singleton

20
Q

is a structural design pattern that allows objects with incompatible interfaces to collaborate.

A

Adapter

21
Q

a structural design pattern that lets you split a large class or a set of closely related classes into two separate hierarchies—abstraction and implementation—which can be developed independently of each other.

A

Bridge

22
Q

a structural design pattern that lets you compose objects into tree structures and then work with these structures as if they were individual objects.

A

Composite

23
Q

a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.

A

Decorator

24
Q

a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.

A

Facade

25
Q

a structural design pattern that lets you 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 object.

A

Flyweight

26
Q

a structural design pattern that lets you provide a substitute or placeholder for another object. A proxy controls access to the original object, allowing you to perform something either before or after the request gets through to the original object.

A

Proxy

27
Q

a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.

A

Chain of Responsibility

28
Q

a behavioral design pattern that turns a request into a stand-alone object that contains all information about the request. This transformation lets you pass requests as a method arguments, delay or queue a request’s execution, and support undoable operations.

A

Command

29
Q

a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.).

A

Iterator

30
Q

a behavioral design pattern that lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object.

A

Mediator

31
Q

a behavioral design pattern that lets you save and restore the previous state of an object without revealing the details of its implementation.

A

Memento

32
Q

a behavioral design pattern that lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they’re observing.

A

Observer

33
Q

a behavioral design pattern that lets an object alter its behavior when its internal state changes. It appears as if the object changed its class.

A

State

34
Q

a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.

A

Strategy

35
Q

a behavioral design pattern that defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure.

A

Template Method

36
Q

a behavioral design pattern that lets you separate algorithms from the objects on which they operate.

A

Visitor

37
Q

why prefer composition over inheritance

A

composition offers several advantages over inheritance, including greater flexibility, reduced complexity, and improved maintainability. It can also avoid problems associated with multiple inheritance, such as the “diamond problem.” While inheritance still has its place in object-oriented programming.