Position OOP as deliberate choice, add FP contrasts

- Main README: Add FP vs OOP comparison with pragmatism callout
- Classes: Position as one option among many
- Interfaces: Add function vs class comparison
- Polymorphism: Add discriminated unions as FP alternative
- Composition: Include function composition alongside object composition

Author: kentcdodds

exercises/01.classes/README.mdx

@@ -43,8 +43,10 @@ class User {
 ```
 
 <callout-info>
-	Classes in TypeScript are similar to classes in Java or C#. If you know those
-	languages, you'll feel right at home.
+	Classes aren't the only way to organize code. Many modern codebases (React,
+	functional libraries) prefer plain objects and functions. This workshop
+	teaches OOP as one powerful option—valuable knowledge even if you primarily
+	use functional patterns.
 </callout-info>
 
 In this exercise, you'll create and use classes.

exercises/03.interfaces-and-classes/01.solution.implementing-interfaces/README.mdx

@@ -6,3 +6,27 @@ they can be used interchangeably.
 🦉 The interface defines the contract (`pay()` method), and each class provides
 its own implementation. This allows different payment methods to work through the
 same interface.
+
+## Interfaces: Classes vs Functions
+
+Interfaces can define contracts for both classes and functions:
+
+```ts
+// OOP approach - interface with classes
+interface PaymentProcessor {
+	process(amount: number): boolean
+}
+class StripeProcessor implements PaymentProcessor {
+	process(amount: number) {
+		return true
+	}
+}
+
+// FP approach - function type
+type PaymentProcessor = (amount: number) => boolean
+const stripeProcessor: PaymentProcessor = (amount) => true
+```
+
+Both approaches achieve polymorphism—just through different mechanisms. The OOP
+approach bundles state and behavior; the FP approach keeps functions separate
+from data.

exercises/05.polymorphism/README.mdx

@@ -56,6 +56,35 @@ function printArea(shape: Shape) {
 printArea(new Circle(5)) // ✅ Circle is substitutable for Shape
 ```
 
+## Polymorphism: OOP vs FP
+
+OOP achieves polymorphism through class hierarchies. Functional programming
+achieves it through discriminated unions:
+
+```ts
+// OOP approach - class hierarchy
+abstract class Shape {
+	abstract area(): number
+}
+class Circle extends Shape {
+	area() {
+		return Math.PI * this.radius ** 2
+	}
+}
+
+// FP approach - discriminated union
+type Shape =
+	| { type: 'circle'; radius: number }
+	| { type: 'rectangle'; width: number; height: number }
+
+const area = (s: Shape) =>
+	s.type === 'circle' ? Math.PI * s.radius ** 2 : s.width * s.height
+```
+
+**OOP** is extensible: add new classes without changing existing code.
+**FP** makes all cases explicit: add a new variant and the compiler tells you
+everywhere you need to handle it.
+
 ## Benefits
 
 - **Flexibility** - Write code that works with multiple types

exercises/06.composition-vs-inheritance/FINISHED.mdx

@@ -5,19 +5,26 @@
 You learned:
 
 - 🔗 **Inheritance** - "is-a" relationships, code reuse through hierarchy
-- 🧩 **Composition** - "has-a" relationships, combining behaviors
+- 🧩 **Object Composition** - "has-a" relationships, combining behaviors
+- 🔄 **Function Composition** - combining functions into pipelines (FP style)
 - 🎯 **When to use each** - Choose based on the relationship type
 - 💡 **Favor composition** - More flexible and easier to change
 
 🦉 Key differences:
 
 - **Inheritance**: Tight coupling, fixed at compile time, "is-a"
-- **Composition**: Loose coupling, flexible at runtime, "has-a"
+- **Composition**: Loose coupling, flexible at runtime, "has-a" or "transforms"
 
 💰 General rule: Use inheritance when you have a clear "is-a" relationship and
-want to share implementation. Use composition when you need flexibility or have
-a "has-a" relationship.
-
-🦉 Both are valuable tools—the key is choosing the right one for each situation.
-
-Congratulations! You've completed the Object-Oriented TypeScript workshop!
+want to share implementation. Use composition (object or function) when you need
+flexibility.
+
+<callout-info>
+	OOP is a tool, not a religion. Many successful TypeScript codebases use a mix
+	of OOP and functional patterns. Use the right tool for each situation—sometimes
+	that's a class, sometimes it's a function, and often it's a combination.
+</callout-info>
+
+Congratulations! You've completed the Object-Oriented TypeScript workshop! You
+now understand both OOP patterns and when functional alternatives might be a
+better fit.

exercises/06.composition-vs-inheritance/README.mdx

@@ -47,6 +47,32 @@ Use composition when:
 - You need to combine multiple behaviors
 - The relationship is "has-a" not "is-a"
 
+## Three Types of Composition
+
+1. **Inheritance** (is-a): `Dog extends Animal`
+2. **Object Composition** (has-a): `Car` has an `Engine`
+3. **Function Composition** (transforms): combine functions into pipelines
+
+```ts
+// Object composition (OOP)
+class EmailService {
+	constructor(private logger: Logger) {}
+	send(email: Email) {
+		this.logger.log('Sending...')
+		// ...
+	}
+}
+
+// Function composition (FP)
+const sendEmail = (logger: Logger) => (email: Email) => {
+	logger.log('Sending...')
+	// ...
+}
+```
+
+Both achieve the same goal—loose coupling and flexibility—through different
+mechanisms.
+
 ## When to Use Each
 
 **Inheritance:**
@@ -55,16 +81,17 @@ Use composition when:
 - `Circle` is a `Shape` ✅
 - `Manager` is an `Employee` ✅
 
-**Composition:**
+**Composition (object or function):**
 
 - `Car` has an `Engine` ✅
 - `Computer` has a `CPU` ✅
 - `User` has a `Profile` ✅
+- Data transformation pipelines ✅
 
 <callout-info>
-	Favor composition over inheritance when possible. Composition is more flexible
-	and easier to change. Use inheritance when you truly have an "is-a"
-	relationship.
+	Favor composition over inheritance when possible. Both object composition and
+	function composition are more flexible and easier to change than inheritance.
+	Use inheritance when you truly have an "is-a" relationship.
 </callout-info>
 
 In this exercise, you'll choose between composition and inheritance.

exercises/README.mdx

@@ -15,9 +15,42 @@ We'll cover:
 5. **Polymorphism** - Substitutability and why it matters
 6. **Composition vs Inheritance** - Practical decision-making
 
+## OOP vs Functional Programming
+
+TypeScript supports multiple paradigms. This workshop teaches OOP because it's
+valuable knowledge—you'll encounter it in many codebases and libraries. But you
+should know the alternative:
+
+**OOP organizes around objects** - data and behavior bundled together:
+
+```ts
+class ShoppingCart {
+	private items: Product[] = []
+	addItem(product: Product) {
+		this.items.push(product)
+	}
+	getTotal() {
+		return this.items.reduce((sum, p) => sum + p.price, 0)
+	}
+}
+```
+
+**FP organizes around functions** - data and transformations separate:
+
+```ts
+type Cart = readonly Product[]
+const addItem = (cart: Cart, product: Product): Cart => [...cart, product]
+const getTotal = (cart: Cart): number => cart.reduce((sum, p) => sum + p.price, 0)
+```
+
+**Both are valid.** OOP excels at encapsulation and polymorphism. FP excels at
+data transformation and immutability. Choose based on your problem domain.
+
 <callout-info>
-	OOP isn't about using classes everywhere—it's about organizing code so that
-	complexity is manageable and changes are isolated.
+	Pragmatism over purity! JavaScript isn't Haskell—no JS program is 100% purely
+	functional. If a class solves your problem elegantly, use it. The goal is to
+	have both tools in your toolkit and choose wisely. Modern React codebases
+	often lean functional, but many successful projects use classes too.
 </callout-info>
 
 By the end of this workshop, you'll be able to:
@@ -27,5 +60,6 @@ By the end of this workshop, you'll be able to:
 - Apply inheritance appropriately
 - Understand when to prefer composition
 - Write polymorphic code that's flexible and testable
+- **Make informed decisions** about when OOP or FP is the better fit
 
 Let's build some objects! 🧱