High-Level Design Flashcards
(43 cards)
1
Q
Abstraction
A
Abstraction is a technique for managing complexity by focusing on relevant details and hiding unnecessary ones. It allows engineers to concentrate on what’s important for a specific task (e.g., a UX designer focuses on UI flows, not backend cryptography).
2
Q
Data Abstraction
A
explicitly separating the abstract properties of a data type and its concrete implementation
3
Q
What makes
createTeam(name: string): boolean
an example of data abstraction?
A
It hides the implementation details of how teams are created and stored. Client code only interacts with the method’s contract (what it requires and what it provides), not with the underlying data or logic
4
Q
data abstraction
A
- obscuring data so the client code is oblivious to the underlying implementation
- ex:
// Creates a new team.
// Requires: A non-empty and unused name.
// Modifies: Team database.
// Effects: Returns whether a team was created.
public createTeam(name: string):boolean {…}
5
Q
control abstraction
A
- Control abstraction means hiding the how of program execution so developers can focus on the what.
- It lets programmers write logical, readable code without worrying about low-level machine operations.
- Control statements (if, for, while)
- Functions/methods
- javascript promises
6
Q
top down decoposition
A
- cons: might not match the best design in practice
7
Q
Bottom Up Composition
A
as you create types, find layers of abstraction above them
8
Q
Information Hiding
A
- hide specific details of implementation
- ex: create a private field that can only be accessed by instances of the class that it is in
9
Q
Encapsulation
A
- encapsulate the data and behaviour of a class and seperate it from its implementation
- abstracts away info and simplifies
10
Q
problems with coupling (4)
A
- eaasier for errors in one part of the system to propagate to other parts of the system
- increases the degree to which a single bug fix or addition is scattered across the code base
- harder to reuse independently
- harder to understand a coupled element because it cannot be considered/understood independently
11
Q
ways to decrease coupling (3)
A
- Minimize the number of interfaces between elements
- Minimize the complexity of interfaces
- Avoid control flow coupling
12
Q
draw flow chart for coupling
A
answer in notes
13
Q
Data Coupling (score)
A
- coupling through primitive types
- score: 1
14
Q
Stamp Coupling
A
- coupling through data scructures
- score: 2
15
Q
Control Coupling
A
- coupling through control flags (the example given is a boolean about status)
- score: 3
16
Q
Global Coupling
A
- use of global variables
- score: 4
17
Q
Content Coupling
A
- coupling through internal sccess
- score: 5
18
Q
Draw the Cohesion Flow Chart
A
in notes
19
Q
cohesion + pros/cons
A
Cohesion measures how focused a program element (especially a class) is on doing a single, complete task.
In object-oriented design, cohesion evaluates how well the elements within a class belong together.
- cons: Can make navigation harder
pros: But makes individual classes easier to understand and maintain
Helps with:
Debugging
Feature additions
Bug fixes
20
Q
low cohesion
A
- Class performs many unrelated tasks.
- Leads to conflicting concerns within the same class.
- Harder to reason about and maintain:
- Fixing one bug may break a feature that relies on different logic in the same class.
- As a class’s scope grows, the chance of these issues increases
21
Q
high cohesion
A
- Class has a clear purpose and a unified set of responsibilities.
- Typically has:
- A small set of private fields
- Fields that are used by most public methods
- If some fields are used only by a few methods, that may suggest non-cohesive design.
22
Q
sequential cohesion
A
- output from one step is used as input in the next step
- score: 2
23
Q
communicational cohesion
A
- when different tasks are grouped together because they work on the same data
- score 2
24
Q
procedural cohesion
A
- when rasks are related by control flow, harder to independantly reuse
- score 3
25
Temporal Cohesion
- functionality is grouped only because it happens at the same time
- score 4
26
Logical Cohesion
- contribute to the same task even though they have different goals
- score 5
27
coincidal cohesion
- when functionality is arbitrarily grouped together
- score 6 (evil)
28
Design Symptoms (7)
-** rigidity: **resistant to change (propagate across)
- **fragility:** make a lot of assumptions about context it will be run in & lax in pre/post condition
- **immobility**
- **viscosity**: easier to violate design than adhere to it
- **neeedless complexity**
- "**repetition**: clones, indicate abstraction is missing
- **opacity**: when devs add new functionality to inconvenient places
29
SOLID
- single responsibility
- open/closed
- liskov substitution
- interface segregation
- dependency inversion
30
single responsibility
**Strategy pattern:**
- modules encapsulate algorithms
- we create modules that only implement a specific algorithm.
**Command pattern: **
- separates the notion of an action that can be performed from its implementation
- results in small modules that only provide the features needed for a specific action.
**State pattern: **
Systems often depend differently according to their internal state. Rather than having large modules that need to reason globally about all states, this pattern
- encapsulates the behaviours for a single state in a single module resulting in smaller, more targetted code.
31
open/closed
- systems should be open to extension but closed to modification
- One common code smell for violating the open/closed principle are instanceof or typeof checks within the code
32
liskov substitution
- any object in a program should be interchangeable with any object that has the same parent type
33
interface segregation
Clients should not be forced to depend on interfaces they do not use.
34
dependency inversion
- classes should depend on abstractions not implementations
- usually this means interfaces
35
APIs
- provide services without customer needing to understand implementation
- APIs are forever (ie pushback if want to change_
36
API Design Principles (2 questions)
1) what is the goal? (languages, protocols, platforms)
2) who is the customer? (versioning, licensing and authentication)
37
API Design Process (4 steps)
1) start with a spec
2) solicit feedback
3) prototype (create something that simulates use by a client)
4) document
38
Highlevel API Design Advice (4)
- APIs should **do one thing,** and do it well
- APIs should be kept as **small and simple** as possible
- APIs should **never expose internal implementation** details
- The** ‘usability’ **of a system to another engineer is dictated by the quality of the API. This means names should be well considered and consistent and the APIs, their constraints, and their pre- and post-conditions should be documented.
39
Lowlevel API Advice (6)
- **Avoid long parameter lists**
-** return descriptive objects** rather than primitive types (simplifies API documentation and enables additional fields to be included, reduces parsing)
- **Avoid exceptional returns** so clients can use the return value directly without additional checks
- **Communicate exceptions in terms of the API to make them understandable**
- ** values returned by an API should be immutable** to prevent unintended changes between the client and producer
- (private as possible) **Limit the surface of an API **to avoid clients from depending on internal classes, fields, and method.
40
API Usability (3)
- **model:** name methods well
- **mapping:**use types to be specific
- **feedback:** provide immediate feedback to user
41
Technical Representations (4)
(top more abstract)
Idea
Spec
Design
Code
(bottom more concrete)
42
Deployement Diagrams
Deployment diagrams overlay class diagrams onto execution containers and physical machines.
They help identify where and how a program will run.
43
Quiz Urself on Class Diagrams
