5 added 71 characters in body
source | link

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object validation)
    {
        if (validation == null)
        {
            throw new ArgumentNullException("validation", string.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex regex)
    {
        Require("regex", regex);
        RegexValidation = regex;
    }

    public StringValidator(string wildcard)
    {
        Require("wildcard", wildcard);
        WildcardValidation = wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors should guarantee there is exactly one validation strategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

I think you can get away with this only because, fundamentally, that sort of StringValidator public interface/contract with clients, is coincidentally, rather minimal:minimal;

In essence, that's simply,

bool IsValid(string input)

SurelyBut surely, though, I would not use this implementation approach I just sketched for things that get more involved than that after construction time, and/or for a richer public interfacesinterface (be it with or without mutable state).

'Hope this helps.

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object validation)
    {
        if (validation == null)
        {
            throw new ArgumentNullException("validation", string.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex regex)
    {
        Require("regex", regex);
        RegexValidation = regex;
    }

    public StringValidator(string wildcard)
    {
        Require("wildcard", wildcard);
        WildcardValidation = wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors should guarantee there is exactly one validation strategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

I think you can get away with this only because, fundamentally, that sort of StringValidator public interface/contract with clients, is coincidentally, rather minimal:

bool IsValid(string input)

Surely, though, I would not use this approach for things that get more involved than that after construction time and/or for richer public interfaces.

'Hope this helps.

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object validation)
    {
        if (validation == null)
        {
            throw new ArgumentNullException("validation", string.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex regex)
    {
        Require("regex", regex);
        RegexValidation = regex;
    }

    public StringValidator(string wildcard)
    {
        Require("wildcard", wildcard);
        WildcardValidation = wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors should guarantee there is exactly one validation strategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

I think you can get away with this only because, fundamentally, that sort of StringValidator public interface/contract with clients, is coincidentally, rather minimal;

In essence, that's simply,

bool IsValid(string input)

But surely, though, I would not use this implementation approach I just sketched for things that get more involved than that after construction time, and/or for a richer public interface (be it with or without mutable state).

'Hope this helps.

4 added 349 characters in body
source | link

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object validation)
    {
        if (validation == null)
        {
            throw new ArgumentNullException("validation", string.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex regex)
    {
        Require("regex", regex);
        RegexValidation = regex;
    }

    public StringValidator(string wildcard)
    {
        Require("wildcard", wildcard);
        WildcardValidation = wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors should guarantee there is exactly one validation strategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

I think you can get away with this only because, fundamentally, that sort of StringValidator public interface/contract with clients, is coincidentally, rather minimal:

bool IsValid(string input)

Surely, though, I would not use this approach for things that get more involved than that after construction time and/or for richer public interfaces.

'Hope this helps.

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object validation)
    {
        if (validation == null)
        {
            throw new ArgumentNullException("validation", string.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex regex)
    {
        Require("regex", regex);
        RegexValidation = regex;
    }

    public StringValidator(string wildcard)
    {
        Require("wildcard", wildcard);
        WildcardValidation = wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors should guarantee there is exactly one validation strategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

'Hope this helps.

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object validation)
    {
        if (validation == null)
        {
            throw new ArgumentNullException("validation", string.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex regex)
    {
        Require("regex", regex);
        RegexValidation = regex;
    }

    public StringValidator(string wildcard)
    {
        Require("wildcard", wildcard);
        WildcardValidation = wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors should guarantee there is exactly one validation strategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

I think you can get away with this only because, fundamentally, that sort of StringValidator public interface/contract with clients, is coincidentally, rather minimal:

bool IsValid(string input)

Surely, though, I would not use this approach for things that get more involved than that after construction time and/or for richer public interfaces.

'Hope this helps.

3 added 104 characters in body
source | link

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object patternvalidation)
    {
        if (patternvalidation == null)
        {
            throw new ArgumentNullException("pattern""validation", "cannotstring.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex patternregex)
    {
        Require(pattern"regex", regex);
        RegexValidation = pattern;regex;
    }

    public StringValidator(string patternwildcard)
    {
        Require(pattern"wildcard", wildcard);
        WildcardValidation = pattern;wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors willshould guarantee there is exactly one validation implementationstrategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

'Hope this helps.

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(object pattern)
    {
        if (pattern == null)
        {
            throw new ArgumentNullException("pattern", "cannot be null");
        }
    }

    public StringValidator(Regex pattern)
    {
        Require(pattern);
        RegexValidation = pattern;
    }

    public StringValidator(string pattern)
    {
        Require(pattern);
        WildcardValidation = pattern;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors will guarantee there is exactly one validation implementation
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

'Hope this helps.

I don't see a problem with that.

Can it not be seen as a mere implementation detail?

You can have your StringValidator constructor overloads dispatch their argument to various protected properties:

public class StringValidator
{
    protected void Require(string strategy, object validation)
    {
        if (validation == null)
        {
            throw new ArgumentNullException("validation", string.Concat(strategy, " cannot be null");
        }
    }

    public StringValidator(Regex regex)
    {
        Require("regex", regex);
        RegexValidation = regex;
    }

    public StringValidator(string wildcard)
    {
        Require("wildcard", wildcard);
        WildcardValidation = wildcard;
    }

    // Derived validators, if any, will just override this, by:
    // if (NewValidation != null) {
    // ...
    // }
    // else
    //     return base.Validate(input);
    protected virtual bool Validate(string input)
    {
        if (WildcardValidation != null)
        { // Wildcard matching strategy
          // return ...
        }
        else
        { // Regex matching strategy
          // return ...
        }
        // Proper constructors should guarantee there is exactly one validation strategy ready
    }

    public bool IsValid(string input)
    {
        return Validate(input);
    }

    protected string WildcardValidation { get; private set; }

    protected Regex RegexValidation { get; private set; }

    // Etc
}

'Hope this helps.

2 added 104 characters in body
source | link
1
source | link