Thiết kế trong ngôn ngữ hỗn hợp của người Viking: thiết kế hướng đối tượng hoặc lập trình chức năng?

Trong vài năm qua, các ngôn ngữ tôi muốn sử dụng ngày càng trở nên "chức năng" hơn. Bây giờ tôi sử dụng các ngôn ngữ là một loại "lai": C #, F #, Scala. Tôi thích thiết kế ứng dụng của mình bằng các lớp tương ứng với các đối tượng miền và sử dụng các tính năng chức năng trong đó điều này giúp mã hóa dễ dàng hơn, trùng khớp hơn và an toàn hơn (đặc biệt là khi hoạt động trên các bộ sưu tập hoặc khi truyền chức năng).

Tuy nhiên, hai thế giới "đụng độ" khi đến với các mẫu thiết kế. Ví dụ cụ thể mà tôi phải đối mặt gần đây là mẫu Observer. Tôi muốn nhà sản xuất thông báo cho một số mã khác ("người tiêu dùng / người quan sát", giả sử bộ lưu trữ DB, bộ ghi, v.v.) khi một mục được tạo hoặc thay đổi.

Ban đầu tôi đã làm nó "chức năng" như thế này:

producer.foo(item => { updateItemInDb(item); insertLog(item) })
// calls the function passed as argument as an item is processed

Nhưng bây giờ tôi đang tự hỏi liệu tôi có nên sử dụng cách tiếp cận "OO" hơn không:

interface IItemObserver {
  onNotify(Item)
}
class DBObserver : IItemObserver ...
class LogObserver: IItemObserver ...

producer.addObserver(new DBObserver)
producer.addObserver(new LogObserver)
producer.foo() //calls observer in a loop

Đó là pro và con của hai cách tiếp cận? Tôi đã từng nghe một chuyên gia về FP nói rằng các mẫu thiết kế chỉ tồn tại vì những hạn chế của ngôn ngữ và đó là lý do tại sao có rất ít ngôn ngữ chức năng. Có lẽ đây có thể là một ví dụ về nó?

EDIT: Trong kịch bản cụ thể của tôi, tôi không cần nó, nhưng .. bạn sẽ thực hiện loại bỏ và thêm "quan sát viên" theo cách chức năng như thế nào? (Tức là làm thế nào bạn sẽ thực hiện tất cả các chức năng trong mẫu?) Chỉ cần chuyển một chức năng mới, ví dụ?

Đó là một ví dụ điển hình về hai cách tiếp cận khác nhau mang khái niệm thực hiện một nhiệm vụ bên ngoài ranh giới quan tâm đối với đối tượng gọi.

Mặc dù trong ví dụ này rõ ràng rằng bạn nên sử dụng phương pháp tiếp cận chức năng, nói chung, nó sẽ thực sự phụ thuộc vào mức độ phức tạp của hành vi mà đối tượng được gọi phải thể hiện. Nếu đó thực sự là một vấn đề của hành vi phức tạp, nơi bạn sẽ thấy mình thường xuyên áp dụng logic tương tự và các trình tạo hàm không thể được sử dụng để diễn đạt rõ ràng, thì có lẽ bạn sẽ muốn đi theo thành phần lớp hoặc kế thừa, nơi bạn sẽ có thêm một chút tự do để sử dụng lại và mở rộng hành vi hiện có trên cơ sở đặc biệt.

Tuy nhiên, một mô hình mà tôi đã quan sát được là các nhà phát triển thường sử dụng phương pháp tiếp cận chức năng ban đầu và chỉ khi nhu cầu về hành vi chi tiết hơn phát sinh, họ quyết định đi theo cách tiếp cận dựa trên lớp. Tôi biết, chẳng hạn, Django đã chuyển từ các chế độ xem dựa trên chức năng, trình tải mẫu và người chạy thử nghiệm sang các chế độ dựa trên lớp một khi lợi ích và yêu cầu trở nên rõ ràng, nhưng không phải trước đó.

Phiên bản chức năng ngắn hơn nhiều, dễ bảo trì, dễ đọc hơn và nói chung, vượt trội hơn rất nhiều về mọi khía cạnh có thể tưởng tượng được.

Mặc dù vậy, nhiều thứ khác xa so với tất cả các mẫu là để bù đắp cho việc thiếu các tính năng trong OOP, chẳng hạn như Người quan sát. Đó là những mô hình tốt hơn nhiều chức năng.

"Guru guru" của bạn là một phần đúng; nhiều mẫu OO là hack để làm những việc chức năng. (Ông cho rằng đây là lý do có ít ngôn ngữ FP có vẻ không rõ ràng nhất.) Các mẫu Quan sát và Chiến lược đang cố gắng mô phỏng các chức năng hạng nhất. Mẫu khách truy cập là một bản hack để mô phỏng khớp mẫu. Của bạn IItemObserverchỉ là một chức năng trong ngụy trang. Giả vờ nó khác với bất kỳ chức năng nào khác có một mặt hàng không mua cho bạn bất cứ thứ gì.

Đối tượng chỉ là một loại trừu tượng dữ liệu. Bài viết này sẽ giúp làm sáng tỏ chủ đề đó. Các đối tượng có thể hữu ích, nhưng điều quan trọng là phải nhận ra chúng không phù hợp với mọi thứ. Không có sự phân đôi; chỉ đơn giản là vấn đề chọn công cụ phù hợp cho công việc phù hợp và lập trình chức năng không có cách nào yêu cầu bạn từ bỏ các đối tượng. Điều đó sang một bên, lập trình chức năng không chỉ là sử dụng các chức năng. Đó cũng là về việc giảm thiểu tác dụng phụ và đột biến.

Tôi thực sự không thể trả lời câu hỏi vì tôi không giỏi ngôn ngữ chức năng; nhưng tôi nghĩ bạn nên ít quan tâm đến cách tiếp cận miễn là những gì bạn có hiệu quả. Theo những gì tôi hiểu, miễn là bạn không thêm nhiều người nghe trong tương lai hoặc không thay đổi người nghe trong khi thực hiện, bạn rất có thể bỏ qua mẫu Người quan sát ở đây.

Tôi không đồng ý rằng các mẫu thiết kế tạo nên "hạn chế" trong các ngôn ngữ OO. Họ ở đó để sử dụng tốt các tính năng OOP. Đa hình và kế thừa là các tính năng, không giới hạn. Các mẫu thiết kế sử dụng các tính năng này để thúc đẩy thiết kế linh hoạt. Bạn có thể tạo một chương trình hoàn toàn không phải OO trong OO. Bạn có thể, rất cẩn thận, viết toàn bộ chương trình chứa các đối tượng không có trạng thái, bắt chước FP.