Sự gắn kết hợp lý là gì và tại sao nó xấu hoặc không mong muốn?


10

Từ trang c2wiki về khớp nối & sự gắn kết :

Sự gắn kết (phụ thuộc lẫn nhau trong mô-đun) tên sức mạnh / cấp độ: (từ xấu hơn đến tốt hơn, độ gắn kết cao là tốt)

  • Sự gắn kết trùng hợp: (tệ nhất) Các yếu tố mô-đun không liên quan
  • Sự gắn kết logic: Các phần tử thực hiện các hoạt động tương tự như được chọn từ mô-đun bên ngoài, tức là bằng một cờ chọn thao tác để thực hiện (xem thêm CommandObject). tức là phần thân của hàm là một if-other / switch trên cờ hoạt động
  • Sự gắn kết tạm thời: các hoạt động chỉ liên quan đến thời gian chung được thực hiện (nghĩa là khởi tạo () hoặc FatalErrorShutdown? ())
  • Sự gắn kết theo thủ tục: Các yếu tố liên quan đến các hoạt động khác nhau nhưng tuần tự, mỗi yếu tố trên các dữ liệu khác nhau (thường có thể được chia thành nhiều mô đun theo các ranh giới chuỗi tuyến tính)
  • Sự gắn kết giao tiếp: các hoạt động không liên quan ngoại trừ cần cùng một dữ liệu hoặc đầu vào
  • Sự gắn kết tuần tự: các hoạt động trên cùng một dữ liệu theo thứ tự quan trọng; đầu ra từ một chức năng là đầu vào tiếp theo (đường ống)
  • Sự gắn kết thông tin: một mô-đun thực hiện một số hành động, mỗi hành động có điểm vào riêng, với mã độc lập cho từng hành động, tất cả được thực hiện trên cùng một cấu trúc dữ liệu. Về cơ bản là việc thực hiện một kiểu dữ liệu trừu tượng. tức là xác định cấu trúc của sales_region_table và các toán tử của nó: init_table (), update_table (), print_table ()
  • Sự gắn kết chức năng: tất cả các yếu tố đóng góp vào một tác vụ được xác định rõ ràng, tức là một hàm thực hiện chính xác một thao tác get_engine_tem Nhiệt độ (), add_sales_tax ()

(nhấn mạnh của tôi).

Tôi không hiểu đầy đủ định nghĩa về sự gắn kết hợp lý. Câu hỏi của tôi là:

  • sự gắn kết logic là gì?
  • Tại sao nó lại có được một bản rap tệ như vậy (loại gắn kết tồi tệ thứ 2)?

Câu trả lời:


7

Sự gắn kết logic có thể là xấu bởi vì bạn kết thúc chức năng nhóm theo các đặc tính kỹ thuật hơn là các đặc điểm chức năng. Ví dụ, hãy xem xét một ứng dụng bao gồm nhiều mô-đun. Mỗi mô-đun đại diện cho một số lĩnh vực kinh doanh và có mã truy cập dữ liệu tương ứng. Nếu bạn nhóm tất cả mã truy cập dữ liệu trên tất cả các mô-đun thì bạn có sự gắn kết hợp lý. Rốt cuộc, đó là tất cả quyền truy cập dữ liệu và trong một số trường hợp, việc đánh giá các mẫu truy cập dữ liệu của một ứng dụng là có lợi. Tuy nhiên, điều này có vấn đề vì miền doanh nghiệp cung cấp ranh giới mô-đun, không phải miền kỹ thuật. Bằng cách đạt được sự gắn kết hợp lý, bạn sẽ mất đi sự gắn kết chức năng. Thông thường, miền doanh nghiệp xác định một đơn vị triển khai được xác định rõ và các khía cạnh kỹ thuật có sẵn để hỗ trợ miền doanh nghiệp.


Đó là một câu trả lời tốt, mặc dù để tránh nhầm lẫn, tôi đã đề cập rằng trong bối cảnh lập trình hướng đối tượng (và các ví dụ trên Wikipedia và c2wiki), một mô-đun về cơ bản là một lớp. Điều này có nghĩa là nhận xét về "rất lớn nếu / khác" cũng có ý nghĩa hơn.
Daniel B

2

Từ cách nó được mô tả, tôi sẽ nói rằng đó là về việc ghép mã với nhau có một số sự gắn kết, nhưng phá vỡ hướng đối tượng.

Ví dụ: tính diện tích đa giác. Khi bạn đặt phép tính cho hình vuông cùng với phép tính cho tam giác và chỉ chọn theo tham số đầu vào, thì bạn đã nhóm hai điều một cách hợp lý theo kết quả của chúng, không tính đến bản chất thực của chúng.


0

Ý kiến ​​cá nhân của tôi là logicalthuật ngữ đó đã được chọn xấu và dẫn đến nhầm lẫn. Chúng tôi có xu hướng nghĩ rằng đó logicallà tốt. Trong nhiều kịch bản functionalcó thể được hoán đổi với logical.

Tôi sẽ thay thế logicalbằng technical thuật ngữ vì bạn tập trung vào phần kỹ thuật hơn là (và tôi muốn sử dụng từ logicalở đây nhưng nó sẽ gây hiểu nhầm trong bối cảnh của cuộc thảo luận này) những gì thành phần này làm cho toàn bộ hệ thống.

Một ví dụ điển hình có thể là nhóm các lớp cung cấp điểm cuối cho một số API.
Nếu bạn nhóm chúng trong một số thư mục vì chúng cung cấp điểm cuối thì đó là a technical cohesion. Nếu bạn nhóm chúng vì chúng cung cấp một số chức năng (ví dụ như danh sách người dùng quản lý) thì đó làfunctional cohesion


Hơn nữa, tôi cũng sẽ thách thức functionalthuật ngữ ở đây vì nó quá rộng. Nó có thể tham chiếu chức năng như xây dựng cú pháp cũng như chức năng của một điều. Trong ví dụ trên, một lớp điểm cuối có 2 chức năng: điểm cuối và logic nghiệp vụ.

Tôi sẽ thay thế functionalđể logical. Nó đề cập đến business logic, nó đề cập đến logical viewmô hình xem phần mềm 4 + 1 và nói chung, chúng ta có xu hướng gọi mọi thứ là "hợp lý" khi chúng đúng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.