So you want a specialised inherited class for everything in the framework
I'm not too deep into Linq, I'm discussing about Extension Methods here.
Yet, AFAIK, Linq only works on IEnumerable derived >classes. As does my
example... So what in fact would you do in both cases?
No, it does not. In your example you created a separate Linq wrapper
implementation for a Queue. Taking that one step further and assuming it
became Generic so as to work on any IEnumerable, it's still a wrapper class.
It does *not* provide the same non-breaking functionality that Linq
extensions do. The way MS have done it, List<T> is still List<T>. Queue<T>
is still Queue<T>, and so on. The only difference is that they offer up
some very powerful new features. They haven't broken any existing
implementations. I do not need to create pointless instances of specialised
wrapper classes.
Creating a wrapper class would be ugly and unncessary.
Using inheritance might actually work, except you'd have to create a new
sub-class of all existing classes in the framework that implement
IEnumerable<T>. Which then leads me back to my original question: what
happens when I want to create my own IEnumerable<T> type?
Again, I think this is a symptom of you not fully understanding the wheres
and whyfors of Extension methods. MS have (and have given us the capability
to) extended base classes and interfaces via Extension methods without
breaking existing code. Injecting new functions onto the IEnumerable type
means that they're available to any IEnumerable, and that the interface
itself remains unbroken. No need to alter code to handle breaking changes
due to base classes and interfaces that have been altered for new
functionality.
I agree with you. From the developer's point of view I don't see a
difference either (except for where to take functionality from, >where to
find it etc.), but from the designer's point of view Extension Methods are
a huge gate for proliferating bad coding.
As is object oriented design, in fact I would argue OO is far better
equipped for giving developers the opportunity to indulge in bad coding
practices and produce ridiculous implementations (going out of one's way to
avoid anything static and ensuring absolutely everything is instance-based,
for example). Extensions is, by comparison, a very small language shortcut.
I would compare Extensions to a blunted screw driver and OO to a buzz saw.
Give each one to a child and see which produces the most problems...
Actually you don't need to. As you've seen from my example I've used a
MyLinq generic to do the job. There wasn't even >inheritance involved here.
Still, in case you wouldn't need the derived class, just use the base
class. There is absolutely no reason >that would keep you from creating and
using base classes as long as they are not declared as being abstract.
Which requires further instantiation of a generic wrapper around an existing
IEnumerable<T> class, implicit/explicit casting, and less intuitive code.
Yuck, what a lot of work (and very ugly code) just for the sake of a half
dozen or so additional subroutines grafted on to existing classes. How is
that beneficial or easier for debugging purposes? In fact, as far as Linq
Extensions go, debugging is largely irrelevant as regardless of MS's
implementation the code would still be unavailable to you.
In a choice between having to instantiate special wrapper classes around any
of the IEnumerable's I use or just simply taking an existing
List/Queue/Array/etc and writing Linq queries, I know which one I'll choose,
and that it will be a lot easier to understand a year or two down the line
during maintenance.
Because, for instance, when implementing Extension Methods in a workgroup,
debugging will become a mess. You can't boil an >error down to a class's
implementation. It's impossible to narrow the search. You've just have to
debug the *whole* code.
Oh, that is a very weak and frankly ridiculous argument. For one, the
chances of you needing to extend your own code are far slimmer than say
providing an Extension method onto System.String. Example:
String myName = "Joe Bloggs";
String s = myName.ToPrettyFormat;
And your code crashes. Are you going to assume it's a bug in System.String,
or in your extension? I suppose that depends on how arrogant of a coder you
are, but I think the answer is obvious to most. Using today's debugging
tools (and yesterday's, and those of 7 years ago in fact) debugging
Extension methods is no more or less difficult than any other area of your
code. If I'm trying to find an error in a class, I'm going to be stepping
through code line-by-line in most instances anyway --- nothing about
Extensions makes my life any harder in that case. I really don't see your
problem, or to put it another way, I haven't encountered any challenges at
all with it.
I would prefer to have a set of
extension methods that are accessible via an instance of the object they
perform work on instead of some helper class.
Because it's sealed. Like System.String. Like many, many other types in
the .NET framework that are used heavily through a large nTier app.
Let's say for argument's sake I *can* drive from SqlConnection. I decide
that maybe there's some special work I want my code to do each time it
accesses a stored procedure, so I create SpecialSqlConnection and that
inherits from SqlConnection. I then implement my one function on that new
derived class. Simple eh?
I then go through and add the call to that new function in all areas of my
code that call out to stored procs. Except not only do I have to do that,
but I also have to change them to work with SpecialSqlConnection instead of
just SqlConnection. What if they received the connection object as a
parameter, passed down to them from the call stack? Whoops, looks like I've
got to trace all those calls back up the stacks until I've converted them to
use SpecialSqlConnection.
Yep, that's a nice easy solution, not at all complex, and would be a real
joy to debug, I'm sure...
Using Extension methods I can just "inject" my one new method onto the
existing sealed SqlConnection class, and voila, it works.
That's where it's being used, in my DAL. That does not mean that it isn't
being used extensively, and very regularly, and it certainly doesn't mean
that there aren't repetitive operations to be performed using the
SqlConnection class. It would not be appropriate for many of those sorts of
functions to be placed inside any other classes, and thus they end up in
their own class - one which would not require instantiating due to the
nature of the code it contains.
That's not to say I couldn't create a class that takes a SqlConnection as a
param to its constructor and has instance based methods that it performs on
that SqlConnection --- but why on earth would I waste time (not to mention
heap resources) on such an in-elegant and ill-thought out solution which
will inevitably result in much more hassle come debugging time? I'll keep
my Extensions thanks, and run the risk of the "paradigm police" knocking at
my door...
Alex
