Classes in Detail: Constructors, Static Members, UML and Program Structure

Lớp Account.

class Account
  private String number
  private double balance
  private static int count = 0
  public Account(String number)
    this.number = number
    this.balance = 0
    count = count + 1
  end constructor
  public void deposit(double amount)
    if amount > 0 then balance = balance + amount
  end method
  public boolean withdraw(double amount)
    balance = balance - amount
    return true
  end method
  public double getBalance() return balance
  public static int getCount() return count
end class

Lớp SavingsAccount.

class SavingsAccount extends Account
  private double rate
  public SavingsAccount(String number, double rate)
    super(number)
    this.rate = rate
  end constructor
  public boolean withdraw(double amount)
    if amount > getBalance() then return false
    return super.withdraw(amount)
  end method
  public void addInterest() deposit(getBalance() * rate)
end class

Vì sao count tĩnh. Số tài khoản đã tạo là thuộc tính của lớp, không của một tài khoản cụ thể nào; nếu count là thuộc tính thường, mỗi đối tượng có bản riêng và không bản nào biết tổng. Tĩnh nghĩa là một bản duy nhất, tăng trong hàm khởi tạo, đọc qua phương thức tĩnh mà không cần đối tượng.

Vì sao balance riêng tư. Nếu công khai, mã bên ngoài có thể đặt số dư âm hoặc bỏ qua kiểm tra của withdraw; riêng tư buộc mọi thay đổi đi qua deposit và withdraw, nơi quy tắc được kiểm. Hệ quả nhìn thấy trong mã: SavingsAccount là lớp con nhưng vẫn phải dùng getBalance và super.withdraw thay vì chạm thẳng balance — đóng gói áp dụng cả với lớp con.

Cách A. loop I from 0 to N − 1: if ACCOUNTS[I] is SavingsAccount then addInterest, else if CurrentAccount then chargeOverdraft. Nó chạy đúng hôm nay, nhưng logic loại tài khoản nào làm gì nằm ở nơi gọi, và mọi nơi khác có vòng lặp tương tự — in sao kê, tính thuế — đều lặp lại chuỗi if đó.

Cách B. Account khai báo monthEnd() (có thể rỗng hoặc trừu tượng); SavingsAccount ghi đè để cộng lãi; CurrentAccount ghi đè để tính phí. Vòng lặp chỉ còn ACCOUNTS[I].monthEnd(), và phiên bản đúng được chọn lúc chạy theo lớp thật của đối tượng. Logic của mỗi loại nằm trong lớp đó, đúng nơi người bảo trì tìm.

Thêm StudentAccount sau một năm. Với A, phải tìm mọi vòng lặp có chuỗi if trong toàn chương trình và thêm một nhánh; bỏ sót một chỗ là lỗi im lặng — tài khoản sinh viên bị bỏ qua cuối tháng mà không ai báo. Với B, viết lớp mới với monthEnd() riêng, và mọi vòng lặp hiện có tự động xử lý nó mà không sửa một dòng nào. Đây là lý do thật của đa hình: không phải mã ngắn hơn, mà là thay đổi được khoanh vùng trong lớp mới thay vì rải khắp chương trình.

Cái giá cần nêu. Cách B đòi thiết kế trước — quyết định monthEnd() thuộc về Account từ đầu — và khi đọc mã, người ta không thấy ngay điều gì xảy ra ở dòng ACCOUNTS[I].monthEnd() mà phải mở từng lớp con. Với chương trình hai loại tài khoản không bao giờ đổi, cách A không sai; đa hình trả công khi hệ thống lớn lên.