不使用扩展方法而使用通用逻辑扩展C＃接口

Question

Is there a way to extend an interface without using Extension Methods?

If I define some interface with a couple of get/set strings for example :

public interface IMyItem
{
    string Title { get; set; }
    string Description { get; set; }
}

I'd like add some simple validation to these interfaces, but without having to re-define the logic or force some form of inheritance.

Currently I'm using Extension Methods, like this :

public static class MyItemExtensions
{
    public static bool ERROR(this IMyItem item)
    {
        return item.TITLE_ERROR() || item.DESCRIPTION_ERROR();
    }

    public static bool TITLE_ERROR(this IMyItem item)
    {
        return string.IsNullOrEmpty(item.Title);
    }

    public static bool DESCRIPTION_ERROR(this IMyItem item)
    {
        return string.IsNullOrEmpty(item.Description);
    }
}

Doing this works and I can have:

public class Item : IMyItem
{
   public string Title { get; set; }
   public string Description { get; set; }
}

public static class app
{
    public static void go()
    {
        var item = new Item
        {
            Title = "My Item Title", 
            Description = ""
        };

        Console.log(item.ERROR());
    }
}

But I'd prefer ERROR , TITLE_ERROR & DESCRIPTION_ERROR to be get/sets - Is there a way to achieve the same but expose Get/Set properties rather than Extension Methods?

Update 11/06/2014

As many have suggested, an abstract class would be an obvious solution based on the example, but the types need to implement multiple interfaces.

While it may be possible to arrange the inheritance it's an unnecessary complication and restriction on the types.

The added benefit of using Extension Methods for validation on these interfaces allows for context specific & shared logic to be used, via namespacing.

Multiple ERROR(this IMyItem item) Extension Methods could be defined for the interface, on different namespaces. One that checks Both the TITLE_ERROR and DESCRIPTION_ERROR and another might only test one of the properties. Then, depending on the context, the relevant namespace can be referenced and the shared validation for that item be executed.

I'll look at Microsoft's validator, but it looks rather verbose and I really wanted these states as properties for type, as it makes the code that uses them much easier to use.

Additionally, these are very simple examples, some of the validation much more complex and some cases require interaction with other web services - albeit against a cache of web service data within the AppDomain.

Currently these interface Extension Methods feel like the best solution.

Answer 1

I think a proper solution would be to use an abstract class instead of an interface .

What you share here is a common validation logic which will be valid for any class implementing IMyItem . As so, i'd recommand you create an abstract class as a base for all items, that way they can all reuse that validation code. You can even make those properties virtual, so one could extend that validation code:

public abstract class ItemBase : IMyItem
{
    public string cTitle { get; set; }
    public string cDescription { get; set; }

    public virtual bool Error 
    { 
      get { return TitleError || DescriptionError; } 
    }

    public virtual bool TitleError 
    { 
      get { return string.IsNullOrEmpty(cTitle); } 
    }

    public virtual bool DescriptionError 
    { 
      get { return string.IsNullOrEmpty(cDescription); } 
    }
}

Answer 2

Seems like you're reinventing the wheel. Microsoft already created a fairly good validation framework that does not require Entity Framework or MVC. Simply add a reference to System.ComponentModel.DataAnnotations and the using System.ComponentModel.DataAnnotations to a class:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;

public class Program
{
    public static void Main()
    {
        // required if you use the MetdataType attribute
        TypeDescriptor.AddProviderTransparent(
            new AssociatedMetadataTypeTypeDescriptionProvider(typeof(MyItem),
                typeof(IMyItemValidation)),
            typeof(MyItem));


        var item = new MyItem();
        var context = new ValidationContext(item, 
          serviceProvider: null, 
          items: null);
        var results = new List<ValidationResult>();

        var isValid = Validator.TryValidateObject(item, context, results);

        if (!isValid)
        {
            foreach (var validationResult in results)
            {
                Console.WriteLine(validationResult.ErrorMessage);
            }
        }

        Console.ReadKey();
    }

    [MetadataType(typeof(IMyItemValidation))]
    public class MyItem : IMyItem
    {
        public string cTitle { get; set; }
        public string cDescription { get; set; }
    }

    public interface IMyItem
    {
        string cTitle { get; set; }
        string cDescription { get; set; }
    }

    public interface IMyItemValidation
    {
        [Required]
        string cTitle { get; set; }
        [Required]
        string cDescription { get; set; }
    }

    /* 

    // alternatively you could do either of these as well:
    // Derive MyItem : MyItemBase

    // contains the logic on the base class
    public abstract MyItemBase
        [Required]
        public string cTitle { get; set; }
        [Required]
        public string cDescription { get; set; }
    }

    // or

    // Derive MyItem : MyItemBase
    // contains the logic on the base class using MetadataType
    [MetadataType(typeof(IMyItemValidation))]
    public abstract MyItemBase
        public string cTitle { get; set; }
        public string cDescription { get; set; }
    }


}

Output

The cTitle field is required.

the cDescription field is required.