Có sự khác biệt giữa một thành phần và một mô-đun

Tôi có một vấn đề nhỏ với các điều khoản mô-đun và thành phần. Trong tâm trí của tôi, một mô-đun là các lớp được đóng gói, chỉ có thể truy cập thông qua một giao diện được xác định rõ. Họ ẩn tất cả các chi tiết thực hiện và có thể tái sử dụng. Các mô-đun xác định các mô-đun mà chúng phụ thuộc vào.

Sự khác biệt cho các thành phần là gì? Tôi đã tìm nó trong một số cuốn sách, nhưng mô tả về các thành phần rất giống nhau.

Các điều khoản tương tự nhau. Tôi thường nghĩ về một "mô-đun" lớn hơn một "thành phần". Một thành phần là một phần duy nhất, thường tương đối nhỏ trong phạm vi, có thể là mục đích chung. Các ví dụ bao gồm các điều khiển UI và "các thành phần nền" như bộ định thời, trợ lý luồng, v.v. "Mô-đun" là một phần lớn hơn của tổng thể, thường là một thứ thực hiện chức năng chính phức tạp mà không bị nhiễu bên ngoài. Nó có thể là thư viện lớp của một ứng dụng cung cấp tích hợp với e-mail hoặc cơ sở dữ liệu. Nó có thể lớn bằng một ứng dụng duy nhất của một bộ, chẳng hạn như "mô-đun khoản phải thu" của nền tảng ERP / kế toán.

Tôi cũng nghĩ về "các mô-đun" là có thể thay thế cho nhau. Các thành phần có thể được sao chép, với các thành phần mới trông giống như cũ nhưng theo cách nào đó "tốt hơn", nhưng thông thường, thiết kế của hệ thống phụ thuộc chặt chẽ hơn vào một thành phần (hoặc thay thế được thiết kế để phù hợp với hành vi rất cụ thể của thành phần đó). Theo thuật ngữ phi máy tính, một "thành phần" có thể là khối động cơ của ô tô; bạn có thể sửa lại bên trong động cơ, thậm chí thay thế hoàn toàn, nhưng chiếc xe phải có động cơ và nó phải tuân theo các thông số kỹ thuật rất cứng nhắc như kích thước, trọng lượng, điểm lắp, v.v. để thay thế động cơ "cổ" mà xe ban đầu được thiết kế để có. Mặt khác, một "mô-đun" ngụ ý chức năng "trình cắm thêm"; bất kể mô-đun đó là gì, nó có thể được liên lạc theo cách nhẹ đến mức có thể loại bỏ mô-đun và / hoặc thay thế với hiệu quả tối thiểu trên các phần khác của hệ thống. Hệ thống điện của một ngôi nhà có tính mô-đun cao; bạn có thể cắm bất cứ thứ gì với phích cắm 120V15A vào bất kỳ ổ cắm 120V15A nào và mong muốn thứ bạn đang cắm vào hoạt động. Hệ thống dây điện trong nhà không thể quan tâm đến những gì được cắm ở đâu, miễn là nhu cầu năng lượng trong bất kỳ nhánh nào của hệ thống không vượt quá giới hạn an toàn.

Ý nghĩa chung của mô-đun là một nhóm mã có thể tái sử dụng, không gắn với một chương trình cụ thể. Đây có thể là tất cả mọi thứ từ toàn bộ các thư viện GUI cho đến một lớp duy nhất.

Ý nghĩa chung của thành phần là một mô-đun với sự hạn chế bổ sung về khả năng thay thế bằng cách sử dụng một giao diện cụ thể. Nếu bạn tạo một thành phần Widget Widget, nó có thể được sử dụng ở bất cứ nơi nào mà Widget dự kiến, mà không phải làm gì đặc biệt trong mã gọi. Các mô-đun nói chung không có hạn chế như vậy. Qt và GTK + là các mô-đun, nhưng tôi không thể trao đổi cái này với cái kia mà không có công việc đáng kể trong mã gọi nó, do đó chúng không phải là thành phần.

Nhiều khung hoặc ngôn ngữ lập trình sử dụng các thuật ngữ có nghĩa là một cái gì đó cụ thể hơn nhiều, đó là lý do tại sao mọi người đang hỏi về bối cảnh. Một cái gì đó có thể là một thành phần theo nghĩa chung, nhưng nếu nó không thực hiện một IComponentgiao diện rất cụ thể , nó có thể không được coi là một thành phần trong ngữ cảnh. Trong python, modulecó ý nghĩa kỹ thuật rất cụ thể của một cái gì đó bạn có thể nhận được bằng cách sử dụng một importlệnh. Thông thường mọi người đang đề cập đến những ý nghĩa cụ thể theo ngữ cảnh.

Nếu chúng ta trừu tượng hóa từ các ngôn ngữ, khung cụ thể và các diễn giải riêng của chúng, thì hệ thống phân cấp độ chi tiết của phần mềm trừu tượng là như sau:

Product - application, library, service
  Module - GUI, core logic, data, etc...
    Component - purpose specific collection of objects
      Object - collection of primitives
        Primitive - numbers, functions, etc...

• Sản phẩm

Đơn giản và đơn giản, Sản phẩm là tập hợp các mô đun chức năng được kết nối.

• Mô-đun

Đúng như tên gọi, động lực của Module là tính mô đun. Trái với những gì nhiều người tuyên bố, nó không thực sự ngụ ý sử dụng lại mã. Có nhiều mô-đun không thực sự có thể tái sử dụng và không phù hợp với bất kỳ mô-đun nào chúng không được thiết kế.

Điều quan trọng là phải tách các lớp phần mềm khác nhau, giúp phần mềm dễ thực hiện và bảo trì hơn, và nếu cần phải thực hiện lại một cái gì đó như mặt trước cho khung GUI khác, mô đun cho phép điều đó xảy ra một cách dễ dàng và an toàn, không bị phá vỡ mã khắp nơi.

Một mô-đun đóng gói một tập hợp các thành phần mà tất cả phục vụ một mục đích chung như được xác định bởi các yêu cầu mô-đun. Một mô-đun nên khép kín và hoàn chỉnh, và mặc dù không thực sự có thể sử dụng được, nhưng nó có thể hoạt động cùng với bất kỳ triển khai tuân thủ nào.

• Thành phần

Về độ chi tiết, Thành phần nằm giữa Mô-đun và Đối tượng. Mục đích của một thành phần là tập hợp một tập hợp các đối tượng có mục đích chung để tạo thành một đơn vị mục đích cụ thể.

Như tên của nó, không giống như Mô-đun, Thành phần không "khép kín", nó là một phần của tổng thể chức năng lớn hơn.

• Vật

Đối tượng là các khối xây dựng nhỏ hơn của các thành phần. Các đối tượng là các bộ sưu tập của người nguyên thủy và ghép chúng lại với nhau để phục vụ mức độ thấp hơn, phổ quát hơn trong khi vẫn có mục đích cụ thể.

• Nguyên thủy

Nguyên thủy là mức độ chi tiết phát triển phần mềm nhỏ nhất, đơn giản nhất và thấp nhất. Về cơ bản, nó chỉ là số nguyên và số thực và hàm / toán tử, mặc dù hầu hết các ngôn ngữ đều có thêm "công dân hạng nhất".

Có rất ít bạn có thể làm với người nguyên thủy, và đồng thời, nó ở mức độ thấp đến mức bạn có thể thực hiện mọi thứ thực tế với nó. Nó chỉ là rất, rất dài dòng, cực kỳ phức tạp và vô cùng tẻ nhạt để hoàn thành trong khi trực tiếp làm việc với người nguyên thủy.

• Điểm của tất cả những điều này là gì?

Như đã đề cập ở trên, làm việc trực tiếp với người nguyên thủy là một ý tưởng cực kỳ tồi tệ. Không chỉ bởi vì nó vô cùng phức tạp, chậm chạp và tẻ nhạt để phát triển phần mềm hiện đại, mà nó còn cực kỳ gây khó chịu và cản trở cho việc kiểm tra và bảo trì.

Có tất cả các phần khái niệm được kết hợp vào phát triển phần mềm làm cho nó dễ dàng hơn, nhanh hơn, đơn giản hơn và an toàn hơn. Bạn không tạo ra một ngôi nhà từ các nguyên tử, bất kể các nguyên tử linh hoạt và phổ quát như thế nào. Đó sẽ là một bài tập trong vô ích. Nguyên tử của bạn là nguyên thủy của bạn, đất sét là đối tượng của bạn, gạch là thành phần của bạn, tường, sàn và mái nhà là các mô-đun của bạn, được lắp ráp với nhau, chúng biểu hiện sản phẩm cuối cùng.

Con người không thực sự phát minh ra bất cứ điều gì, chúng ta chỉ khám phá những thứ đã có trong vũ trụ, sau đó sao chép và áp dụng chúng vào cuộc sống của chúng ta. Hệ thống phân cấp độ hạt giống nhau là bản chất đối với vũ trụ, từ các nguyên tử và thậm chí bên dưới, đến các phân tử hữu cơ, protein, mô, cơ quan, sinh vật và ở trên, thực tế tuân theo cùng một nguyên tắc - kết hợp những thứ nhỏ bé, đơn giản, hạn chế và có mục đích lớn hơn, phức tạp hơn, nhiều chức năng hơn và những điều cụ thể hơn mục đích.

• Thuật ngữ hãy cẩn thận

Về mặt kỹ thuật, tất cả chúng đều là "đối tượng", chúng đều là "thành phần" của phát triển phần mềm, chúng đều là "mô-đun" đủ để có thể khớp với nhau, chúng đều là "sản phẩm" theo nghĩa chúng được sản xuất, v.v. ..

Đây không phải là về thuật ngữ hoặc danh pháp, mà là về cách nhân rộng mọi thứ lên và xuống ảnh hưởng đến các khía cạnh khác nhau của sự sáng tạo và năng suất. Và về tầm quan trọng của việc không chỉ sử dụng tất cả các cấp độ khác nhau mà còn về tầm quan trọng của việc không cố gắng hoàn thành mục tiêu ở cấp độ sai, điều này chỉ có thể phản tác dụng.

Nó phụ thuộc vào bối cảnh của bạn. Mô-đun đã được sử dụng để chỉ các nhóm cấp DLL trong một số ngôn ngữ, gần giống với 'gói' hoặc 'lắp ráp' trong các ngôn ngữ khác. Thành phần được sử dụng cho những thứ COM cũng như những thứ Thành phần dựa trên thực thể phổ biến trong phát triển trò chơi.

Trong các thuật ngữ kiến ​​trúc chung, mô-đun và thành phần đều có xu hướng đề cập đến một số gói mã đằng sau một giao diện được xác định rõ. Nói chung, mô-đun có xu hướng đề cập đến các gói lớn hơn. Thường có một bộ giao diện và mô-đun có xu hướng có thể tự đứng.

Mặt khác, các thành phần có xu hướng là các gói mã nhỏ hơn, thường nhỏ hơn một lớp đầy đủ. Theo tên của họ, họ có xu hướng là một thành phần của một cái gì đó lớn hơn. Đôi khi, đó chính là ứng dụng, nhưng với việc sử dụng bố cục ngày càng tăng trong thiết kế lớp, nó thường có nghĩa là một thành phần của một đối tượng lớn hơn. Các giao diện được xác định rõ cho các thành phần cũng có xu hướng cho phép ứng dụng hoán đổi các thành phần cho nhau. Các mô-đun có xu hướng không có khả năng trao đổi.