Design Patterns Cheatsheet

Là gì: Tách query DB ra khỏi business logic.

Khi dùng: Mọi service tương tác DB — đừng để service gọi Prisma trực tiếp.

class UserRepository {
  async findById(id: string) {
    return prisma.user.findUnique({ where: { id } });
  }
}

class UserService {
  constructor(private userRepo: UserRepository) {}
  async getUserProfile(id: string) {
    const user = await this.userRepo.findById(id);
    if (!user) throw new NotFoundException();
    return this.sanitize(user);
  }
}

Interview Q: Khi nào Repository over-engineering? → App nhỏ < 5 tables, không có nhu cầu đổi ORM.

Là gì: Tách business logic khỏi controller. Controller chỉ parse HTTP + delegate.

Khi dùng: Luôn dùng khi có hơn 5-line logic per endpoint.

// controller — thin
@Controller('orders')
class OrderController {
  constructor(private orderService: OrderService) {}
  @Post() create(@Body() dto: CreateOrderDto) {
    return this.orderService.createOrder(dto);
  }
}

// service — thick
class OrderService {
  async createOrder(dto: CreateOrderDto) {
    // validation, calculation, side effects
  }
}

Interview Q: Tại sao controller phải thin? → Service không phụ thuộc HTTP framework → reuse được trong CLI, queue worker, GraphQL.

Là gì: Class không tự tạo dependencies, nhận từ ngoài (constructor).

Khi dùng: Luôn dùng trong NestJS. Manual trong Express với tsyringe.

// ❌ Hard-coded — không test được
class OrderService {
  private emailer = new EmailService();
}

// ✅ DI — inject từ ngoài
class OrderService {
  constructor(private emailer: IEmailService) {}
}
// Test: new OrderService(mockEmailer)

Interview Q: DI khác Service Locator? → DI push vào constructor (minh bạch). Service Locator code tự kéo (ẩn). DI testable hơn.

Là gì: Đóng gói thuật toán có thể đổi runtime.

Khi dùng: Nhiều "cách làm cùng việc" — vd: 3 payment provider (Stripe, Paypal, SePay).

interface PaymentStrategy {
  charge(amount: number): Promise<Result>;
}

class StripeStrategy implements PaymentStrategy { /* ... */ }
class SepayStrategy implements PaymentStrategy { /* ... */ }

class CheckoutService {
  constructor(private payment: PaymentStrategy) {}
  async process(amount: number) {
    return this.payment.charge(amount);
  }
}

Interview Q: Strategy khác if-else? → If-else vi phạm Open-Closed (sửa code cũ). Strategy mở rộng = thêm class mới.

Là gì: Tách stateful logic ra hàm useXxx().

Khi dùng: Logic 2+ component cùng dùng.

function useDebouncedValue<T>(value: T, delayMs: number): T {
  const [debounced, setDebounced] = useState(value);
  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delayMs);
    return () => clearTimeout(id);
  }, [value, delayMs]);
  return debounced;
}

// const debouncedSearch = useDebouncedValue(search, 300);

Interview Q: Khi nào extract? → Rule of 3 — chờ thấy 3 lần duplicate mới extract.

Là gì: Tách "smart" (fetch + state) khỏi "dumb" (chỉ render).

Khi dùng: Storybook + design system. Tanstack Query nay thay phần lớn.

// Container — fetches data
function UserListContainer() {
  const { data, isLoading } = useUsers();
  if (isLoading) return <Spinner />;
  return <UserList users={data} />;
}

// Presentational — pure UI
function UserList({ users }: { users: User[] }) {
  return <ul>{users.map(u => <li>{u.name}</li>)}</ul>;
}

Interview Q: Còn dùng không? → Vẫn cho design system: Presentational components dễ document và visual test.

Là gì: Component chia nhiều sub-component, share state ngầm qua Context.

Khi dùng: Tabs, Accordion, Select — cần flexibility.

<Tabs defaultValue="profile">
  <Tabs.List>
    <Tabs.Tab value="profile">Profile</Tabs.Tab>
    <Tabs.Tab value="settings">Settings</Tabs.Tab>
  </Tabs.List>
  <Tabs.Panel value="profile">...</Tabs.Panel>
  <Tabs.Panel value="settings">...</Tabs.Panel>
</Tabs>

Interview Q: Vì sao không 1 component lớn nhận tabs prop? → Compound = layout flexibility, dev tự custom.

Là gì: Wrap subtree, share state cho descendants không cần prop drilling.

Khi dùng: Theme, Auth, i18n — data ÍT thay đổi.

const AuthContext = createContext<AuthState | null>(null);

function AuthProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<User | null>(null);
  return <AuthContext.Provider value={{ user, setUser }}>
    {children}
  </AuthContext.Provider>;
}

function useAuth() {
  const ctx = useContext(AuthContext);
  if (!ctx) throw new Error('useAuth must be inside AuthProvider');
  return ctx;
}

Interview Q: Khi nào Context KHÔNG nên dùng? → Data đổi mỗi giây → re-render storm → dùng Zustand/Redux.

Composition over Inheritance

Slogan: "has-a" tốt hơn "is-a".

// ❌ Inheritance — rigid
class FlyingDuck extends Duck { fly() {} }

// ✅ Composition — flexible
class Duck {
  constructor(private flyBehavior: FlyBehavior) {}
  fly() { this.flyBehavior.fly(); }
}
// new Duck(new RealFly()) hoặc new Duck(new NoFly())

React favors composition — props.children là composition.

YAGNI · KISS · DRY

• YAGNI: You Aren't Gonna Need It. Đừng code feature "biết đâu sau dùng".
• KISS: Keep It Simple, Stupid. Code đơn giản nhất giải quyết được = best.
• DRY: Don't Repeat Yourself. Duplicate 3+ lần → extract.

Cẩn thận: DRY over-applied → abstraction sớm sai. Rule of 3: chờ 3 lần duplicate.