Nhiều thuật toán được sử dụng trong điện toán khoa học có cấu trúc vốn có khác với các thuật toán thường được xem xét trong các hình thức kỹ thuật phần mềm ít chuyên sâu về toán học. Cụ thể, các thuật toán toán học riêng lẻ có xu hướng rất phức tạp, thường liên quan đến hàng trăm hoặc hàng nghìn dòng mã, tuy nhiên không liên quan đến trạng thái (nghĩa là không hoạt động theo cấu trúc dữ liệu phức tạp) và thường có thể được đun sôi - về mặt lập trình giao diện - đến một chức năng duy nhất hoạt động trên một mảng (hoặc hai).
Điều này cho thấy rằng một hàm, chứ không phải một lớp, là giao diện tự nhiên cho hầu hết các thuật toán gặp phải trong tính toán khoa học. Tuy nhiên, lập luận này cung cấp một cái nhìn sâu sắc về cách thực hiện các thuật toán phức tạp, đa phần nên được xử lý.
Mặc dù cách tiếp cận truyền thống chỉ đơn giản là có một hàm gọi một số hàm khác, chuyển các đối số có liên quan trên đường đi, OOP cung cấp một cách tiếp cận khác, trong đó các thuật toán có thể được gói gọn thành các lớp. Để rõ ràng, bằng cách gói gọn một thuật toán trong một lớp, tôi có nghĩa là tạo một lớp trong đó các đầu vào thuật toán được nhập vào hàm tạo của lớp, và sau đó một phương thức công khai được gọi để thực sự gọi thuật toán. Việc triển khai multigrid trong C ++ psuedocode có thể giống như:
class multigrid {
private:
x_, b_
[grid structure]
restrict(...)
interpolate(...)
relax(...)
public:
multigrid(x,b) : x_(x), b_(b) { }
run()
}
multigrid::run() {
[call restrict, interpolate, relax, etc.]
}
Câu hỏi của tôi là như sau: những lợi ích và hạn chế của loại thực hành này so với cách tiếp cận truyền thống hơn mà không có lớp học là gì? Có vấn đề về khả năng mở rộng hoặc bảo trì? Để rõ ràng, tôi không có ý định thu hút ý kiến, mà là để hiểu rõ hơn về các hiệu ứng xuôi dòng (tức là những hiệu ứng có thể không phát sinh cho đến khi một cơ sở mã hóa trở nên khá lớn) khi áp dụng một thực hành mã hóa như vậy.