# Best way to relate methods with properties [closed]

I have a class with some properties that I need to reflect over. One of the things I need, is a instance of a complex type returned for each of my properties, which means I can't just instantiate it directly in the attribute.

Now, I have so far two ways to do this. Either I can write method-names, in strings, in each attribute pointing to the method to call to get the instance, or I can use Duck Typing and add a "magic" method, that will contain information about the instance needed for each attribute.

Okay, let me show some code and then I need some feedback on which way is preferable or suggestions for other ways I haven't thought of.

public class SomeClass
{
[Parameter("OnePropertyWidgetProvider")]
public string OneProperty { get; set; }

[Parameter("AnotherPropertyWidgetProvider")]
public string AnotherProperty { get; set; }

private Widget OnePropertyWidgetProvider() {}
private Widget AnotherPropertyWidgetProvider() {}
}


Or

public class SomeClass
{
public string OneProperty { get; set; }
public string AnotherProperty { get; set; }

private ParameterWidgets GetWidgets()
{
return new ParameterWidgets()
{
{ () => this.OneProperty, new Widget() },
{ () => this.AnotherProperty, new Widget() },
};
}
}


The class itself a unit-of-work that can be configured through a GUI. The Widget-instance is needed to configure the editor the user should see to fill out the given property.

My concern with the first way is lack of type-safety, there is no way to check at compile-tile if the functions actually exists. It's always kinda verbose, and with many properties in one class, you end up with many methods returning Widgets.

The other way might introduce ways of coding that many programmers are not familiar with; lambdas and such. The syntax is cool, there is type safety, etc., but I'm afraid of it being "too clever".

-

## closed as off-topic by Heslacher, Quill, Pimgd, SuperBiasedMan, MastDec 14 '15 at 11:04

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

What is the underlying goal of this class? What purpose does the class serve? Do the properties need to be simple strings? You started with "I have a class with properties I need to reflect over" and "I need an instance of a complex type for each property", but those seem like implementation details which could still be malleable, given your two code examples. – Dan Lyons Apr 20 '12 at 16:42
The class itself a unit-of-work that can be configured through a GUI. The Widget-instance is needed to configure the editor the user should see to fill out the given property. – Pauli Østerø Apr 20 '12 at 16:45
This seems like bad separation of concerns to me. The class shouldn't decide how will its parts going to be displayed. – svick Apr 20 '12 at 17:27
the widget can contain information like textbox, dropdownlist, checkboxlist etc. Anyway, its just the way the system is constructed and i have no way to change that, so thats not really in the scope of this question. – Pauli Østerø Apr 20 '12 at 17:31

I've done this several times with a typeof operator in the attribute. That's how MS does their Editor attribute. The only disadvantage is that you can't pass constructor attributes that way. In other words you have an attribute on your property like this:

[Widget(typeof(TextBoxWidget))]


If you need parameters, you could still do it with inheritors of Widget. Suppose you need a Min/Max/Inc on your numeric widget:

[NumericWidget(-42, 42, 1)]


The methods to get the attributes allow you to look for inheritors of an attribute type.

Without this parameterized attribute approach, I definitely prefer your second option. And I would put GetWidgets into its own IHasWidgets interface. That way you can fall back to some default all-text-box implementation when that interface is missing.

Another good option is to put this information into the property registration. Are you familiar with the DependencyProperty mechanism in WPF? The CSLA framework (among others) support a property registration mechanism that is a good match for what you're doing here.

-

Another approach is to introduce family of types that can be mapped onto widgets to get proper representation in GUI. I.e. either interface

class OnePropertyType : IWidgetAssociatied
{
public string Value { get {} set {} }

Widget IWidgetAssociated.CreateWidget() {}
}

class AnotherPropertyType : IWidgetAssociated {}


Widget CreateWidgetFor(OnePropertyType one) {}