Delegates vs. Class Hierarchy
-
In a helper class, I have a dictionary (object, target), where target can be created in a very few different ways, e.g. a delegate, a type or a specific object. Specifying a
System.Typefor target will be the most common option, but the caller should be able to use a custom delegate as well. One way to implement this is an abstract base:// ---- 1st implementation - virtual class hierarchy
// implementation 1class TargetBase
{
abstract object Convert(object o);
};public class TypeAdapter
{
Dictionary<object, TargetBase> dict;public void Add(Type source, Type target) { dict.Add(source, new TypeTarget(target); }
public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }object Map(object o) { return dict[o.GetType()].Convert(o); }
};(I've omitted the Typetarget, DelegateTarget implementations for brevity) Alternatively, since a delegate is in there anyway, I could use the delegate for the other options:
// ---- 2nd implementation - using the delegates directly
// implementation 1
public class TypeAdapter
{
Dictionary<object, MyDelegate> dict;public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }
public void Add(Type source, Type target)
{
dict.Add(source, delegate(object o) { Activator.CreateInstance(target, o); }
}object Map(object o) { return dict[o.GetType()](o); }
};The current implementation uses struct containing either a delegate or a type, and acts depending on which one is not null. This is IMO quite ok, since there is only a minor chance of a 3rd option, and I can't conceive more. I'd like to get some feedback which way you would go, and why. Topics I see are readability/maintainability and performance* *) I claim "not a premature optimization" here, since it's intended as a library component I don't know how it will be used, and I have no feeling for the performance/overhead of virtual calls vs. delegates.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | -
In a helper class, I have a dictionary (object, target), where target can be created in a very few different ways, e.g. a delegate, a type or a specific object. Specifying a
System.Typefor target will be the most common option, but the caller should be able to use a custom delegate as well. One way to implement this is an abstract base:// ---- 1st implementation - virtual class hierarchy
// implementation 1class TargetBase
{
abstract object Convert(object o);
};public class TypeAdapter
{
Dictionary<object, TargetBase> dict;public void Add(Type source, Type target) { dict.Add(source, new TypeTarget(target); }
public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }object Map(object o) { return dict[o.GetType()].Convert(o); }
};(I've omitted the Typetarget, DelegateTarget implementations for brevity) Alternatively, since a delegate is in there anyway, I could use the delegate for the other options:
// ---- 2nd implementation - using the delegates directly
// implementation 1
public class TypeAdapter
{
Dictionary<object, MyDelegate> dict;public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }
public void Add(Type source, Type target)
{
dict.Add(source, delegate(object o) { Activator.CreateInstance(target, o); }
}object Map(object o) { return dict[o.GetType()](o); }
};The current implementation uses struct containing either a delegate or a type, and acts depending on which one is not null. This is IMO quite ok, since there is only a minor chance of a 3rd option, and I can't conceive more. I'd like to get some feedback which way you would go, and why. Topics I see are readability/maintainability and performance* *) I claim "not a premature optimization" here, since it's intended as a library component I don't know how it will be used, and I have no feeling for the performance/overhead of virtual calls vs. delegates.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! |peterchen wrote:
In a helper class
I see this "helper class" statement being used a lot recently. At first I wonder, did I skipped the chapter in Design Patterns[^] that discusses the Helper Class Pattern? Then I remember that I'm seeing it here on code project and realize that it is more likely a result of poor design. If I am wrong help me pleeeezzz, it's urgent :rolleyes:
led mike
-
peterchen wrote:
In a helper class
I see this "helper class" statement being used a lot recently. At first I wonder, did I skipped the chapter in Design Patterns[^] that discusses the Helper Class Pattern? Then I remember that I'm seeing it here on code project and realize that it is more likely a result of poor design. If I am wrong help me pleeeezzz, it's urgent :rolleyes:
led mike
Maybe it's not a very good label, would "utility class" be a better one? I put everything under that label that is not explicitely domain-specific, i.e. doesn't have a roöe specific for the actual project at hand. Nonetheless, it has a very distinct role. We could also call it "glue and plaster". The idea I am following might be in very thin air[^], I will see. Maybe I should just have written "In a class" :rolleyes:
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
Maybe it's not a very good label, would "utility class" be a better one? I put everything under that label that is not explicitely domain-specific, i.e. doesn't have a roöe specific for the actual project at hand. Nonetheless, it has a very distinct role. We could also call it "glue and plaster". The idea I am following might be in very thin air[^], I will see. Maybe I should just have written "In a class" :rolleyes:
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistpeterchen wrote:
Maybe it's not a very good label, would "utility class" be a better one?
No. Unless I also skipped the Utility Class Pattern chapter in Design Patterns as well. Keep in mind I don't really care what all you guys do in your projects, but when you post a question in the "Design" forum it seems appropriate to mention that you may not be following the principles of Object Oriented Design and the use of Design Patterns.
peterchen wrote:
The idea I am following might be in very thin air[^], I will see.
When you go too far up, abstraction-wise, you run out of oxygen. That doesn't seem to match what you posted because what you posted sounds like it fits a Creational Pattern[^]
led mike
-
peterchen wrote:
Maybe it's not a very good label, would "utility class" be a better one?
No. Unless I also skipped the Utility Class Pattern chapter in Design Patterns as well. Keep in mind I don't really care what all you guys do in your projects, but when you post a question in the "Design" forum it seems appropriate to mention that you may not be following the principles of Object Oriented Design and the use of Design Patterns.
peterchen wrote:
The idea I am following might be in very thin air[^], I will see.
When you go too far up, abstraction-wise, you run out of oxygen. That doesn't seem to match what you posted because what you posted sounds like it fits a Creational Pattern[^]
led mike
phuket, CP ate my reply :mad:
led mike wrote:
Unless I also skipped the Utility Class Pattern chapter in Design Patterns as well
Are you sure you are not mixing up "Design Patterns" with "Compendium of past, current and future entity classification systems"? They like, have the same cover color and stuff ;) I'm not looking for a creator as such - I don't have a clear picture yet myself, so I tried to avoid the underlying problem. If you require the same interface from diverse types, you will have some that implement (i.e. know) the interface, and others for which you need a proxy (adapter? surrogate? your call! :)). What I am throwing some brain cycles at is a kind of
asoperator where you can register a surrogate for certain types. A similar pattern is used in serialization, where you can register surrogates for certain types that need specific handling. Another thing (the one I'm actually coming from) is MVC for "aggregate" views (like lists, trees, grids etc.) Here, the surrogate could acts as a "node controller" for diverse data node classes. I'm not yet sure if this makes sense, but also that was not my questionWe are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
In a helper class, I have a dictionary (object, target), where target can be created in a very few different ways, e.g. a delegate, a type or a specific object. Specifying a
System.Typefor target will be the most common option, but the caller should be able to use a custom delegate as well. One way to implement this is an abstract base:// ---- 1st implementation - virtual class hierarchy
// implementation 1class TargetBase
{
abstract object Convert(object o);
};public class TypeAdapter
{
Dictionary<object, TargetBase> dict;public void Add(Type source, Type target) { dict.Add(source, new TypeTarget(target); }
public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }object Map(object o) { return dict[o.GetType()].Convert(o); }
};(I've omitted the Typetarget, DelegateTarget implementations for brevity) Alternatively, since a delegate is in there anyway, I could use the delegate for the other options:
// ---- 2nd implementation - using the delegates directly
// implementation 1
public class TypeAdapter
{
Dictionary<object, MyDelegate> dict;public void Add(Type source, MyDelegate target) { dict.Add(source, new DelegateTarget(target); }
public void Add(Type source, Type target)
{
dict.Add(source, delegate(object o) { Activator.CreateInstance(target, o); }
}object Map(object o) { return dict[o.GetType()](o); }
};The current implementation uses struct containing either a delegate or a type, and acts depending on which one is not null. This is IMO quite ok, since there is only a minor chance of a 3rd option, and I can't conceive more. I'd like to get some feedback which way you would go, and why. Topics I see are readability/maintainability and performance* *) I claim "not a premature optimization" here, since it's intended as a library component I don't know how it will be used, and I have no feeling for the performance/overhead of virtual calls vs. delegates.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! |I'd say go for the first approach. By using your "TargetBase" class (or ITarget iface), you can apply extra information on those instances later on if you need. Eg, ITarget dt = new DelegateTarget(target); dt.Status = TargetStatus.New; // Im not saying that these properties applies in this context dt.TimeToLive = 123; //just that you have the option to add extra info if you need dict.add(source, dt); By using the pure delegate approach you can never attach any metadata to your targets. Except for using more dictionaries that carry the extra info for each delegate. Maybe you don't need such features, but IMO: an interface approach is always easier to extend than a pure delegate approach. And I think an interface approach is cleaner when it comes to semantics (this is ofcourse just my own take on it, others may not agree) Eg, every class that implements "ITarget" (or inherits TargetBase) promises that its purpose is to do what the interface implies. (ofcourse you can abuse it and implement it differently, but the semantics associated with your interface promises something) While delegates are more "oh yeah, I just return something of the correct type" , there is not the same kind of promise attached to a delegate type.
modified on Thursday, May 15, 2008 7:24 AM
-
phuket, CP ate my reply :mad:
led mike wrote:
Unless I also skipped the Utility Class Pattern chapter in Design Patterns as well
Are you sure you are not mixing up "Design Patterns" with "Compendium of past, current and future entity classification systems"? They like, have the same cover color and stuff ;) I'm not looking for a creator as such - I don't have a clear picture yet myself, so I tried to avoid the underlying problem. If you require the same interface from diverse types, you will have some that implement (i.e. know) the interface, and others for which you need a proxy (adapter? surrogate? your call! :)). What I am throwing some brain cycles at is a kind of
asoperator where you can register a surrogate for certain types. A similar pattern is used in serialization, where you can register surrogates for certain types that need specific handling. Another thing (the one I'm actually coming from) is MVC for "aggregate" views (like lists, trees, grids etc.) Here, the surrogate could acts as a "node controller" for diverse data node classes. I'm not yet sure if this makes sense, but also that was not my questionWe are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
Yeah, I see someone liked your reply enough to vote it a 5. All that stuff you said is great but where in surrogates and aggregate views and interfaces and all those nice buzz words you used is a "Helper" class? I don't think so. ;)
led mike
I showed you my definition of a "Helper class" (everything outside being domain specifc), now show me yours! ;)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
I showed you my definition of a "Helper class" (everything outside being domain specifc), now show me yours! ;)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
That's easy. My definition of a "Helper class"[^] :-D
led mike
Hmm... strange - I've been to Bolivia, but I've never seen anyone call these monkeys "helper class" over there :rolleyes: Seriously: Of course, if "helper classes" don't exist for you (because it's not a very descriptive term, or the GOF haven't written about it, or for whatever reason), this whole discussion is pointless.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistmodified on Thursday, May 15, 2008 5:20 PM