Các lớp so với các mô-đun trong VB.NET

Được coi là một cách thực hành có thể chấp nhận để sử dụng Mô-đun thay vì Lớp có chức năng thành viên được chia sẻ trong VB.NET?

Tôi có xu hướng tránh các Mô-đun, vì chúng cảm thấy như phần còn lại từ Visual Basic 6.0 và dường như không thực sự phù hợp nữa. Mặt khác, dường như không có nhiều khác biệt giữa việc sử dụng Mô-đun và Lớp chỉ có các thành viên được chia sẻ. Không phải lúc nào tôi cũng thực sự cần nhiều thứ, nhưng đôi khi có những tình huống họ đưa ra một giải pháp đơn giản.

Tôi tò mò muốn biết liệu bạn có ý kiến ​​hay sở thích nào theo cách này hay cách khác.

Modules là đối tác VB với staticcác lớp C # . Khi lớp của bạn được thiết kế chỉ dành cho các hàm trợ giúp và phương thức mở rộng và bạn không muốn cho phép kế thừa và khởi tạo , bạn sử dụng một Module.

Nhân tiện, sử dụng Modulekhông thực sự chủ quan và nó không bị phản đối . Thật vậy, bạn phải sử dụng Modulekhi nó thích hợp. .NET Framework tự thực hiện nhiều lần ( System.Linq.Enumerableví dụ). Để khai báo một phương thức mở rộng, bắt buộc phải sử dụng Modules.

Tôi nghĩ rằng đó là một ý tưởng tốt để tiếp tục tránh các mô-đun trừ khi bạn dán chúng vào các không gian tên riêng biệt. Bởi vì trong các phương thức Intellisense trong các mô-đun sẽ hiển thị từ mọi nơi trong không gian tên đó.

Vì vậy, thay vì ModuleName.MyMethod()bạn kết thúc với MyMethod()cửa sổ bật lên ở bất cứ đâu và loại này làm mất hiệu lực đóng gói. (ít nhất là ở cấp độ lập trình).

Đó là lý do tại sao tôi luôn cố gắng tạo Class bằng các phương thức được chia sẻ, có vẻ tốt hơn nhiều.

Các mô-đun không có nghĩa là không được chấp nhận và được sử dụng nhiều trong ngôn ngữ VB. Chẳng hạn, đó là cách duy nhất để thực hiện một phương thức mở rộng trong VB.Net.

Có một sự khác biệt lớn giữa Mô-đun và Lớp với Thành viên tĩnh. Bất kỳ phương thức nào được xác định trên Mô-đun đều có thể truy cập toàn cầu miễn là Mô-đun có sẵn trong không gian tên hiện tại. Trong thực tế, một Module cho phép bạn xác định các phương thức toàn cầu. Đây là điều mà một lớp chỉ có các thành viên được chia sẻ không thể làm được.

Đây là một ví dụ nhanh mà tôi sử dụng rất nhiều khi viết mã VB xen kẽ với các giao diện COM thô.

Module Interop
  Public Function Succeeded(ByVal hr as Integer) As Boolean
    ...
  End Function

  Public Function Failed(ByVal hr As Integer) As Boolean
    ...
  End Function
End Module

Class SomeClass
  Sub Foo()
    Dim hr = CallSomeHrMethod()
    if Succeeded(hr) then
      ..
    End If
  End Sub
End Class

Nó được chấp nhận để sử dụng Module. Modulekhông được sử dụng để thay thế cho Class. Modulephục vụ mục đích riêng của nó. Mục đích của Moduleviệc sử dụng như một container cho

• phương pháp mở rộng,
• các biến không đặc trưng cho bất kỳ Class, hoặc
• các biến không phù hợp đúng trong bất kỳ Class.

Modulekhông giống như Classvì bạn không thể

• kế thừa từ một Module,
• thực hiện một Interfacevới một Module,
• cũng không tạo một thể hiện của a Module.

Bất cứ điều gì trong một Modulecó thể được truy cập trực tiếp trong Modulehội đồng mà không đề cập đến Moduletên của nó. Theo mặc định, mức truy cập cho một Modulelà Friend.

Các lớp học

• các lớp có thể được khởi tạo như các đối tượng
• Dữ liệu đối tượng tồn tại riêng cho từng đối tượng khởi tạo.
• các lớp có thể thực hiện các giao diện .
• Các thành viên được định nghĩa trong một lớp được đặt trong một thể hiện cụ thể của lớp và chỉ tồn tại cho đời của đối tượng .
• Để truy cập các thành viên lớp từ bên ngoài một lớp, bạn phải sử dụng các tên đủ điều kiện theo định dạng của Object.Member .

Mô-đun

• Mô-đun không thể được khởi tạo dưới dạng đối tượng , vì chỉ có một bản sao dữ liệu của mô-đun chuẩn, khi một phần trong chương trình của bạn thay đổi biến công khai trong mô-đun chuẩn, nó sẽ hiển thị cho toàn bộ chương trình.
• Các thành viên được khai báo trong một mô-đun là thể truy cập công khai theo mặc định.
• Nó có thể được truy cập bởi bất kỳ mã nào có thể truy cập mô-đun.
• Điều này có nghĩa là các biến trong một mô-đun chuẩn là các biến toàn cầu hiệu quả vì chúng có thể nhìn thấy từ bất kỳ đâu trong dự án của bạn và chúng tồn tại trong vòng đời của chương trình.

Khi một trong các lớp VB.NET của tôi có tất cả các thành viên được chia sẻ, tôi sẽ chuyển đổi nó thành Mô-đun với không gian tên phù hợp (hoặc phù hợp khác) hoặc tôi làm cho lớp không thể kế thừa và không thể xây dựng:

Public NotInheritable Class MyClass1

   Private Sub New()
      'Contains only shared members.
      'Private constructor means the class cannot be instantiated.
   End Sub

End Class

Các mô-đun là tốt để lưu trữ enums và một số biến toàn cục, hằng và hàm chia sẻ. nó rất tốt và tôi thường sử dụng nó Các biến được khai báo có thể nhìn thấy toàn bộ dự án.

Bạn phải sử dụng Mô-đun (chứ không phải Lớp) nếu bạn đang tạo phương thức Tiện ích mở rộng. Trong VB.NET tôi không biết đến một lựa chọn khác.

Tự mình chống lại các Mô-đun, tôi chỉ mất vài giờ vô ích để cố gắng tìm cách thêm một số mã soạn sẵn để giải quyết các hội đồng nhúng trong một, chỉ để tìm ra rằng Sub New()(Mô-đun) và Shared Sub New()(Lớp) là tương đương. (Tôi thậm chí không biết có là một callableSub New() trong một Module!)

Vì vậy, tôi chỉ cần ném EmbeddedAssembly.Loadvà AddHandler AppDomain.CurrentDomain.AssemblyResolvedòng trong đó và Bob đã trở thành chú của tôi.

Phụ lục : Tôi chưa kiểm tra 100% nhưng tôi có một loại mực Sub New()chạy theo thứ tự khác trong Mô-đun so với Lớp, chỉ cần thực tế là tôi phải chuyển một số khai báo sang bên trong từ bên ngoài để tránh lỗi.