Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have an abstract class called Address and I am deriving three classes ; HomeAddress, Work Address, NextOfKin address.

My idea is to bind this to a usercontrol and based on the type of Address it should bind properly to the ASP.NET user control.

My idea is the user control doesn't know which address it is going to present and based on the type it will parse accordingly.

How can I design such a setup, based on the fact that, the user control can take any type of address and bind accordingly.

I know of one method like :- Declare class objects for all the three types (Home,Work,NextOfKin). Declare an enum to hold these types and based on the type of this enum passed to user control, instantiate the appropriate object based on setter injection.

As a part of my generic design, I just created a class structure like this :-

Sample UML

I know I am missing a lot of pieces in design. Can anybody give me an idea of how to approach this in proper way.

share|improve this question
    
Is this a question about dependency injection or data-binding in asp.net? The title doesn't seem to match the question.. –  MattDavey Feb 13 '13 at 9:35
1  
@MattDavey In simple sense it is data binding a class object to asp.net user control. This is definitely a dependency, and I am not talking about dependency injection per-se. It is definitely a dependency issue also. Anyways I will change the title, so as to make it simple. –  Rohith Nair Feb 13 '13 at 10:42
    
I think the reason you're not getting any answers yet is that the question is a little open-ended. Also it doesn't really have anything to do with design patterns or dependency injection. If I understand correctly, you want to instantiate a different user control specific for each child in the class hierarchy? This may be a question better suited to Stack Overflow. –  MattDavey Feb 15 '13 at 9:56
    
Same user control different field hide/show based on class heirarchy –  Rohith Nair Feb 15 '13 at 10:01
    
Do you just need the object's properties to appear in the control? You could use reflection to get the properties. Hard to answer without knowing specifically what your are going for. –  mike30 Feb 15 '13 at 14:52

3 Answers 3

In general, you shouldn't. The user control should bind to a concrete type.

A better approach would be to have the base address bits be their own class, and then compose 3 classes for the optional bits, each containing a base address class as a member. The user control can then defer the rendering of the address bits to some sub-control.

Or better yet, simply include the home/work phones and next of kin (and leave them blank if unused). It's not as though those elements are mutually exclusive (or should be anyways...).

share|improve this answer

Looks like a candidate for a Strategy Pattern to me. In a simplistic approach, use delegates to perform the binding based upon type.

It is just as you demonstrate in your diagram whereby the point of the strategy pattern is to encapsulate behavior, ensure class not doing more than one thing, and to use Delegate Pattern to designate a specific interface and concretes to perform a specific function.

share|improve this answer
    
Hi can you please elaborate this a bit based on my case? –  Rohith Nair Apr 18 '13 at 14:13
    
It is just as you demonstrate in your diagram whereby the point of the strategy pattern is to encapsulate behavior, ensure class not doing more than one thing, and to use Delegate Pattern to designate a specific interface and concretes to perform a specific function. –  Mushy Apr 18 '13 at 17:29

I think your best bet would be to define an abstract class that represents an address and the type of address:

public abstract class Address
{
    public abstract string Type { get; }
    public abstract IEnumerable<string> FieldLabels { get; }
    public abstract IEnumerable<string> FieldValues { get; }
};

which you might derive from like this:

public class HomeAddress : Address
{
    public string FirstLine { get; set; }
    public string ZipCode { get; set; }
    public override string Type { get { return "HomeAddress"; } }
    public override IEnumerable<string> FieldLabels
    {
        get
        {
            List<string> tmp = new List<string>();
            tmp.Add("First Line");
            tmp.Add("Zip Code");
            return tmp;
        }
    }
    public override IEnumerable<string> FieldValues
    {
        get
        {
            List<string> tmp = new List<string>();
            tmp.Add(FirstLine);
            tmp.Add(ZipCode);
            return tmp;
        }
    }
};

Any GUI element can then simply be passed an object as a base class pointer, and retrieve and display the address type and address fields.

If there are fields that always appear in all address types then they could be defined in the base class with only optional/variably present fields retrived through the IEnumerable properties.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.