Có phải thực tế xấu khi chỉ sử dụng một giao diện để phân loại?

Ví dụ:

Nói rằng tôi có các lớp học A, B, C. Tôi có hai giao diện, hãy gọi chúng IAnimalvà IDog. IDogkế thừa từ IAnimal. Avà Blà IDogs, trong khi Ckhông, nhưng nó là một IAnimal.

Phần quan trọng là IDogcung cấp không có chức năng bổ sung. Nó chỉ được sử dụng để cho phép Avà B, nhưng không C, được truyền dưới dạng đối số cho các phương thức nhất định.

Đây có phải là thực hành xấu?

Giao diện không có bất kỳ thành viên nào hoặc có chính xác các thành viên với giao diện khác được kế thừa từ cùng một giao diện có tên là Giao diện đánh dấu và bạn đang sử dụng nó làm điểm đánh dấu.

Nó không phải là thực tiễn xấu nhưng giao diện có thể được thay thế bằng các thuộc tính (chú thích) nếu ngôn ngữ mà bạn đang sử dụng hỗ trợ nó.

Tôi có thể tự tin nói rằng đó không phải là thực tiễn tồi vì tôi đã thấy mô hình "Giao diện đánh dấu" sử dụng nhiều trong Dự án Orchard

Dưới đây là mẫu từ dự án Orchard.

public interface ISingletonDependency : IDependency {}

/// <summary>
/// Base interface for services that may *only* be instantiated in a unit of work.
/// This interface is used to guarantee they are not accidentally referenced by a singleton dependency.
/// </summary>
public interface IUnitOfWorkDependency : IDependency {}

/// <summary>
/// Base interface for services that are instantiated per usage.
/// </summary>
public interface ITransientDependency : IDependency {}

Vui lòng tham khảo Giao diện đánh dấu .

Vâng, đó là một thực hành xấu trong hầu hết các ngôn ngữ.

Các loại không có để mã hóa dữ liệu; chúng là một trợ giúp để chứng minh rằng dữ liệu của bạn đi đến nơi cần đến và hành xử như nó cần phải hành xử. Lý do duy nhất để loại phụ là nếu một hành vi đa hình thay đổi (và không phải lúc nào cũng vậy).

Vì không có gõ, IDog có thể làm gì được ngụ ý. Một lập trình viên nghĩ một điều, một điều khác nghĩ khác và mọi thứ đổ vỡ. Hoặc những thứ nó thể hiện tăng lên khi bạn cần kiểm soát chi tiết hơn.

[sửa: làm rõ]

Ý tôi là bạn đang thực hiện một số logic dựa trên giao diện. Tại sao một số phương pháp chỉ có thể làm việc với chó và những người khác bất kỳ động vật? Sự khác biệt đó là một hợp đồng ngụ ý vì không có thành viên thực sự cung cấp sự khác biệt; không có dữ liệu thực tế trong hệ thống. Sự khác biệt duy nhất là giao diện (do đó bình luận 'không gõ') và điều đó có nghĩa là gì sẽ khác nhau giữa các lập trình viên. [/biên tập]

Một số ngôn ngữ cung cấp các cơ chế đặc điểm trong đó điều này không quá tệ nhưng những ngôn ngữ này có xu hướng tập trung vào các khả năng, không phải là sàng lọc. Tôi có ít kinh nghiệm với họ vì vậy không thể nói với các thực tiễn tốt nhất ở đó. Trong C ++ / Java / C # mặc dù ... không tốt.

Tôi chỉ biết rõ về C #, vì vậy tôi không thể nói điều này cho lập trình OO nói chung, nhưng như một ví dụ về C #, nếu bạn cần phân loại các lớp, các tùy chọn rõ ràng là giao diện, thuộc tính enum hoặc thuộc tính tùy chỉnh. Thông thường tôi sẽ chọn giao diện bất kể người khác nghĩ gì.

if(animal is IDog)
{
}
if(animal.Type == AnimalType.Dog)
{
}
if(animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
{
}


var dogs1 = animals.OfType<IDog>();
var dogs2 = animals.Where(a => a.Type == AnimalType.Dog);
var dogs3 = animals.Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any());


var dogsFromDb1 = session.Query<IDog>();
var dogsFromDb2 = session.Query<Animal>().Where(a => a.Type == AnimalType.Dog);
var dogsFromDb3 = session.Query<Animal>().Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute),false).Any());


public void DoSomething(IDog dog)
{
}
public void DoSomething(Animal animal)
{
    if(animal.Type != AnimalType.Dog)
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}
public void DoSomething(Animal animal)
{
    if(!animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}

Không có gì sai khi có một giao diện kế thừa giao diện khác mà không cần thêm thành viên mới, nếu tất cả các triển khai của giao diện sau sẽ có thể thực hiện một cách hữu ích những điều mà một số triển khai trước đây không thể thực hiện được. Thật vậy, đó là một mẫu tốt mà IMHO nên được sử dụng nhiều hơn trong những thứ như .net Framework, đặc biệt là khi người triển khai có lớp sẽ tự nhiên thỏa mãn các ràng buộc được ngụ ý bởi giao diện có nguồn gốc nhiều hơn có thể chỉ ra rằng chỉ bằng cách thực hiện giao diện có nguồn gốc nhiều hơn , mà không phải thay đổi bất kỳ mã khai báo thành viên hoặc khai báo nào.

Ví dụ: giả sử tôi có các giao diện:

giao diện IMaybeMutableFoo {
  Bar Thing {get; set;} // Và các thuộc tính khác nữa
  bool IsMutable;
  IImmutableFoo AsImmutable ();
}
giao diện IImmutableFoo: IMaybeMutableFoo {};

Một triển khai IImmutableFoo.AsImmutable()sẽ được dự kiến ​​sẽ trở lại chính nó; một lớp triển khai có thể thay đổi IMaybeMutableFoo.AsImmutable()sẽ được mong đợi sẽ trả về một đối tượng mới không thay đổi sâu có chứa ảnh chụp nhanh của dữ liệu. Một thói quen muốn lưu trữ một ảnh chụp nhanh của dữ liệu được giữ trong một IMaybeMutableFoocó thể cung cấp quá tải:

khoảng trống công khai StoreData (IImmutableFoo ThingToStore)
{
  // Lưu trữ tài liệu tham khảo sẽ đủ, vì ThingToStore được biết là không thay đổi
}
khoảng trống công khai StoreData (IMaybeMutableFoo ThingToStore)
{
  StoreData (ThingToStore.AsImmutable ()); // Gọi quá tải cụ thể hơn
}

Trong trường hợp trình biên dịch không biết rằng thứ được lưu trữ là một IImmutableFoo, nó sẽ gọi AsImmutable(). Hàm sẽ trả về nhanh nếu mục đã không thay đổi, nhưng một lệnh gọi qua giao diện vẫn mất thời gian. Nếu trình biên dịch biết rằng mục đó đã là một IImmutableFoo, nó có thể bỏ qua lệnh gọi hàm không cần thiết.