Popularity: ★ ★ ★

Complexity: ★ ✰ ✰

1. Vấn đề

Hãy tưởng tượng bạn đang xây dựng một ứng dụng chỉ đường. Tính năng cốt lõi là tìm và hiển thị tuyến đường nhanh nhất từ điểm A đến điểm B.

Ban đầu, ứng dụng chỉ hỗ trợ tìm đường cho ô tô. Mọi thứ đều tuyệt vời. Nhưng sau đó, người dùng yêu cầu thêm chức năng tìm đường cho người đi bộ và cả phương tiện công cộng.

Để đáp ứng, bạn bắt đầu thêm logic vào class Navigator. Mỗi khi có một phương thức di chuyển mới, bạn lại phải sửa đổi class này.

// Vấn đề: Class Navigator phình to và khó quản lý
class Navigator {
  buildRoute(origin: string, destination: string, transportMode: string): void {
    let route;
    if (transportMode === 'car') {
      route = this.buildCarRoute(origin, destination);
      console.log('Building route for Car...');
      // logic phức tạp để tìm đường cho ô tô
    } else if (transportMode === 'walking') {
      route = this.buildWalkingRoute(origin, destination);
      console.log('Building route for Walking...');
      // logic phức tạp để tìm đường đi bộ
    } else if (transportMode === 'public_transport') {
      route = this.buildPublicTransportRoute(origin, destination);
      console.log('Building route for Public Transport...');
      // logic phức tạp để tìm đường bằng phương tiện công cộng
    }
  }

  // Các phương thức private cho từng loại
  private buildCarRoute(origin: string, destination: string) { /* ... */ }
  private buildWalkingRoute(origin: string, destination: string) { /* ... */ }
  private buildPublicTransportRoute(origin: string, destination: string) { /* ... */ }
}

Nhìn vào đoạn code trên, ta thấy một vài vấn đề nghiêm trọng:

• Vi phạm Nguyên lý Open/Closed: Mỗi khi muốn thêm một phương thức di chuyển mới (ví dụ: xe đạp, tàu hỏa), bạn buộc phải sửa đổi class Navigator. Lý tưởng nhất là chúng ta chỉ nên mở rộng mà không cần sửa đổi code cũ.

• Khó bảo trì: Toàn bộ logic tìm đường cho các phương tiện khác nhau đều bị nhồi nhét vào một class. Khi một thuật toán thay đổi, nó có nguy cơ ảnh hưởng đến các thuật toán khác.

• Khó làm việc nhóm: Nhiều người cùng chỉnh sửa một file dễ gây ra xung đột (merge conflicts).

2. Giải pháp

Strategy Pattern đề xuất một giải pháp thanh lịch: tách các thuật toán này ra thành các đối tượng riêng biệt, gọi là strategies.

Class ban đầu (được gọi là Context) sẽ không trực tiếp thực thi thuật toán nữa. Thay vào đó, nó sẽ chứa một tham chiếu đến một đối tượng strategy và ủy thác công việc cho đối tượng đó.

Hãy áp dụng vào ví dụ ứng dụng chỉ đường:

1. Tạo một interface RouteStrategy: Định nghĩa một phương thức chung mà tất cả các thuật toán tìm đường phải tuân theo.

2. Tạo các Concrete Strategies: Mỗi thuật toán tìm đường (ô tô, đi bộ, xe buýt) sẽ được triển khai trong một class riêng, và class này sẽ implement RouteStrategy.

3. Sửa đổi Context (Navigator): Class Navigator sẽ giữ một đối tượng strategy và sử dụng nó để thực hiện công việc. Nó cũng cung cấp một phương thức để client (nơi gọi đến) có thể thay đổi strategy đang được sử dụng một cách linh hoạt.

// Bước 1: Định nghĩa Strategy Interface
interface RouteStrategy {
  buildRoute(origin: string, destination: string): void;
}

// Bước 2: Tạo các Concrete Strategies
class CarStrategy implements RouteStrategy {
  buildRoute(origin: string, destination: string): void {
    console.log(`Building route for Car from ${origin} to ${destination}...`);
    // Logic tìm đường cho ô tô
  }
}

class WalkingStrategy implements RouteStrategy {
  buildRoute(origin: string, destination: string): void {
    console.log(`Building route for Walking from ${origin} to ${destination}...`);
    // Logic tìm đường đi bộ
  }
}

class PublicTransportStrategy implements RouteStrategy {
  buildRoute(origin: string, destination: string): void {
    console.log(`Building route for Public Transport from ${origin} to ${destination}...`);
    // Logic tìm đường bằng phương tiện công cộng
  }
}

// Bước 3: Sửa đổi Context
class Navigator {
  private routeStrategy: RouteStrategy;

  constructor(strategy: RouteStrategy) {
    this.routeStrategy = strategy;
  }

  // Cho phép thay đổi strategy lúc runtime
  public setStrategy(strategy: RouteStrategy): void {
    this.routeStrategy = strategy;
  }

  // Context ủy thác công việc cho đối tượng strategy
  public buildRoute(origin: string, destination: string): void {
    this.routeStrategy.buildRoute(origin, destination);
  }
}

// === Cách sử dụng (Client code) ===
const origin = "Nhà hát Lớn Hà Nội";
const destination = "Hồ Gươm";

// Khởi tạo Navigator với chiến lược mặc định là ô tô
const navigator = new Navigator(new CarStrategy());
navigator.buildRoute(origin, destination); // Output: Building route for Car...

// Người dùng chọn đi bộ -> thay đổi strategy
navigator.setStrategy(new WalkingStrategy());
navigator.buildRoute(origin, destination); // Output: Building route for Walking...

Với cách tiếp cận này, class Navigator giờ đây đã trở nên gọn gàng. Nó không còn quan tâm đến chi tiết triển khai của từng thuật toán nữa. Nếu muốn thêm phương thức di chuyển mới (ví dụ CyclingStrategy), chúng ta chỉ cần tạo một class mới mà không cần đụng đến code của Navigator.

3. Khi nào nên dùng

• Khi bạn có một đối tượng cần thực hiện một tác vụ theo nhiều cách khác nhau và bạn muốn có thể chuyển đổi giữa các cách đó một cách linh hoạt tại runtime.

• Khi có nhiều class tương tự nhau, chỉ khác ở cách chúng thực thi một hành vi nào đó. Strategy Pattern giúp giảm trùng lặp code bằng cách gom các hành vi đó vào các class riêng.

• Khi bạn muốn tách biệt logic nghiệp vụ của một class khỏi chi tiết triển khai của các hành vi. Điều này giúp code dễ đọc và dễ bảo trì hơn.

• Khi class của bạn chứa một khối if-else hoặc switch-case lớn để lựa chọn giữa các biến thể của cùng một hành vi.

4. Ưu và nhược điểm

Hãy tưởng tượng bạn đang viết một ứng dụng quản lý vận chuyển. Ban đầu, ứng dụng chỉ cần xử lý vận chuyển đường bộ bằng Truck, nên bạn code trực tiếp như sau:

class Truck {
  deliver() {
    console.log("Giao hàng bằng xe tải");
  }
}

class OrderService {
  createOrder() {
    const transport = new Truck();
    transport.deliver();
  }
}

class ReportService {
  generateReport() {
    const transport = new Truck();
    transport.deliver();
  }
}

Ứng dụng chạy tốt. Nhưng khách hàng yêu cầu thêm Ship. Bạn sửa code như sau:

class OrderService {
  createOrder(config: string) {
    if (config === "road") {
      const transport = new Truck();
      transport.deliver();
    } else if (config === "sea") {
      const transport = new Ship();
      transport.deliver();
    }
  }
}

class ReportService {
  generateReport(config: string) {
    if (config === "road") {
      const transport = new Truck();
      transport.deliver();
    } else if (config === "sea") {
      const transport = new Ship();
      transport.deliver();
    }
  }
}

Vấn đề: if/else bị lặp lại ở nhiều nơi. Nếu ngày mai có thêm Plane, bạn lại phải sửa từng service. Hệ thống càng lớn, càng dễ lỗi.

2. Giải pháp

Factory Method tách biệt việc tạo object khỏi logic nghiệp vụ. Thay vì tạo object trực tiếp bằng new, ta định nghĩa một factory method trong lớp cha (Creator). Các lớp con (Concrete Creator) sẽ quyết định tạo ra loại object cụ thể nào (Concrete Product).

Các thành phần chính

• Product: interface hoặc abstract class mô tả bản thiết kế hành vi chung.

• Concrete Product: class cài đặt cụ thể của Product.

• Creator: lớp khai báo factory method, đồng thời chứa logic nghiệp vụ.

• Concrete Creator: lớp con override factory method để tạo ra Concrete Product tương ứng.

// Product
interface Transport {
  deliver(): void;
}

// Concrete Products
class Truck implements Transport {
  deliver() { console.log("Giao hàng bằng xe tải"); }
}

class Ship implements Transport {
  deliver() { console.log("Giao hàng bằng tàu biển"); }
}

// Creator
abstract class Logistics {
  abstract createTransport(): Transport;

  planDelivery() {
    const transport = this.createTransport();
    transport.deliver();
  }
}

// Concrete Creators
class RoadLogistics extends Logistics {
  createTransport(): Transport { return new Truck(); }
}

class SeaLogistics extends Logistics {
  createTransport(): Transport { return new Ship(); }
}

// Client code
const logistics: Logistics =
  config === "road" ? new RoadLogistics() : new SeaLogistics();

class OrderService {
  constructor(private logistics: Logistics) {}
  createOrder() {
    this.logistics.planDelivery();
  }
}

class ReportService {
  constructor(private logistics: Logistics) {}
  generateReport() {
    this.logistics.planDelivery();
  }
}

Bây giờ:

• if/else chỉ dùng một lần duy nhất (chọn Creator).

• Các service (Order, Report, …) không còn chứa if/else, chỉ làm việc với abstraction Logistics.

• Muốn thêm PlaneLogistics → chỉ cần viết thêm class mới, không phải sửa service nào.

3. Khi nào nên dùng

• Khi code của bạn phụ thuộc vào nhiều loại object nhưng không muốn gắn chặt với class cụ thể.

• Khi bạn cần dễ dàng mở rộng để hỗ trợ loại object mới mà không sửa logic chính.

• Khi muốn giảm if/else hoặc switch-case liên quan đến việc tạo object.

• Khi viết framework hoặc thư viện cho phép người dùng tuỳ biến cách tạo object.

4. Ưu và nhược điểm

1. Vấn đề thực tế

Hãy tưởng tượng bạn đang xây dựng một ứng dụng thương mại điện tử. Mỗi khi khách hàng tìm kiếm sản phẩm hoặc kiểm tra thông tin đơn hàng, ứng dụng cần truy vấn cơ sở dữ liệu. Với hàng trăm hoặc hàng nghìn yêu cầu đồng thời, nếu mỗi yêu cầu đều tạo một kết nối mới đến cơ sở dữ liệu, hệ thống sẽ nhanh chóng gặp rắc rối:

• Tạo quá nhiều kết nối làm tiêu tốn tài nguyên (CPU, bộ nhớ, băng thông mạng).

• Hiệu suất giảm do thời gian thiết lập kết nối lặp đi lặp lại.

• Vượt quá giới hạn kết nối tối đa mà cơ sở dữ liệu cho phép, dẫn đến lỗi "connection refused".

Rõ ràng, chúng ta cần một cách tiếp cận thông minh hơn thay vì để ứng dụng tạo kết nối vô tội vạ.

2. Giải pháp ban đầu

Một cách xử lý đơn giản mà nhiều người có thể nghĩ tới là tạo một lớp Database để quản lý kết nối. Mỗi khi cần truy vấn, ta tạo một thể hiện mới của lớp này.

class Database {
    private connection: any; // Giả định đây là kết nối thực tế

    constructor() {
        this.connection = this.createConnection();
    }

    private createConnection() {
        console.log("Tạo kết nối mới đến cơ sở dữ liệu");
        return {}; // Logic tạo kết nối
    }

    public query(sql: string) {
        console.log(`Thực hiện truy vấn: ${sql}`);
    }
}

// Sử dụng
const db1 = new Database();
db1.query("SELECT * FROM users");

const db2 = new Database();
db2.query("SELECT * FROM products");

Cách làm này có vẻ đơn giản, nhưng lại ẩn chứa nhiều vấn đề:

1. Tiêu tốn tài nguyên: Mỗi lần tạo thể hiện mới, một kết nối mới được thiết lập. Điều này tốn thời gian và tài nguyên hệ thống.

2. Hiệu suất kém: Nếu có 100 yêu cầu đồng thời, ứng dụng sẽ tạo 100 kết nối, gây chậm trễ không cần thiết.

3. Dễ vượt giới hạn: Cơ sở dữ liệu thường giới hạn số kết nối đồng thời (ví dụ: 50 hoặc 100). Tạo quá nhiều kết nối có thể khiến hệ thống báo lỗi.

Cách tiếp cận này giống như mỗi lần bạn cần vào nhà lại xây một cánh cửa mới thay vì dùng cửa chính có sẵn – không hiệu quả chút nào!

3. Giới thiệu Singleton Pattern

Để giải quyết vấn đề trên, chúng ta có thể sử dụng Singleton Pattern. Đây là một mẫu thiết kế thuộc nhóm Creational Pattern (Mẫu thiết kế tạo dựng), đảm bảo rằng một lớp chỉ có một thể hiện duy nhất trong toàn bộ ứng dụng, đồng thời cung cấp một điểm truy cập chung để sử dụng thể hiện đó.

Hãy nghĩ về Singleton như một "lối vào chính" của một tòa nhà. Dù có bao nhiêu người cần vào, họ đều đi qua cùng một cánh cửa thay vì mỗi người tự đục một lỗ riêng. Trong trường hợp của chúng ta, "cánh cửa" này là kết nối cơ sở dữ liệu duy nhất được chia sẻ cho mọi yêu cầu.

Ý tưởng chính của Singleton Pattern:

• Ngăn việc tạo nhiều thể hiện bằng cách đặt constructor là private.

• Dùng một phương thức static để kiểm soát việc tạo và truy cập thể hiện duy nhất.

4. Áp dụng Singleton Pattern

Hãy viết lại lớp Database bằng Singleton Pattern để đảm bảo chỉ có một kết nối được tạo:

class DatabaseSingleton {
    private static instance: DatabaseSingleton;
    private connection: any;

    // Constructor private để ngăn tạo thể hiện từ bên ngoài
    private constructor() {
        this.connection = this.createConnection();
    }

    private createConnection() {
        console.log("Tạo kết nối mới đến cơ sở dữ liệu");
        return {}; // Logic tạo kết nối
    }

    public static getInstance(): DatabaseSingleton {
        if (!DatabaseSingleton.instance) {
            DatabaseSingleton.instance = new DatabaseSingleton();
        }
        return DatabaseSingleton.instance;
    }

    public query(sql: string) {
        console.log(`Thực hiện truy vấn: ${sql}`);
    }
}

// Sử dụng
const db = DatabaseSingleton.getInstance();
db.query("SELECT * FROM users");

const dbAgain = DatabaseSingleton.getInstance();
dbAgain.query("SELECT * FROM products");

So sánh trước và sau:

• Trước: Mỗi lần tạo new Database(), một kết nối mới được tạo. Nếu gọi 10 lần, ta có 10 kết nối.

• Sau: Dù gọi getInstance() bao nhiêu lần, chỉ một kết nối được tạo và tái sử dụng.

Khi chạy code trên, bạn sẽ thấy thông báo "Tạo kết nối mới đến cơ sở dữ liệu" chỉ xuất hiện một lần duy nhất. Điều này chứng tỏ tất cả các truy vấn đều dùng chung một kết nối, giúp tiết kiệm tài nguyên đáng kể.

4. Ưu và Nhược điểm

Ưu điểm:

• Tiết kiệm tài nguyên: Chỉ tạo một kết nối và tái sử dụng, giảm tải cho hệ thống.

• Hiệu suất tốt hơn: Không cần thiết lập và đóng kết nối liên tục.

• Kiểm soát tập trung: Dễ dàng quản lý trạng thái kết nối ở một nơi duy nhất.

Nhược điểm:

• Trạng thái toàn cục: Vì thể hiện là duy nhất và có thể truy cập từ mọi nơi, nếu không cẩn thận, bạn có thể vô tình thay đổi trạng thái ở nơi không mong muốn.

• Khó kiểm thử: Việc phụ thuộc vào một thể hiện cố định có thể gây khó khăn khi viết unit test, đặc biệt nếu cần mock hoặc thay thế.

5. Khi nào nên dùng?

Singleton Pattern không phải lúc nào cũng là lựa chọn tốt nhất, nhưng nó rất hữu ích khi bạn nhận thấy những "mùi code" sau:

• Ứng dụng tạo quá nhiều thể hiện của một lớp trong khi chỉ cần một.

• Những tài nguyên (như kết nối cơ sở dữ liệu, kết nối mạng) bị khởi tạo lặp đi lặp lại.

• Nhiều phần của ứng dụng cần truy cập cùng một tài nguyên và bạn muốn tránh xung đột.

Một số trường hợp điển hình để áp dụng:

• Quản lý kết nối cơ sở dữ liệu (như ví dụ trên).

• Xây dựng hệ thống logging để ghi log vào một file duy nhất.

• Quản lý cấu hình ứng dụng (application settings) được dùng chung toàn cục.

Lưu ý thực tế: Trong ứng dụng lớn, một kết nối duy nhất có thể không đủ để xử lý chịu tải cao. Khi đó, bạn có thể kết hợp Singleton với connection pooling (quản lý một tập hợp kết nối). Singleton vẫn hữu ích để đảm bảo chỉ có một pool được tạo.

1. Dependency Injection là gì?

Nói một cách đơn giản, Dependency Injection (tạm dịch: Tiêm phụ thuộc) là một kỹ thuật thiết kế mà trong đó, một đối tượng nhận các "phụ thuộc" (dependencies) từ bên ngoài, thay vì tự tạo ra chúng.

Hãy tưởng tượng bạn có một lớp Car. Để hoạt động, nó cần một Engine.

• Cách thông thường (không dùng DI): Lớp Car sẽ tự mình tạo ra một đối tượng Engine bên trong hàm khởi tạo của nó.

    class Engine {
      start() {
        console.log("Engine started!");
      }
    }
  
    class Car {
      private engine: Engine;
  
      constructor() {
        this.engine = new Engine(); // <-- Tự tạo dependency
      }
  
      startCar() {
        this.engine.start();
      }
    }
  

• Với DI: Chúng ta "tiêm" đối tượng Engine vào Car từ bên ngoài.

Tại sao cần làm vậy?

• Linh hoạt: Dễ dàng thay đổi, nâng cấp các dependency mà không sửa code của lớp sử dụng chúng.

• Dễ kiểm thử (Testable): Có thể "tiêm" các đối tượng giả (mock) khi viết unit test, giúp cô lập và kiểm tra logic một cách độc lập.

• Giảm phụ thuộc cứng (Loose Coupling): Các thành phần trong hệ thống trở nên độc lập hơn, giúp mã nguồn dễ bảo trì và mở rộng.

2. Constructor Injection

Đây là phương pháp phổ biến và được khuyến khích nhất. Dependency được truyền vào qua hàm khởi tạo (constructor).

Ví dụ:

class UserService {
  private logger: ILogger;

  // Dependency ILogger là bắt buộc để tạo ra UserService
  constructor(logger: ILogger) {
    this.logger = logger;
  }

  createUser(name: string) {
    this.logger.log(`User ${name} đã được tạo.`);
  }
}

// === Cách sử dụng ===
const logger = new ConsoleLogger();
const userService = new UserService(logger); // Dependency phải được cung cấp ngay lúc tạo

Ưu điểm:

• Nhìn vào constructor là biết ngay lớp cần những gì để hoạt động.

• Đảm bảo đối tượng luôn ở trạng thái hợp lệ ngay sau khi được tạo, vì tất cả dependency bắt buộc đã có mặt.

Nhược điểm:

• Constructor có thể trở nên dài nếu có quá nhiều dependency (đây là dấu hiệu lớp của bạn đang làm quá nhiều việc).

• Không phù hợp cho các dependency tùy chọn (optional).

3. Setter Injection

Phương pháp này dùng các hàm set để tiêm dependency sau khi đối tượng đã được khởi tạo.

Ví dụ:

class ReportService {
  private emailService?: IEmailService; // Dependency này là tùy chọn

  // Phương thức để tiêm dependency sau
  setEmailService(service: IEmailService) {
    this.emailService = service;
  }

  generateReport() {
    console.log("Đang tạo báo cáo...");
    // Chỉ gửi mail nếu emailService đã được cung cấp
    this.emailService?.send("admin@example.com", "Báo cáo mới.");
  }
}

// === Cách sử dụng ===
const reportService = new ReportService(); // Tạo đối tượng mà không cần dependency
const mailer = new GmailService();
reportService.setEmailService(mailer); // Tiêm sau khi cần

Ưu điểm:

• Rất phù hợp cho các dependency không bắt buộc (optional).

• Cho phép thay đổi dependency ngay cả sau khi đối tượng đã được tạo.

Nhược điểm:

• Có thể quên gọi phương thức set, dẫn đến lỗi null khi chương trình chạy.

• Đối tượng có thể tồn tại ở trạng thái chưa hoàn chỉnh hoặc chưa sẵn sàng hoạt động.

• Các dependency bị phân tán ở nhiều nơi thay vì tập trung tại constructor, làm code khó đọc và khó quản lý hơn.

4. Method Injection

Thay vì tiêm dependency cho toàn bộ đối tượng, chúng ta chỉ truyền nó vào như một tham số cho phương thức cụ thể cần sử dụng nó.

Ví dụ:

// Dependency IFormatter có nhiệm vụ định dạng dữ liệu
interface IFormatter {
  format(data: any): string;
}

class ExporterService {
  // Phương thức này nhận dependency 'formatter' ngay lúc được gọi
  export(data: any[], formatter: IFormatter) {
    console.log("Chuẩn bị xuất dữ liệu...");
    const formattedData = formatter.format(data);
    console.log("Dữ liệu đã định dạng:", formattedData);
  }
}

// === Cách sử dụng ===
const exporter = new ExporterService();
const myData = [{ id: 1, product: "Laptop" }];

// Mỗi lần gọi, ta có thể "tiêm" một dependency khác nhau
exporter.export(myData, new JsonFormatter()); // Dùng JSON formatter
exporter.export(myData, new CsvFormatter());  // Dùng CSV formatter

Ưu điểm:

• Cho phép sử dụng các dependency khác nhau cho mỗi lần gọi phương thức.

• Dependency chỉ tồn tại trong phạm vi của phương thức đó, không ảnh hưởng đến toàn bộ đối tượng.

Nhược điểm:

• Nếu nhiều phương thức trong cùng một lớp cần cùng một dependency, bạn sẽ phải truyền nó vào nhiều lần.

• Danh sách tham số của phương thức trở nên dài, khó quản lý và dễ gây nhầm lẫn nếu có nhiều dependency.

5. Interface Injection

Đây là một phương pháp ít phổ biến hơn, trong đó đối tượng nhận phụ thuộc sẽ triển khai một interface đặc biệt. Interface này không mô tả nghiệp vụ, mà chỉ định nghĩa một phương thức để nhận một phụ thuộc cụ thể.

Sự khác biệt chính với Setter Injection:

• Setter Injection: Injector phải biết tên phương thức setter cụ thể (setLogger, setEmailService, v.v.).

• Interface Injection: Injector chỉ cần biết về interface chung (ILoggerAware). Nó có thể tiêm ILogger cho bất kỳ lớp nào, miễn là lớp đó triển khai ILoggerAware, giúp Injector trở nên chung chung và linh hoạt hơn.

Ví dụ:

interface ILogger {
  log(message: string): void;
}

// Bất kỳ lớp nào triển khai interface này đều "hứa" rằng nó có thể nhận ILogger.
interface ILoggerAware {
  injectLogger(logger: ILogger): void;
}

class ProductService implements ILoggerAware {
  private logger?: ILogger;

  // Đây là phương thức bắt buộc do implement ILoggerAware
  public injectLogger(logger: ILogger): void {
    this.logger = logger;
  }

  createProduct(name: string) {
    // ... logic tạo sản phẩm
    this.logger?.log(`Sản phẩm '${name}' đã được tạo.`);
  }
}

// === Cách sử dụng ===
const productService = new ProductService();
const fileLogger = new FileLogger(); // Một implementation của ILogger

if ("injectLogger" in productService) {
  // Nếu có, nó gọi phương thức từ interface mà không cần biết tên cụ thể của lớp
  (productService as ILoggerAware).injectLogger(fileLogger);
}

productService.createProduct("Macbook Pro M3");

Ưu điểm:

• Injector và Client hoàn toàn độc lập, chúng chỉ giao tiếp qua một interface chung.

• Việc implement một interface như ILoggerAware thể hiện rõ ràng rằng lớp này có một dependency cần được cung cấp từ bên ngoài.

Nhược điểm:

• Phải tạo thêm các interface chỉ để phục vụ mục đích tiêm, gây ra nhiều code "thừa" (boilerplate).

• Buộc lớp Client phải triển khai các phương thức không liên quan trực tiếp đến logic nghiệp vụ của nó.

• Trong hầu hết các ngôn ngữ hiện đại, lợi ích nó mang lại không đủ lớn để đánh đổi sự phức tạp so với Constructor hoặc Setter Injection.

6. Kết luận

• Luôn ưu tiên Constructor Injection: Đây là cách tiếp cận an toàn, rõ ràng và hiệu quả nhất cho các dependency bắt buộc.

• Dùng Setter Injection: Khi bạn cần các dependency tùy chọn hoặc muốn có khả năng thay đổi chúng trong quá trình chạy.

• Method Injection: Được sử dụng khi phụ thuộc chỉ cần thiết cho một phương thức cụ thể và có thể thay đổi linh hoạt trong mỗi lần gọi.

• Interface Injection: Nên được cân nhắc khi bạn muốn tạo ra sự tách biệt tuyệt đối giữa đối tượng Injector và Client thông qua một interface chung, nhưng hãy lưu ý đến sự phức tạp mà nó có thể mang lại.

Ngoài 4 cách trên, còn có Field Injection (Property Injection) cũng tồn tại nhưng ít được dùng. Dù dễ viết nhưng nó làm ẩn đi sự phụ thuộc, khó kiểm thử, giảm tính bất biến, và phụ thuộc vào framework để hoạt động. Điều này khiến code kém rõ ràng, khó bảo trì và khó tái sử dụng.

Bài viết này sẽ cung cấp một cái nhìn tổng quan, dễ hiểu về những thành phần cơ bản của mạng nơ-ron: từ một nơ-ron đơn lẻ, các lớp (layer), đến cách huấn luyện toàn bộ mạng.

1. Nơ-ron: Sự kết hợp giữa hàm tuyến tính và phi tuyến

Hàm tuyến tính là gì?

Về cơ bản, hàm tuyến tính (linear function) là một hàm mô tả mối quan hệ bậc nhất giữa đầu vào và đầu ra. Với một đầu vào duy nhất, ta có:

$$y = ax + b$$

Khi có nhiều đầu vào, ta có:

$$y = w_1 x_1 + w_2 x_2 + \dots + w_n x_n + w_0$$

Để biểu diễn ngắn gọn hơn, ta đưa thêm một biến giả định x₀ = 1, lúc đó:

$$y = \sum_{i=0}^{n} w_i x_i$$

Trong đó, w_i được gọi là trọng số (weight) – thể hiện mức độ ảnh hưởng của mỗi input đến output.

Hàm phi tuyến là gì?

Hàm phi tuyến mô tả mối quan hệ phức tạp hơn, ví dụ như bậc hai, bậc ba, hoặc dạng hàm mũ. Trong AI, những hàm này được dùng để "kích hoạt" đầu ra của một nơ-ron, gọi là hàm kích hoạt (activation function). Một vài hàm kích hoạt ví dụ phổ biến:

• Sigmoid:

  $$\sigma(x) = \frac{1}{1 + e^{-x}}$$

• ReLU:

  $$f(x) = \max(0, x)$$

• Tanh:

  $$\tanh(x) = \frac{e^x - e^{-x}}{e^x + e^{-x}}$$

Kết Hợp Thành Nơ-ron

Một nơ-ron sẽ nhận các giá trị đầu vào, kết hợp với trọng số qua một hàm tuyến tính, sau đó đưa kết quả qua hàm kích hoạt:

$$y = \sigma \left( \sum_{i=0}^{n} w_i x_i \right)$$

Trong đó ϕ là một hàm phi tuyến. Đây chính là công thức tổng quát của một nơ-ron.

2. Layer: Lớp các nơ-ron

Khi nhiều nơ-ron hoạt động song song, cùng nhận một bộ input nhưng với trọng số khác nhau, ta có một layer. Mỗi nơ-ron trong layer này sẽ đưa ra một output riêng. Các layer được chia thành:

• Input Layer: nhận dữ liệu đầu vào (ví dụ: pixel ảnh).

• Hidden Layer: thực hiện các phép tính toán để trích xuất đặc trưng.

• Output Layer: tạo ra kết quả dự đoán cuối cùng (ví dụ: xác suất thuộc các lớp).

3. Mạng nơ-ron: Neural Network

Một mạng nơ-ron nhân tạo (Artificial Neural Network) là một hệ thống gồm nhiều layer được xếp nối tiếp nhau. Đầu ra của layer này là đầu vào của layer kế tiếp. Cấu trúc nhiều lớp giúp mô hình học được cả đặc trưng đơn giản và phức tạp.

Ví dụ trong bài toán nhận diện khuôn mặt:

• Layer đầu: học đặc trưng đơn giản như đường viền, góc cạnh.

• Layer giữa: học hình dạng mắt, mũi, miệng.

• Layer sâu: học được khái niệm trừu tượng như “khuôn mặt người”.

4. Huấn luyện mạng: Cập nhật trọng số

Quá trình huấn luyện (training) là việc điều chỉnh lại các trọng số w_i​ sao cho dự đoán của mô hình ngày càng chính xác hơn. Quá trình này bao gồm:

• Tính toán sai số: giữa đầu ra dự đoán và giá trị thực (gọi là loss).

• Lan truyền ngược (Backpropagation): sai số để tính ảnh hưởng của từng trọng số.

• Cập nhật trọng: số bằng một thuật toán tối ưu (như Gradient Descent).

1. Web Worker

Web Worker là gì?

Web Worker là một cơ chế cho phép chạy các tác vụ JavaScript trong một luồng riêng biệt (background thread), tách biệt khỏi luồng chính (main thread) của trình duyệt. Điều này giúp tránh tình trạng chặn giao diện người dùng khi thực hiện các tác vụ nặng về tính toán.

Ví dụ

Khi bạn chơi game Tetris trên trình duyệt, mỗi khi khối rơi xuống, Web Worker sẽ tính toán va chạm, điểm số, và xử lý logic của trò chơi trong một luồng riêng. Điều này giúp bạn điều khiển khối mượt mà, không bị đứng hình khi game đang xử lý dữ liệu phức tạp phía sau.

Đặc điểm chính

• Chạy trong luồng riêng: Web Worker hoạt động độc lập với luồng chính, không can thiệp vào việc hiển thị giao diện hoặc tương tác của người dùng.
• Không truy cập DOM: Web Worker không thể truy cập trực tiếp vào DOM, window, hoặc các đối tượng liên quan đến giao diện.
• Giao tiếp qua tin nhắn: Sử dụng postMessage() để gửi dữ liệu giữa luồng chính và worker, và onmessage để nhận dữ liệu.
• Loại Worker:
  • Dedicated Worker: Chỉ phục vụ một trang web cụ thể.
  • Shared Worker: Có thể được chia sẻ giữa nhiều tab hoặc cửa sổ trình duyệt.

Ứng dụng

• Xử lý các tác vụ tính toán nặng như xử lý hình ảnh, mã hóa/giải mã dữ liệu, hoặc phân tích dữ liệu lớn.
• Thực hiện các tác vụ nền không cần tương tác trực tiếp với giao diện người dùng.

2. Service Worker

Service Worker là gì?

Service Worker là một loại script nền chạy trong nền, hoạt động như một proxy mạng giữa ứng dụng web và mạng. Chúng được thiết kế để cải thiện trải nghiệm ngoại tuyến, quản lý bộ nhớ cache, và hỗ trợ các tính năng như thông báo đẩy (push notifications).

Ví dụ

Giả sử bạn đang học tiếng Anh trên một trang web, nhưng khi đang trên xe buýt thì mất kết nối. Nhờ có Service Worker, bài học đã được lưu sẵn từ lần truy cập trước sẽ được lấy ra từ cache để hiển thị, giúp bạn tiếp tục học mà không cần mạng — giống như việc lấy sách từ tủ cá nhân đã chuẩn bị sẵn từ trước.

Đặc điểm chính

• Hoạt động như proxy mạng: Service Worker chặn các yêu cầu mạng và có thể trả về dữ liệu từ bộ nhớ cache hoặc mạng.
• Hỗ trợ ngoại tuyến: Cho phép ứng dụng web hoạt động khi không có kết nối internet bằng cách lưu trữ tài nguyên trong Cache API.
• Chạy độc lập với trang web: Service Worker có thể hoạt động ngay cả khi trang web không được mở, hỗ trợ các tác vụ như đồng bộ dữ liệu nền hoặc thông báo đẩy.
• Yêu cầu HTTPS: Service Worker chỉ hoạt động trên các trang web sử dụng HTTPS để đảm bảo an toàn.

Ứng dụng

• Tạo trải nghiệm ngoại tuyến cho ứng dụng web (Progressive Web Apps - PWA).
• Quản lý cache để tăng tốc độ tải trang.
• Hỗ trợ thông báo đẩy và đồng bộ dữ liệu nền.

3. So sánh Web Worker và Service Worker

4. Khi nào nên sử dụng?

• Web Worker: Dùng khi cần xử lý các phép tính phức tạp, như trong game hoặc chỉnh sửa ảnh, để giao diện người dùng vẫn mượt mà và không bị gián đoạn.
• Service Worker: Dùng khi muốn ứng dụng web hoạt động ngoại tuyến, tải nhanh hơn nhờ lưu trữ trước tài nguyên, hoặc hỗ trợ các tính năng như thông báo đẩy và đồng bộ dữ liệu.

1. Redis là gì?

Redis (Remote Dictionary Server) là một cơ sở dữ liệu mã nguồn mở, hoạt động theo mô hình key-value và lưu trữ dữ liệu chủ yếu trong bộ nhớ RAM. Điều này giúp Redis có tốc độ đọc-ghi cực nhanh, lý tưởng cho các ứng dụng cần phản hồi tức thì như caching, quản lý phiên, hoặc phân tích thời gian thực.

2. Tại sao nên sử dụng Redis?

• Hiệu suất cao: Redis hoạt động như một lớp cache. Khi ứng dụng cần dữ liệu, nó kiểm tra Redis trước. Nếu dữ liệu có sẵn (cache hit), ứng dụng lấy ngay từ RAM; nếu không (cache miss), nó lấy từ cơ sở dữ liệu và lưu vào Redis cho lần sau. Điều này giảm tải cho cơ sở dữ liệu và tăng tốc độ phản hồi.

• Tính đồng thời cao: Redis có thể xử lý hàng trăm ngàn yêu cầu mỗi giây nhờ lưu trữ trong RAM, giúp hệ thống chịu tải tốt trong giờ cao điểm.

3. So sánh Redis và Memcached

4. Các kiểu dữ liệu phổ biến trong Redis và kịch bản sử dụng

• String: Kiểu dữ liệu cơ bản nhất.
  → Lưu trữ cache đơn giản (HTML, JSON), làm bộ đếm (số lượt xem, lượt thích).

• Hash: Một map chứa các cặp field-value.
  → Lưu thông tin có cấu trúc như hồ sơ người dùng (ví dụ: user_id -> {name: "Nam", email: "nam@example.com", age: 25}).

• List: Danh sách chuỗi sắp xếp theo thứ tự chèn.
  → Xây dựng dòng thời gian (social media feed), hàng đợi tin nhắn (message queue).

• Set: Tập hợp chuỗi không thứ tự, các phần tử duy nhất.
  → Lưu trữ tag bài viết, tìm bạn chung, hoặc danh sách sở thích.

• Sorted Set (Zset): Tập hợp có điểm số (score) để sắp xếp.
  → Tạo bảng xếp hạng (leaderboard), theo dõi người dùng online (sắp xếp theo thời gian đăng nhập cuối).

5. Redis giải quyết cơ chế hết hạn và sự cố cache như thế nào?

Cơ chế hết hạn dữ liệu

• Xóa định kỳ: Redis ngẫu nhiên quét một số key có thời gian hết hạn và xóa chúng nếu đã quá hạn.

• Xóa khi truy cập: Khi client truy cập một key hết hạn, Redis xóa ngay và trả về null.

Các sự cố cache phổ biến

• Cache Breakdown/Penetration: Khi nhiều yêu cầu cùng hỏi một key không tồn tại, tất cả dồn xuống cơ sở dữ liệu, gây quá tải.

• Cache Avalanche: Nhiều key hết hạn cùng lúc, khiến lượng lớn yêu cầu đổ về cơ sở dữ liệu.

Giải pháp

• Khóa phân tán (Distributed Lock): Sử dụng Redis để quản lý truy cập, tránh quá tải hệ thống bằng cách áp dụng khóa bi quan (pessimistic lock) hoặc lạc quan (optimistic lock).

• Khởi tạo cache trước (Pre-heating): Tải dữ liệu vào cache trước khi cần, đặc biệt hữu ích khi dự đoán được giờ cao điểm.