OOP AEIP (A=Abstraction, E=Encapsulation, I=Inheritance, P=Polymorphism — the four pillars of Object-Oriented Programming): Abstraction, Encapsulation, Inheritance, Polymorphism
4 Pillars of OOP
The four principles of object-oriented programming
Abstraction: hide complexity. Encapsulation: bundle data and methods, restrict access. Inheritance: child class extends parent. Polymorphism: same interface, different implementations.
A
Abstraction — hide implementation
E
Encapsulation — bundle data and behavior
I
Inheritance — child extends parent
P
Polymorphism — same interface, different behavior
Recursion
Recursion: base case stops it, recursive case reduces toward base case
Recursion
A function that solves a problem by calling itself
Every recursive function needs: (1) base case that stops recursion, (2) recursive case moving toward base case. Factorial: n! = n × (n-1)!, base case: 0! = 1. Without base case → stack overflow.
DRY Principle
DRY (Do Not Repeat Yourself): Don't Repeat Yourself — extract repeated logic into functions
DRY Principle
The most important coding principle — eliminate duplication
If you write the same logic twice, extract it. Changes only need to be made once. Related: SOLID principles. Opposite of WET (Write Everything Twice) code.
Complexity Trade-offs
Time vs Space complexity: often trade one for the other
Complexity Trade-offs
Algorithms often trade time for memory or vice versa
Caching (memoization): use more memory to save computation time. Streaming: process in chunks, save memory at cost of speed. Profile before optimizing — premature optimization wastes time.
Five object-oriented design principles for maintainable code
S: one class, one job. O: open for extension, closed for modification. L: subclasses should be substitutable for parent classes. I: don't force classes to implement interfaces they don't use. D: depend on abstractions, not concretions.
Functional Programming
Functional programming: pure functions (no side effects) + immutable data. Map, filter, reduce.
Functional Programming
A paradigm treating computation as mathematical function evaluation
Pure functions: same input always produces same output, no side effects. Immutable data: never modify, create new. First-class functions: functions as values — pass them, return them. Map: transform each element. Filter: keep elements matching condition. Reduce: combine elements into single value. Haskell, Clojure, Scala.
Commit: snapshot of all tracked files at a point in time. Branch: independent line of development (feature/main). Merge: combine changes from two branches. Pull request: request to merge branch, enables code review. Common workflow: create branch → make changes → commit → push → pull request → merge.
Four levels of testing — each catching different types of bugs
Unit tests: test individual functions/methods in isolation — fast, pinpoint failures. Integration tests: test how modules work together — catches interface bugs. End-to-end (E2E): test complete user workflows — slow but high confidence. Regression: re-run tests after changes to ensure old bugs don't return.
Unit
Single function, fast, isolated
Integration
Multiple modules working together
E2E
Full user workflow
Regression
Prevent old bugs from returning
Space Complexity
Big O space complexity: track memory used. Recursive algorithms use O(n) stack space for n calls.
Space Complexity
Measuring memory usage — often overlooked but critical
Algorithms have both time AND space complexity. Iterative O(n) sum: O(1) space. Recursive O(n) sum: O(n) space (n stack frames). Merge sort: O(n) extra space for merging. In-place algorithms: O(1) extra space (bubble sort, selection sort). Space-time tradeoff: often use more memory to go faster.
APIs and REST
API (Application Programming Interface). REST (Representational State Transfer): stateless, HTTP verbs, JSON. Endpoint = specific URL.
APIs and REST
How software systems communicate with each other
API: defined interface for software interaction. REST (Representational State Transfer): architectural style for web APIs. Stateless: each request contains all info needed. Resources identified by URLs. HTTP verbs: GET/POST/PUT/DELETE. Response typically JSON. Status codes: 200 OK, 404 Not Found, 500 Server Error.
Concurrency and Parallelism
Concurrency vs parallelism: concurrency = dealing with multiple things. Parallelism = doing multiple things simultaneously.
Concurrency and Parallelism
Two related but distinct concepts in multi-threaded programming
Concurrency: structuring program to handle multiple tasks — can be done on a single core by interleaving. Parallelism: actually executing multiple tasks simultaneously — requires multiple cores. Race condition: two threads access shared data simultaneously → unpredictable results. Mutex/lock: ensures only one thread accesses resource at a time.
Mnemonic
What it means
✅ 0❌ 0📚 0 left
No saved cards yet — click ☆ Save on any memory trick.
🎓 Common Exam Questions
Q: What does OOP AEIP stand for? Explain each pillar with an example.
A: OOP AEIP: Abstraction (A): hide complexity, expose interface. Car accelerator abstracts the engine. In code: abstract classes and interfaces. Encapsulation (E): bundle data and methods, control access. Bank account exposes deposit() and withdraw() but keeps balance private. Inheritance (I): child class inherits from parent, promotes reuse. Dog extends Animal getting eat() and sleep(), adds bark(). Polymorphism (P): same interface different behavior. Shape has draw() — Circle.draw() and Rectangle.draw() each do different things. At runtime the correct version is called (dynamic dispatch).
Q: What does SOLID stand for? Explain each principle.
A: SOLID: S Single Responsibility — class has one reason to change. User handles data; EmailService sends emails. O Open/Closed — open for extension, closed for modification. Add payment methods by extending base class, not changing existing. L Liskov Substitution — subclasses substitutable for parent without breaking behavior. I Interface Segregation — clients should not implement interfaces they do not use, split fat interfaces. D Dependency Inversion — depend on abstractions not concretions, enables testing with mock objects.
Q: Explain recursion — how does the call stack work?
A: Recursion: function calls itself with smaller problem until base case. Each call placed on the call stack — LIFO (Last In First Out) structure storing local variables and return address. Example: factorial(5) = 5 times factorial(4) and so on. Stack builds: factorial(5) through factorial(1) which is base case returning 1, then unwinds. Stack overflow: recursion too deep, no base case, or problem too large exceeds stack size limit. Fix: add base case, ensure recursive case reduces toward it, or convert to iteration with explicit stack.
Q: What is an API? Explain REST and JSON.
A: API (Application Programming Interface): rules for how software components communicate. REST (Representational State Transfer, Roy Fielding 2000): stateless meaning each request contains all needed information, resources identified by URLs (Uniform Resource Locators), HTTP verbs define actions (GET retrieves, POST creates, PUT replaces, PATCH partially updates, DELETE removes), responses typically in JSON (JavaScript Object Notation) which is lightweight text like: name is Alice, age is 30. REST vs GraphQL: REST has fixed endpoints; GraphQL lets clients specify exactly what data they need.
Q: Compare testing types and explain the test pyramid.
A: Test pyramid: wide base of many fast cheap tests, narrow top of few slow expensive tests. Unit tests at base: single function in isolation, mock dependencies, milliseconds each, hundreds or thousands total, pinpoint bugs exactly. Integration tests in middle: multiple modules together, test database queries and API calls, slower and fewer. End-to-End tests at top: simulate real user from browser click to database, slowest and most brittle, fewest of all. Tools: Jest, JUnit, pytest for unit; Supertest or Postman for integration; Selenium, Cypress, Playwright for E2E. TDD: write failing test first, then minimal code to pass, then refactor.