Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Common methods for different objects
Message
From
21/05/2009 04:42:01
 
 
To
20/05/2009 16:02:40
General information
Forum:
ASP.NET
Category:
Coding, syntax and commands
Environment versions
Environment:
C# 3.0
OS:
Windows XP
Network:
Windows 2003 Server
Database:
MS SQL Server
Miscellaneous
Thread ID:
01400964
Message ID:
01401209
Views:
46
This message has been marked as a message which has helped to the initial question of the thread.
Hi,
I also find (2) a flexible approach - especially since you can plug in different implementations at runtime etc.

>Not sure yet whether I should make an extension method or a just a static class with those methods
I think you end up with exactly the same excution when compiled.
x.MyExtension() translates to
MyExtension(x) under the hood - you can invoke an extension method in this way if you wish anyway

I don't remember where I read that MS favours minimising their use (and I certainly don't take everything they say as gospel(g)) - but they came up with it and understand the innards so I assume there is some basis to the recommendation. Maybe a performance issue, maybe a perceived readability issue. There's a tendency to think of extensions methods as having fixed (baked-in) behaviour but the potential to have them behave differently in different parts of an app - but I don't think that would be a real concern in a real world situation.....

>About the extension method
>It has its pros and cons - you can add it to any class, but if you have many - there's the trees and the forest
>If only that class of grid needs them - better to use #1 imo
>
>If all grids need them - better to use an extension method
>If the grids that will need them do not necessarily have the same base class - an Interface + extension method on the interface may be the way to go
>
>Reason why I suggested (2) is that I've started reading the GOF - favour composition over inheritance. Haven't digested yet - but I see some advantages over subclassing
>Subclassing may lead to huge classes in the end - too much code(if you could see my grid's base class in foxpro - uh) . But (2) has the advantage that the additional class will be small and easy to understand - and maintain. In addition, you just plug it in where you need it.
>
>ps: I haven't thought extension methods fully through yet. I could add a lot of extension methods to string. But too many is not good either
>[Some things like convert to utf8, utf7, zip,. .... Not sure yet whether I should make an extension method or a just a static class with those methods]
>
>Just dreaming
>
>ps: Who cares about MS recommending against extension methods ? I don't
>
>Gregory
>
>
>>Hi,
>>
>>I suggested the first. Thought of suggesting the second. But I'm not sure about using an Extension method.
>>I know it would work but MS seem to recommend against them when there are alternatives.
>>Great if you don't have access to the source of the targeted class but, in the end, they are really just syntatic sugar?
>>Best,
>>Viv
>>
>>
>>>At least three possibilities come to mind
>>>
>>>(1) Subclass the grid, and put the methods in that class
>>>The grids you use will be based on that class
>>>
>>>(2) create a class that implements those methods
>>>Add it to the grids that will use it
>>>Call the methods of that class
>>>
>>>(3) Extension methods
>>>- either for all grids
>>>- or for a subclass of the grid's class
>>>
>>>
>>>There will be other ways
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform