7a:T9e5,// UML Class: // ┌────────────────────────────────────┐ // │ «abstract» Account │ // ├────────────────────────────────────┤ // │ - accountId: string │ // │ - balance: decimal │ // │ # transactions: Transaction [*] │ // ├────────────────────────────────────┤ // │ + deposit(amount: decimal): void │ // │ + withdraw(amount: decimal): bool │ // │ # recordTransaction(t: Trans): void│ // │ + getBalance(): decimal │ // └────────────────────────────────────┘ abstract class Account { // Private attributes - dash (-) in UML private readonly accountId: string; private balance: number; // Protected attribute - hash (#) in UML, [*] means collection protected transactions: Transaction[] = []; constructor(accountId: string, initialBalance: number = 0) { this.accountId = accountId; this.balance = initialBalance; } // Public methods - plus (+) in UML public deposit(amount: number): void { if (amount <= 0) { throw new Error("Deposit amount must be positive"); } this.balance += amount; this.recordTransaction(new Transaction("DEPOSIT", amount)); } public withdraw(amount: number): boolean { if (amount <= 0 || amount > this.balance) { return false; } this.balance -= amount; this.recordTransaction(new Transaction("WITHDRAWAL", amount)); return true; } // Protected method - hash (#) in UML protected recordTransaction(transaction: Transaction): void { this.transactions.push(transaction); } public getBalance(): number { return this.balance; } // Abstract method (from abstract class) public abstract calculateInterest(): number; } // Concrete implementation class SavingsAccount extends Account { private readonly interestRate: number; constructor(accountId: string, initialBalance: number, interestRate: number) { super(accountId, initialBalance); this.interestRate = interestRate; } public calculateInterest(): number { return this.getBalance() * this.interestRate; } }7b:Tafe,// UML Class: // ┌────────────────────────────────────┐ // │ «abstract» Account │ // ├────────────────────────────────────┤ // │ - accountId: String │ // │ - balance: BigDecimal │ // │ # transactions: Transaction [*] │ // ├────────────────────────────────────┤ // │ + deposit(amount: BigDecimal): void│ // │ + withdraw(amount: BigDecimal): bool│ // │ # recordTransaction(t: Trans): void│ // │ + getBalance(): BigDecimal │ // └────────────────────────────────────┘ public abstract class Account { // Private attributes - dash (-) in UML private final String accountId; private BigDecimal balance; // Protected attribute - hash (#) in UML, [*] means collection protected List transactions = new ArrayList<>(); protected Account(String accountId, BigDecimal initialBalance) { this.accountId = accountId; this.balance = initialBalance != null ? initialBalance : BigDecimal.ZERO; } // Public methods - plus (+) in UML public void deposit(BigDecimal amount) { if (amount.compareTo(BigDecimal.ZERO) <= 0) { throw new IllegalArgumentException("Deposit amount must be positive"); } this.balance = this.balance.add(amount); this.recordTransaction(new Transaction("DEPOSIT", amount)); } public boolean withdraw(BigDecimal amount) { if (amount.compareTo(BigDecimal.ZERO) <= 0 || amount.compareTo(this.balance) > 0) { return false; } this.balance = this.balance.subtract(amount); this.recordTransaction(new Transaction("WITHDRAWAL", amount)); return true; } // Protected method - hash (#) in UML protected void recordTransaction(Transaction transaction) { this.transactions.add(transaction); } public BigDecimal getBalance() { return this.balance; } // Abstract method (from abstract class) public abstract BigDecimal calculateInterest(); } // Concrete implementation public class SavingsAccount extends Account { private final BigDecimal interestRate; public SavingsAccount(String accountId, BigDecimal initialBalance, BigDecimal interestRate) { super(accountId, initialBalance); this.interestRate = interestRate; } @Override public BigDecimal calculateInterest() { return getBalance().multiply(interestRate); } }7c:T126a,// ================================================ // ASSOCIATION: Simple "knows about" relationship // UML: Order ───────────> Customer // ================================================ class Order { // Association: Order knows about Customer // Customer exists independently, passed in from outside private customer: Customer; constructor(customer: Customer) { this.customer = customer; } getCustomerEmail(): string { return this.customer.getEmail(); } } // ================================================ // AGGREGATION: "Has-a" with independent lifecycle // UML: Department ◇───────> Employee [*] // Diamond on Department side, employees can exist without dept // ================================================ class Department { private name: string; // Aggregation: Department has Employees // Employees exist independently and can belong to other departments private employees: Employee[] = []; constructor(name: string) { this.name = name; } // Employees are added/removed, not created/destroyed addEmployee(employee: Employee): void { this.employees.push(employee); } removeEmployee(employee: Employee): void { const index = this.employees.indexOf(employee); if (index > -1) { this.employees.splice(index, 1); } // Note: employee continues to exist after removal } } // ================================================ // COMPOSITION: "Has-a" with owned lifecycle // UML: House ◆───────> Room [1..*] // Filled diamond on House side, rooms can't exist without house // ================================================ class House { private address: string; // Composition: House owns Rooms // Rooms are created by House and can't exist independently private readonly rooms: Room[] = []; constructor(address: string, roomCount: number) { this.address = address; // House creates its rooms - they can't exist without the house for (let i = 0; i < roomCount; i++) { this.rooms.push(new Room(`Room ${i + 1}`, this)); } } getRooms(): ReadonlyArray { return this.rooms; } // When house is destroyed, rooms are automatically destroyed // (no explicit cleanup needed in garbage-collected languages) } class Room { private name: string; private readonly house: House; // Back-reference to parent constructor(name: string, house: House) { this.name = name; this.house = house; } } // ================================================ // INHERITANCE: "Is-a" relationship // UML: SavingsAccount ──────▷ Account // Open arrow pointing to parent class // ================================================ abstract class Account { protected balance: number; constructor(initialBalance: number) { this.balance = initialBalance; } abstract calculateInterest(): number; } class SavingsAccount extends Account { private interestRate: number; constructor(initialBalance: number, interestRate: number) { super(initialBalance); this.interestRate = interestRate; } calculateInterest(): number { return this.balance * this.interestRate; } } // ================================================ // REALIZATION: Implementing an interface // UML: EmailNotifier - - - - -▷ «interface» NotificationService // Dashed line with open arrow to interface // ================================================ interface NotificationService { send(recipient: string, message: string): Promise; validateRecipient(recipient: string): boolean; } class EmailNotifier implements NotificationService { async send(recipient: string, message: string): Promise { // Implementation details console.log(`Sending email to ${recipient}: ${message}`); } validateRecipient(recipient: string): boolean { return recipient.includes('@'); } } // ================================================ // DEPENDENCY: Temporary usage // UML: ReportGenerator - - - -> DataFormatter // Dashed line with arrow (weakest relationship) // ================================================ class ReportGenerator { // No field reference to DataFormatter generateReport(data: object[]): string { // Dependency: uses DataFormatter temporarily // Formatter is a parameter, not a stored reference const formatter = new DataFormatter(); return formatter.format(data); } }7d:T125b,// ================================================ // MULTIPLICITY: [1] - Exactly one (required) // UML: Order ──────────[1]──> PaymentMethod // ================================================ class Order { // Multiplicity [1]: Exactly one, cannot be null private readonly paymentMethod: PaymentMethod; constructor(paymentMethod: PaymentMethod) { // Enforce multiplicity constraint if (!paymentMethod) { throw new Error("PaymentMethod is required"); } this.paymentMethod = paymentMethod; } } // ================================================ // MULTIPLICITY: [0..1] - Zero or one (optional) // UML: User ──────────[0..1]──> ProfilePhoto // ================================================ class User { private name: string; // Multiplicity [0..1]: Optional, can be null private profilePhoto: ProfilePhoto | null = null; constructor(name: string) { this.name = name; } setProfilePhoto(photo: ProfilePhoto | null): void { this.profilePhoto = photo; } hasProfilePhoto(): boolean { return this.profilePhoto !== null; } } // ================================================ // MULTIPLICITY: [*] or [0..*] - Zero or more // UML: ShoppingCart ──────────[*]──> CartItem // ================================================ class ShoppingCart { // Multiplicity [*]: Zero or more private items: CartItem[] = []; addItem(item: CartItem): void { this.items.push(item); } removeItem(itemId: string): boolean { const index = this.items.findIndex(i => i.getId() === itemId); if (index > -1) { this.items.splice(index, 1); return true; } return false; } isEmpty(): boolean { return this.items.length === 0; } } // ================================================ // MULTIPLICITY: [1..*] - One or more (non-empty) // UML: Playlist ──────────[1..*]──> Song // ================================================ class Playlist { private name: string; // Multiplicity [1..*]: At least one required private readonly songs: Song[]; constructor(name: string, initialSong: Song) { this.name = name; // Enforce at least one song if (!initialSong) { throw new Error("Playlist must have at least one song"); } this.songs = [initialSong]; } addSong(song: Song): void { this.songs.push(song); } removeSong(songId: string): boolean { // Maintain [1..*] constraint if (this.songs.length <= 1) { return false; // Cannot remove the last song } const index = this.songs.findIndex(s => s.getId() === songId); if (index > -1) { this.songs.splice(index, 1); return true; } return false; } } // ================================================ // MULTIPLICITY: [2..5] - Specific range // UML: Team ──────────[2..5]──> Player // ================================================ class Team { private static readonly MIN_PLAYERS = 2; private static readonly MAX_PLAYERS = 5; private name: string; private readonly players: Player[]; constructor(name: string, initialPlayers: Player[]) { // Enforce range constraint if (initialPlayers.length < Team.MIN_PLAYERS) { throw new Error(`Team requires at least ${Team.MIN_PLAYERS} players`); } if (initialPlayers.length > Team.MAX_PLAYERS) { throw new Error(`Team cannot have more than ${Team.MAX_PLAYERS} players`); } this.name = name; this.players = [...initialPlayers]; } addPlayer(player: Player): boolean { if (this.players.length >= Team.MAX_PLAYERS) { return false; // At maximum capacity } this.players.push(player); return true; } removePlayer(playerId: string): boolean { if (this.players.length <= Team.MIN_PLAYERS) { return false; // At minimum capacity } const index = this.players.findIndex(p => p.getId() === playerId); if (index > -1) { this.players.splice(index, 1); return true; } return false; } canAddPlayer(): boolean { return this.players.length < Team.MAX_PLAYERS; } canRemovePlayer(): boolean { return this.players.length > Team.MIN_PLAYERS; } }7e:T16c9,// ================================================ // INTERFACE (from UML «interface» stereotype) // Defines pure contract - what operations are available // ================================================ // UML: // ┌──────────────────────────────────┐ // │ «interface» PaymentGateway │ // ├──────────────────────────────────┤ // │ + processPayment(amt): Result │ // │ + refund(txnId): Result │ // │ + validateCard(card): bool │ // └──────────────────────────────────┘ interface PaymentGateway { processPayment(amount: number, cardToken: string): Promise; refund(transactionId: string, amount?: number): Promise; validateCard(cardToken: string): Promise; } // Multiple implementations of the interface class StripeGateway implements PaymentGateway { async processPayment(amount: number, cardToken: string): Promise { // Stripe-specific implementation return { success: true, transactionId: `stripe_${Date.now()}` }; } async refund(transactionId: string, amount?: number): Promise { return { success: true }; } async validateCard(cardToken: string): Promise { return cardToken.startsWith('tok_'); } } class PayPalGateway implements PaymentGateway { async processPayment(amount: number, cardToken: string): Promise { // PayPal-specific implementation return { success: true, transactionId: `paypal_${Date.now()}` }; } async refund(transactionId: string, amount?: number): Promise { return { success: true }; } async validateCard(cardToken: string): Promise { return cardToken.startsWith('pp_'); } } // ================================================ // ABSTRACT CLASS (from UML italic class name) // Provides partial implementation - template method pattern // ================================================ // UML: // ┌────────────────────────────────────────┐ // │ «abstract» NotificationSender │ // ├────────────────────────────────────────┤ // │ - recipientValidator: Validator │ // │ # retryCount: int = 3 │ // ├────────────────────────────────────────┤ // │ + send(msg): void │ // │ # formatMessage(msg): string (abs) │ // │ # doSend(formatted): bool (abs) │ // │ - logAttempt(success): void │ // └────────────────────────────────────────┘ abstract class NotificationSender { private recipientValidator: RecipientValidator; protected retryCount: number = 3; constructor(validator: RecipientValidator) { this.recipientValidator = validator; } // Template method - defines algorithm skeleton public async send(message: NotificationMessage): Promise { // Validate recipient (concrete implementation) if (!this.recipientValidator.validate(message.recipient)) { throw new Error("Invalid recipient"); } // Format message (subclass responsibility) const formatted = this.formatMessage(message); // Attempt to send with retries let lastError: Error | null = null; for (let attempt = 0; attempt < this.retryCount; attempt++) { if (await this.doSend(formatted)) { this.logAttempt(true); return; } lastError = new Error(`Send attempt ${attempt + 1} failed`); } this.logAttempt(false); throw lastError || new Error("Send failed"); } // Abstract methods - subclasses must implement protected abstract formatMessage(message: NotificationMessage): string; protected abstract doSend(formattedMessage: string): Promise; // Private helper - not overridable private logAttempt(success: boolean): void { console.log(`Notification send ${success ? 'succeeded' : 'failed'}`); } } // Concrete implementations class EmailSender extends NotificationSender { private smtpClient: SMTPClient; constructor(validator: RecipientValidator, smtpClient: SMTPClient) { super(validator); this.smtpClient = smtpClient; } protected formatMessage(message: NotificationMessage): string { return `Subject: ${message.subject} ${message.body}`; } protected async doSend(formattedMessage: string): Promise { return this.smtpClient.send(formattedMessage); } } class SMSSender extends NotificationSender { private smsProvider: SMSProvider; constructor(validator: RecipientValidator, smsProvider: SMSProvider) { super(validator); this.smsProvider = smsProvider; this.retryCount = 5; // Override default retry count } protected formatMessage(message: NotificationMessage): string { // SMS has character limits - truncate if needed const content = message.body.substring(0, 160); return content; } protected async doSend(formattedMessage: string): Promise { return this.smsProvider.sendSMS(formattedMessage); } }7f:T13b0,// ================================================ // SEQUENCE DIAGRAM: Order Placement Flow // ================================================ // // Customer OrderService Inventory PaymentService EmailService // | | | | | // | placeOrder() | | | | // |---------------->| | | | // | | checkStock() | | | // | |---------------->| | | // | | stockResult | | | // | |<- - - - - - - - | | | // | | | | | // | | [if stock available] | | // | | | | | // | | | processPayment()| | // | |---------------------------------------->| | // | | | paymentResult | | // | |<- - - - - - - - - - - - - - - - - -| | // | | | | | // | | | [if payment successful] | // | | | | | // | | reserveStock() | | | // | |---------------->| | | // | | | | | // | | | | sendConfirmation()| // | |------------------------------------------------->| | // | | | | | // | orderResult | | | | // |<- - - - - - - - | | | | // The above diagram translates to: interface OrderResult { success: boolean; orderId?: string; error?: string; } interface StockResult { available: boolean; quantity: number; } interface PaymentResult { success: boolean; transactionId?: string; error?: string; } class OrderService { private inventory: Inventory; private paymentService: PaymentService; private emailService: EmailService; constructor( inventory: Inventory, paymentService: PaymentService, emailService: EmailService ) { this.inventory = inventory; this.paymentService = paymentService; this.emailService = emailService; } // Main method from sequence diagram async placeOrder(order: Order): Promise { // Step 1: Check stock (message to Inventory) const stockResult = await this.inventory.checkStock(order.items); // Alt fragment: [if stock available] if (!stockResult.available) { return { success: false, error: "Insufficient stock" }; } // Step 2: Process payment (message to PaymentService) const paymentResult = await this.paymentService.processPayment( order.customerId, order.totalAmount ); // Alt fragment: [if payment successful] if (!paymentResult.success) { return { success: false, error: paymentResult.error || "Payment failed" }; } // Step 3: Reserve stock (message to Inventory) await this.inventory.reserveStock(order.items); // Step 4: Send confirmation (message to EmailService) await this.emailService.sendConfirmation(order); // Return result (dashed return arrow to Customer) return { success: true, orderId: this.generateOrderId() }; } private generateOrderId(): string { return `ORD-${Date.now()}`; } } // Supporting classes (from the participant boxes) class Inventory { async checkStock(items: OrderItem[]): Promise { // Implementation return { available: true, quantity: 100 }; } async reserveStock(items: OrderItem[]): Promise { // Implementation } } class PaymentService { async processPayment(customerId: string, amount: number): Promise { // Implementation return { success: true, transactionId: "TXN-123" }; } } class EmailService { async sendConfirmation(order: Order): Promise { // Implementation } }80:Tffd,// ================================================ // PITFALL: Ignoring Visibility // ================================================ // ❌ WRONG: Everything public class BadAccount { public balance: number = 0; // Should be private! public transactions: Transaction[] = []; // Should be protected! public setBalanceDirectly(amount: number) { this.balance = amount; // Bypasses all validation! } } // ✅ CORRECT: Respecting visibility modifiers class GoodAccount { private balance: number = 0; protected transactions: Transaction[] = []; public deposit(amount: number): void { if (amount <= 0) throw new Error("Invalid amount"); this.balance += amount; this.recordTransaction("DEPOSIT", amount); } protected recordTransaction(type: string, amount: number): void { this.transactions.push(new Transaction(type, amount)); } } // ================================================ // PITFALL: Concrete Class Dependencies // ================================================ // ❌ WRONG: Depending on concrete implementation class BadOrderProcessor { private gateway: StripePaymentGateway; // Concrete type! constructor() { this.gateway = new StripePaymentGateway(); // Hard-coded! } async process(order: Order): Promise { await this.gateway.charge(order.total); } } // ✅ CORRECT: Depending on abstraction (interface) class GoodOrderProcessor { private gateway: PaymentGateway; // Interface type! constructor(gateway: PaymentGateway) { // Injected! this.gateway = gateway; } async process(order: Order): Promise { await this.gateway.processPayment(order.total, order.paymentToken); } } // ================================================ // PITFALL: Wrong Relationship Implementation // ================================================ // ❌ WRONG: Composition implemented as aggregation class BadCar { private engine: Engine; setEngine(engine: Engine): void { this.engine = engine; // Engine passed in = aggregation behavior } } // ✅ CORRECT: Composition - Car creates and owns its Engine class GoodCar { private readonly engine: Engine; constructor(engineType: string) { this.engine = new Engine(engineType); // Created internally } // Engine cannot be changed or removed getHorsepower(): number { return this.engine.getHorsepower(); } } // ================================================ // PITFALL: Missing Multiplicity Validation // ================================================ // ❌ WRONG: No constraint enforcement class BadTeam { private players: Player[] = []; addPlayer(player: Player): void { this.players.push(player); // No limit! } removePlayer(index: number): void { this.players.splice(index, 1); // Can remove all players! } } // ✅ CORRECT: Enforcing [2..11] multiplicity class GoodTeam { private static readonly MIN_PLAYERS = 2; private static readonly MAX_PLAYERS = 11; private players: Player[]; constructor(initialPlayers: Player[]) { if (initialPlayers.length < GoodTeam.MIN_PLAYERS || initialPlayers.length > GoodTeam.MAX_PLAYERS) { throw new Error( `Team requires ${GoodTeam.MIN_PLAYERS}-${GoodTeam.MAX_PLAYERS} players` ); } this.players = [...initialPlayers]; } addPlayer(player: Player): boolean { if (this.players.length >= GoodTeam.MAX_PLAYERS) { return false; } this.players.push(player); return true; } removePlayer(playerId: string): boolean { if (this.players.length <= GoodTeam.MIN_PLAYERS) { return false; } const index = this.players.findIndex(p => p.id === playerId); if (index > -1) { this.players.splice(index, 1); return true; } return false; } }72:{"json":{"id":"seed_4363fced0b0b77275034550de1b26ffa","slug":"from-design-to-code","category":"Low-Level Design","topic":"From Design to Code","title":"From Design to Code","description":"Master the art of translating visual design artifacts—UML class diagrams, sequence diagrams, and relationship specifications—into clean, maintainable, production-ready code. Learn systematic approaches to implementation that preserve design intent while adapting to language-specific idioms.","difficulty":"ADVANCED","estimatedMinutes":75,"pages":[{"id":"seed_3b212fc3946d34c00d181dce0e24015c","title":"Translating UML to Code","order":0,"content":[{"id":"opening-hook","title":"The Bridge Between Design and Reality","content":[{"data":{"content":"You've spent 20 minutes in an LLD interview carefully designing a system. Your class diagram is elegant—clean hierarchies, well-defined relationships, appropriate use of design patterns. The interviewer nods approvingly and says: **\"Great design. Now implement it.\"**\n\nThis is where many candidates falter. The transition from visual notation to executable code isn't merely typing what you see. It requires understanding how each UML element maps to language constructs, the order in which to implement components, and how to adapt abstract designs to concrete programming language idioms.\n\nThis page provides a **systematic, repeatable methodology** for translating any UML design into production-quality code. By mastering this translation process, you'll be able to confidently move from whiteboard diagrams to working implementations—whether in an interview setting or real-world software development."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand how to systematically translate UML class diagrams to code, map associations, aggregations, and compositions to object relationships, implement inheritance hierarchies and interface contracts, and handle visibility modifiers and cardinality constraints. You'll leave with a mental checklist that makes UML-to-code translation mechanical rather than ad-hoc.","variant":"info"},"type":"callout"}]},{"id":"why-translation-matters","title":"Why UML-to-Code Translation Matters","content":[{"data":{"content":"UML diagrams serve as a **communication and planning tool**—they capture design decisions in a language-agnostic visual notation. But diagrams don't run. Eventually, every design must become code.\n\nThe translation process is where **design intent meets implementation reality**. Done poorly, the resulting code may technically work but miss the design's purpose—creating tight coupling where the diagram specified loose coupling, or using concrete classes where interfaces were intended.\n\n**The cost of poor translation:**"},"type":"text"},{"data":{"items":["**Lost flexibility** — Associations become hard-coded dependencies, losing the runtime configurability the design intended","**Broken encapsulation** — Visibility modifiers (private, protected) are ignored, exposing internal state that should be hidden","**Incorrect cardinality** — One-to-many relationships implemented as one-to-one, or vice versa, causing data integrity issues","**Missing polymorphism** — Abstract classes and interfaces reduced to concrete implementations, eliminating extensibility","**Inverted control** — Dependency directions flipped, creating circular dependencies or violating dependency inversion"],"title":{"icon":"AlertCircle","text":"Common Translation Failures","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**When done well**, UML-to-code translation preserves the design's qualities:\n\n- **Modularity** — Each class remains a cohesive unit with a single responsibility\n- **Flexibility** — Interfaces and abstract classes enable extension without modification\n- **Testability** — Dependencies are injectable, enabling mock substitution in tests\n- **Readability** — Code structure mirrors diagram structure, making the design visible in the implementation\n\nThe goal isn't blind, mechanical copying. It's **faithful translation that adapts to language idioms** while preserving the design's architectural properties."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Principal Engineer's Perspective","content":"Senior engineers treat UML diagrams as specifications, not suggestions. Every arrow, every visibility modifier, every cardinality annotation was chosen deliberately. Ignoring these details during implementation is equivalent to ignoring requirements—it creates technical debt that compounds over time.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"class-diagram-elements","title":"UML Class Diagram Elements and Their Code Mappings","content":[{"data":{"content":"Before we translate, let's establish a comprehensive mapping between UML notation and code constructs. Each element in a class diagram has a direct, systematic translation.\n\n**The Class Box:**\n\nA UML class is represented as a three-compartment rectangle:\n- **Top compartment**: Class name (italic for abstract classes, «interface» stereotype for interfaces)\n- **Middle compartment**: Attributes (fields/properties)\n- **Bottom compartment**: Operations (methods)"},"type":"text"},{"data":{"rows":[["`+`","Public","`public`","Accessible from anywhere"],["`-`","Private","`private`","Accessible only within the class"],["`#`","Protected","`protected`","Accessible in class and subclasses"],["`~`","Package/Internal","`internal` (C#) / default (Java)","Accessible within same package/assembly"]],"caption":"UML Visibility Modifiers to Code","headers":["UML Symbol","Visibility","Java/C#/TypeScript","Access Level"]},"type":"table"},{"data":{"content":"**Attribute Syntax:**\n\nUML attributes follow the pattern: `visibility name : type [multiplicity] = defaultValue`"},"type":"text"},{"data":{"rows":[["`- balance : decimal`","`private decimal balance;`"],["`+ name : string = \"\"`","`public string name = \"\";`"],["`# items : Product [*]`","`protected List items;`"],["`- createdAt : DateTime [0..1]`","`private DateTime? createdAt;` (nullable)"]],"headers":["UML Notation","Code Translation"]},"type":"table"},{"data":{"content":"**Operation (Method) Syntax:**\n\nUML operations follow: `visibility name(parameters) : returnType`"},"type":"text"},{"data":{"rows":[["`+ calculateTotal() : decimal`","`public decimal CalculateTotal() { }`"],["`- validate(input : string) : bool`","`private bool Validate(string input) { }`"],["`# onStateChanged() : void`","`protected void OnStateChanged() { }`"],["`+ findById(id : int) : User [0..1]`","`public User? FindById(int id) { }`"]],"headers":["UML Notation","Code Translation"]},"type":"table"},{"data":{"fileName":"UML Class Translation Example","languages":[{"code":"$7a","label":"TypeScript","value":"typescript"},{"code":"$7b","label":"Java","value":"java"}]},"type":"code"}],"titleType":"number","titleNumber":2},{"id":"translating-relationships","title":"Translating UML Relationships to Code","content":[{"data":{"content":"Relationships between classes are the heart of any design. UML defines several relationship types, each with distinct implementation semantics.\n\n**The Five Core Relationships:**"},"type":"text"},{"data":{"rows":[["**Association**","Solid line","Uses or knows about","Field reference"],["**Aggregation**","Open diamond","Has-a (shared lifecycle)","Field reference (nullable)"],["**Composition**","Filled diamond","Has-a (owned lifecycle)","Field reference (created internally)"],["**Inheritance**","Open arrow (to parent)","Is-a","`extends` / `:`"],["**Realization**","Dashed open arrow","Implements interface","`implements` / `:`"],["**Dependency**","Dashed line with arrow","Temporarily uses","Parameter or local variable"]],"caption":"UML Relationship Types and Implementation","headers":["Relationship","UML Symbol","Meaning","Code Pattern"]},"type":"table"},{"data":{"content":"**Deep Dive: Association vs. Aggregation vs. Composition**\n\nThese three relationships are frequently confused, but have distinct implementation implications:\n\n**Association** (simple solid line): Two classes are related and can interact. Neither owns the other.\n\n**Aggregation** (open diamond ◇): \"Has-a\" relationship where the part can exist independently of the whole. The whole doesn't control the part's lifecycle.\n\n**Composition** (filled diamond ◆): \"Has-a\" relationship where the part cannot exist without the whole. The whole creates and destroys the part."},"type":"text"},{"data":{"fileName":"Relationship Implementations","languages":[{"code":"$7c","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Info","title":"Navigability Matters","content":"In UML, an arrow on an association indicates navigability—which direction the relationship can be traversed. A unidirectional arrow means only one class holds a reference to the other. A bidirectional association (or no arrows) means both classes hold references. This affects your implementation: unidirectional is simpler but sometimes bidirectional is required for certain operations.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"multiplicity-cardinality","title":"Handling Multiplicity and Cardinality","content":[{"data":{"content":"Multiplicity in UML specifies how many instances of one class relate to instances of another class. Getting this wrong causes runtime errors or data integrity issues.\n\n**Common Multiplicity Notations:**"},"type":"text"},{"data":{"rows":[["`1`","Exactly one","Required field reference","Non-null check"],["`0..1`","Zero or one (optional)","Nullable field","Null handling"],["`*` or `0..*`","Zero or more","Collection/List","Empty collection OK"],["`1..*`","One or more","Collection (non-empty)","At least one element"],["`n..m`","Range (n to m)","Collection with size validation","Min/max size checks"]],"caption":"UML Multiplicity to Code Mapping","headers":["Multiplicity","Meaning","Code Structure","Validation Required"]},"type":"table"},{"data":{"fileName":"Multiplicity Implementation Patterns","languages":[{"code":"$7d","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Multiplicity Validation Is Not Optional","content":"In interviews and production code alike, ignoring multiplicity constraints is a red flag. If a UML diagram shows [1..*], your code must enforce that the collection is never empty. If it shows [1], the reference must never be null. Failing to implement these constraints means the code doesn't match the design.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"interfaces-abstract-classes","title":"Translating Interfaces and Abstract Classes","content":[{"data":{"content":"Interfaces and abstract classes are the cornerstones of flexible design. They define contracts that concrete classes must fulfill, enabling polymorphism and dependency injection.\n\n**The Key Distinction:**"},"type":"text"},{"data":{"rows":[["**UML Notation**","«interface» stereotype","*Italic* class name"],["**Methods**","All abstract (traditionally)","Mix of abstract and concrete"],["**State**","No instance fields (traditionally)","Can have fields"],["**Inheritance**","Multiple implementation allowed","Single inheritance only"],["**Purpose**","Define contract (what)","Provide partial implementation (how)"]],"headers":["Aspect","Interface","Abstract Class"]},"type":"table"},{"data":{"content":"**Modern Considerations:**\n\n- TypeScript interfaces can have optional methods\n- Java 8+ interfaces can have default implementations\n- C# 8+ interfaces can have default implementations\n\nThese blur the traditional distinction, but the conceptual difference remains: **interfaces define contracts; abstract classes provide skeletal implementations**."},"type":"text"},{"data":{"fileName":"Interface and Abstract Class Patterns","languages":[{"code":"$7e","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"When to Use Each","content":"Use **interfaces** when you want to define a contract that multiple unrelated classes can implement. Use **abstract classes** when you have common behavior to share among related classes, especially when you want to use the Template Method pattern. In modern TypeScript, favor interfaces unless you need constructor logic, protected fields, or shared method implementations.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"sequence-diagrams","title":"Translating Sequence Diagrams to Method Implementations","content":[{"data":{"content":"While class diagrams show static structure, **sequence diagrams show dynamic behavior**—how objects interact over time. Translating sequence diagrams reveals method bodies and call chains.\n\n**Reading a Sequence Diagram:**\n\n1. **Participants** (boxes at top) become the objects you'll call methods on\n2. **Messages** (arrows) become method calls\n3. **Lifelines** (vertical dashed lines) show when objects are active\n4. **Return arrows** (dashed) show return values\n5. **Activation bars** (rectangles on lifelines) show method execution duration\n\n**Key Translation Principles:**\n\n- Each message arrow → A method call\n- Self-referencing arrow → A private method call\n- Return arrow → Return statement\n- Alt/Opt fragments → If/else statements\n- Loop fragments → For/while loops"},"type":"text"},{"data":{"fileName":"Sequence Diagram to Code","languages":[{"code":"$7f","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Info","title":"Fragment Notation Translation","content":"UML sequence diagram fragments map directly to control flow: **alt** → if/else, **opt** → if (no else), **loop** → for/while, **par** → parallel execution (Promise.all, threads), **break** → early return or exception. Look for fragment boxes in the diagram to understand conditional logic.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"translation-pitfalls","title":"Common Translation Pitfalls and How to Avoid Them","content":[{"data":{"content":"Even experienced developers make predictable mistakes when translating UML to code. Understanding these pitfalls helps you avoid them."},"type":"text"},{"data":{"left":[{"data":{"items":["**Ignoring visibility modifiers** — Making everything public 'for convenience'","**Flattening inheritance** — Skipping abstract classes and implementing everything concrete","**Wrong relationship type** — Using composition when aggregation is specified","**Ignoring navigability** — Adding bidirectional references when only one direction is needed","**Missing multiplicity validation** — Not enforcing [1..*] or [0..1] constraints","**Concrete class dependencies** — Depending on implementations instead of interfaces"],"title":{"icon":"XCircle","text":"Common Mistakes","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"right":[{"data":{"items":["**Follow visibility exactly** — Private means private, protected means protected","**Preserve abstraction layers** — Implement all abstract classes and interfaces as designed","**Match relationship semantics** — Use constructor-created fields for composition","**Respect navigability** — Only add references where arrows exist","**Validate at construction and mutation** — Throw errors when constraints are violated","**Depend on abstractions** — Use interfaces/abstract classes as field types"],"title":{"icon":"CheckCircle","text":"Correct Approach","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"fileName":"Pitfall Examples","languages":[{"code":"$80","label":"TypeScript","value":"typescript"}]},"type":"code"}],"titleType":"number","titleNumber":7},{"id":"summary-checklist","title":"Summary: UML-to-Code Translation Checklist","content":[{"data":{"content":"We've covered the comprehensive methodology for translating UML designs into production code. Here's a checklist to use during implementation:"},"type":"text"},{"data":{"type":"ordered","items":["**Classes** — Create all classes, interfaces, and abstract classes from the diagram","**Visibility** — Apply correct visibility modifiers (public, private, protected) exactly as specified","**Attributes** — Implement all fields with correct types and default values","**Operations** — Implement all methods with correct signatures and return types","**Inheritance** — Implement extends and implements relationships correctly","**Associations** — Add field references for associations, following navigability arrows","**Composition** — Create composed objects in the constructor; ensure they can't be replaced","**Aggregation** — Accept aggregated objects via constructor or setter; allow null","**Multiplicity** — Validate cardinality constraints at construction and mutation","**Dependencies** — Use interface types for fields, not concrete implementations"],"title":{"icon":"CheckCircle","text":"UML-to-Code Checklist","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a systematic approach to translating any UML diagram into code. The key is treating UML annotations as requirements, not suggestions. Every visibility modifier, every relationship type, and every multiplicity constraint carries meaning that must be preserved in the implementation. Next, we'll explore the optimal order for implementing classes to maximize productivity and minimize rework.","variant":"success"},"type":"callout"},{"data":{"content":"**What's next:**\n\nNow that we can translate individual UML elements to code, the next page addresses **Class Implementation Order**—determining which classes to implement first to minimize dependencies, enable incremental testing, and maximize productivity during implementation."},"type":"text"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_b1b9f70ff4a403476f0af2aa1007d20d","title":"Class Implementation Order","order":1,"content":null,"isLocked":true},{"id":"seed_7e2e981a57a66be4a047ddf897409225","title":"Interface First, Implementation Second","order":2,"content":null,"isLocked":true},{"id":"seed_bd5be1e5567c3f6c7c8db543eaff920d","title":"Incremental Implementation","order":3,"content":null,"isLocked":true}]}}