Add more behaviour without creating new classes

Question

This was the question asked in an interview.

There is a Label with a property Text
In one page a label is simple Label, in other pages it may handle any one or combination of the below actions
Clickable
Resizable
Draggable

How do you design this label component that applies OOP design Principle & Design Pattern?

I said that I would create the following:

public class Label
{
  public string Text{get;set;}
}
public interface IClickable
{
 void Click();
}

public interface IDraggable
{
 void Drag();
}
public interface IResizable
{
 void Resize();
}

So that if the client want Resizable Label

public class ResizableLabel:Label,IResizable
{
  ....
}

same way ClickableLable, DraggableLabel

However, I feel that this is the incorrect approach, because I do not want to add those concrete classes. I want to avoid having ClickableAndDraggableLabel or ClickableDraggableResizableLabel.

Is there any design pattern that would solve this problem without adding these concrete classes?

Answer 1

I would use Decorator pattern. It is used extensivelly in .net world for different kind of streams, that allow you to compose encrypted, zipped, text stream wrappers for byte stream, for example. class diagram is taken from wiki

Example for you situation is not so trivial in implementation, but usage doen't require another classes for new compising behavior:

// Define other methods and classes here
public class Label
{
    public string Text{get;set;}

    public virtual void MouseOver(object sender, EventArgs args) { /*some logic*/ }
    public virtual void Click(object sender, EventArgs args) {  /*some logic*/ }

    //other low level events
}

public class ClikableLabel : Label
{
    private Label _label;

    public ClikableLabel(Label label)
    {
        _label = label; 
    }

    public override void Click(object sender, EventArgs args) 
    {   
        //specific logic
        _label.Click(sender, args);
    }
}

public class DraggableLabel : Label
{
    private Label _label;

    public DraggableLabel(Label label)
    {
        _label = label; 
    }

    public override void Click(object sender, EventArgs args) 
    {   
        //specific logic
        _label.Click(sender, args);
    }
}
public class ResizableLabel : Label
{
    private Label _label;

    public ResizableLabel(Label label)
    {
        _label = label; 
    }

    public override void MouseOver(object sender, EventArgs args) 
    {   
        //specific logic
        _label.MouseOver(sender, args);
    }

    public override  void Click(object sender, EventArgs args) 
    {
        //specific logic
        _label.Click(sender, args);
    }
}

now you can

var clickableDragableLabel = new ClikableLabel(new DraggableLabel(new Label{Text = "write me!"}));

var makeItResizable = new ResizableLabel(clickableDragableLabel);

Answer 2

I would just have boolean properties for CanClick, drag, and resize, all default to true, and falsed as required (or as inherited).

constructor as follows

public Label(bool canClick = true, bool canDrag = true, bool canResize = true){}

Chances are if they're extending a class once, its going to be extended further at a later date

Answer 3

I don't think Interface can resolve your problem.
I would make something more like this:

First, define an enum which list all your action:

public Enum LabelAction{ None = 0, Clickable = 1, Resizable = 2, Draggable = 4 }

For having multiple Enum defined, you can look this links:

• How do you pass multiple enum values in C#?
• Enumeration Types as Bit Flags

Then define a member in your class Label, taking an action:

public class Label
{
    private readonly LabelAction _action;
    private string Text { get; set; }

    public class Label(string text)
        : Label(text, LabelAction.None) { } 

    public class Label(string text, LabelAction action)
    {
        this.Text = text;
        this._action = action; 
    }

    public bool CanClick 
    { 
        get
        {
            return this._action & LabelAction.Clickable == LabelAction.Clickable;
        }
    }

    public bool CanResize { get { return this._action & LabelAction.Resizable == LabelAction.Resizable ;} }
    public bool CanDrag { get { return this._action & LabelAction.Draggable == LabelAction.Draggable ;} }

    public Click()
    {
       if(this.CanClick) { /* click */ }
       else { throw new Exception("Not clickable");}
    }
    public Drag()
    {
       if(this.CanDrag) { /* drag */ }
       else { throw new Exception("Not draggable");}
    }
    public Resize()
    {
       if(this.CanResize) { /* resize */}
       else { throw new Exception("Not resizable");}
    }
}

Usage:

var simpleLabel = new Label("simple");
var clickable = new Label("clickable", LabelAction.Clickable);
var clickableDraggable = new Label("clickable and draggable", LabelAction.Clickable | LabelAction.Draggable);

public void DoEvent(Label label)
{
    if(label.CanClick) label.Click();
    if(label.CanDrag) label.Drag();
    if(label.CanResize) label.Resize();
}

If you need to add an action, you will have to add one item to the Enum LabelAction, one method CanDo() and one method Do() to the Label class. Not so much so.

Answer 4

Well you can have a base class that implement all the interface and delegate their behaviour to concretes strategy classes. Then you would have a NullDraggable, nulResizeable,NullClickable by default that do nothing (so your base label is not clickable, resizable and dragrable) Then you create different strategy, like Clickable, DoubleClickable, WidthResizeable etc... You then pass the combination you want to your class. This way you obtain a lot of little strategy that are easy to reuse in other component with the same interface. You can have multiple behaviour by using a composite pattern (for example you can have clickable and doubleclickable togheter)

This probably would be a little too ingeneered though

Answer 5

I think you're over-thinking what the interviewer must have had in his mind. If the case is as simple and practical, to avoid the complexity of over abstraction, then this would suffice:

public class Label
{
    public string Text{get;set;}
}

public class ComlexLabel : Label
{
    Click();
    Drag();
    Resize();
}

You can do any operation on it. Now if for a challenge you need only one concrete instance and need separate type of objects to be able to do only a combination of these things, its again simple - only that this time you have to create similar prototypes/interfaces:

public class Label
{
    public string Text{get;set;}
}

public interface Clickable
{
    Click();
}

public interface Resizable
{
    Resize();
}

public interface Dragable
{
    Drag();
}

public interface ClickableDragable : Clickable, Draggable
{

}

public interface ClickableResizable : Clickable, Resizable
{

}

public interface ResizableDragable : Resizable, Draggable
{

}

public interface ClickableDragableResizeable : Resizable, Clickable, Draggable
{

}

public class ComlexLabel : Lable, ClickableDragableResizeable
{
    Click();
    Drag();
    Resize();
}

Now you can have instances of ComlexLabel by making the type that gives the required feature. Like:

ResizableDragable rd = new ComlexLabel();
ClickableResizable cr = new ComlexLabel();
ClickableDragableResizeable cdr = new ComlexLabel();

Now rd, cr and cdr have different capabilities. And only one concrete instance behind them. To prevent the clients from getting full privilege by doing

var cdr = new ComplexLabel();

you should make the ComplexLabel constructor private and assign the task to some factory. Like

var rd = Factory.GetResizableDragableLabel();

Now rd must be just ResizableDragable with no Click functionality..

Answer 6

I think for this scenario, there is no need to re-invent the wheel. Even though the question explicitly asks for OOP it is not explicitly asking you to ignore Component Model programming nor event based behaviors. That's why I would follow an approach that allows a division of responsibilities where Label is responsible to notify when it is being clicked or dragged and SomeOtherComponent might or might not listen to such notification (event) in order to perform other logic.

Please take a look at the links below for examples of the approach of event dispatching for those user actions :

Drag and Drop

Label Class

Regards,