Optional component functionality vs SRP

Question

I have a design issue that I encounter currently.

Let's say there is a hierarchy of components. Each of these component derives from an abstract Component type which looks something like this:

public abstract class Component
{
    public abstract Component Parent { get; }
    public abstract ComponentCollection Children { get; }
}

Now I want to add some optional functionality to those components, lets take being able to search within the component hierarchy and to select components within the hierarchy as examples.

Is it considered bad practice to provide those optional functionality in the base class like this:

public abstract class Component
{
    // Other members

    public abstract bool IsSearchable { get; }
    public abstract bool Search(string searchTerm);

    public abstract bool IsSelectable { get; }
    public abstract bool Select();
}

While the "search-ability" and "select-ability" is managed in derived components by e.g. using strategy patterns?

Somehow this seems like violation of the SRP to me, but in my opinion the only alternative would be to have an interface for each optional functionality and only implement it on components that support this functionality.

In my opinion this would have the drawback that I have to write code like this everytime I want to check if a component provides specific functionality:

public bool Search(Component component, string searchTerm)
{
    ISearchable searchable = component as ISearchable;
    if(searchable != null)
    {
        searchable.Search(searchTerm);
    }
}

Which strategy would you choose or do you have any better ideas?

Thanks in advance!

Answer 1

A possible option:

If the searchability/selectability implementation is provided through the strategy pattern (dependency injection), as you say, then I think interfaces for ISearchable and ISelectable are a better idea.

You can derive your strategy object from these interfaces, and implement getters for them in your base-Component class - GetSearchable(), GetSelectable() - where the default implementation in Component returns null (or a no-op implementation of the interface if you dislike null).

Answer 2

Why don't you use decorator?

Component c = new Component ();
var selectableAndSearchableOne = new SelectableComponent (new SearchableComponent (c));

Answer 3

Ok another one: this time you also know the component's extension points. with a visitor-like pattern

public interface IHasExtensions
    {
        List<Extension> Extensions { get; }
        void Extend (Extension ext);
    }

    public class Component : IHasExtensions
    {
        List<Extension> exts = new List<Extension> ();

        public List<Extension> Extensions
        {
            get { return exts; }
        }

        public void Extend (Extension ext)
        {
            exts.Add (ext);
        }

        void Draw() { }
    }

    public abstract class Extension
    {
        readonly protected Component _Component;

        public Extension(Component component)
        {
            _Component = component;
        }
    }

    public class SearchExtension : Extension
    {
        public SearchExtension (Component component) : base (component)
        {

        }
    }

    public class SelectionExtension : Extension
    {
        public SelectionExtension (Component component) : base (component)
        {

        }
    }

    public class test_fly
    {
        void start ()
        {
            Component c = new Component ();
            c.Extend (new SearchExtension (c));
            c.Extend (new SelectionExtension (c));

            var exts = c.Extensions; // I Know the extensions now
        }
    }