5.3. Design Building Blocks: Heuristics

Quá trình thiết kế phần mềm, như đã đề cập trong Phần 3 , là quá trình heuristic hay đó là quá trình thử và sai liên tục để tìm ra thiết kế tốt nhất ( và có thể tốt hơn nữa trong tương lai).

Cách tiếp cận đầu tiên và phổ biến nhất là xác định và hệ thống hóa các đối tượng từ thế giới thực theo cách tiếp cận hướng đối tượng. Gồm 5 bước cơ bản:

  • Xác định các đối tượng và các thành phần của chúng (phương thức (methods), thuộc tính (properties), dữ liệu (fields));
  • Xác định mức chi tiết hơn về các chức năng của đối tượng hay nói cách khác là xác định xem mỗi đối tượng có thể làm những gì;
  • Xác định cách thức giao tiếp giữa các đối tượng;
  • Xác định các thành phần nào của một đối tượng có thể được nhìn thấy bởi đối tượng khác (public), bởi đối tượng thừa kế (protected), hay không được phép nhìn thấy(private);
  • Định nghĩa giao diện (interface) cho các đối tượng.

Các đặc điểm quan trọng của một thiết kế hướng đối tượng

  • Trừu tượng (Abstraction): làm việc với những khái niệm cốt lõi và bỏ qua những chi tiết. Những lớp cơ sở (base classes) chỉ bao gồm những thành phần chung và phổ biến của các đối tượng mà không quan tâm đến các chi tiết.
  • Đóng gói (Encapsulation): là khả năng che giấu thông tin quan trọng từ các đối tượng trước các đối tượng khác ( hay người dùng).
  • Thừa kế (Inheritance): là đặc điểm quan trọng nhất trong thiết kế hướng đối tượng. Thừa kế cho phép các đối tượng sử dụng lại các thành phần từ các đối tượng khác mà không cần định nghĩa lại. Thừa kế cũng hỗ trợ khả năng cho phép định nghĩa lại các thành phần được thừa kế theo mục đích của đối tượng con. Khả năng này được gọi là Đa hình (Polymophism).

Một thiết kế tốt cũng sẵn sàng cho sự thay đổi đến từ:

  • Các quy định về nghiệp vụ (Bussiness rules)
  • Phần cứng (Hardware dependencies)
  • Dữ liệu đầu vào và kết quả đầu ra (Input and Output)
  • Các đặc trưng không chuẩn của ngôn ngữ (Nonstandard language features)
  • Bên cạnh đó là các yếu tố khác như những khó khăn trong thiết kế, cách dùng các biến trạng thái hay sự ràng buộc dữ liệu.

Một đặc điểm khác của một thiết kế tốt là thỏa mãn nguyên tắc Keep Coupling Loose. Nguyên tắc này cho phép các lớp, các phương thức hay các mô-đun được thiết kế sao cho có thể giao tiếp dễ dàng với các lớp, phương thức hay mô-đun khác. Sự giao tiếp hướng đến 3 tiêu chuẩn:

  • Kích cỡ (Size): Giữ mức tối thiểu về số lượng như số lượng kết nối giữa các lớp, mô-đun hay số tham số của các phương thức.
  • Có thể nhìn thấy (Visibility): Cho phép sự kết nối giữa các mô-đun hay lớp
  • Mềm dẻo (Flexibility): Có thể thay đổi sự kết nối một cách dễ dàng, nhanh chóng theo sự thay đổi.

Một vài dạng quan hệ (hay Coupling):

  • Simple-data-parameter coupling: Hai mô-đun có quan hệ kiểu này nếu các dữ liệu trao đổi giữa chúng có kiểu dữ liệu sơ cấp (primitive data types) và được trao đổi thông qua danh sách tham số (parameter list).
  • Simple-object coupling: Một mô-đun có quan hệ với một đối tượng theo kiển này nếu nó (mô-đun) khởi tạo (instantiate) đối tượng đó.
  • Object-parameter coupling: Hai mô-đun quan hệ theo kiểu này nếu Object1 yêu cầu Object2 truyền cho nó một Object3.
  • Semantic coupling: Hai mô-đun, mặc dù có cú pháp khác nhau, có các thành phần tương đồng với nhau về mặc ngữ nghĩa (“semantic”). Đây là quan hệ nguy hiểm vì sẽ dẫn đến một số lỗi không thể phát hiện được bởi trình biên dịch.