If you have a module that uses a type, we say that the module is "coupled"
to that type. It knows of the existence of the type, and any changes in the
type can potentially affect it.
We want to reduce coupling. That is one of the reasons for using base types
in the first place. In my mind, I can think of no better reason.
So, if a module 'has' an object of base type, and 'needs' an object of
derived type, it is already coupled to the derived type. Otherwise, it
wouldn't 'need' it.
Defining a construct that converts from the base type to the derived type,
in the base class, means that your base class has to either create a
conversion strategy that all derived classes will follow, or it has to be
coupled to each derived type. The latter is not feasable. The former is
possible. In fact, you could implement it in code if you want to.
I would suggest that it would be better to consider alternatives before you
go down that road. You aren't addressing the problem of coupling... you are
working around a 'limitation' that is more like a guard rail. Some
limitations are good for us all.
So, let's look at the problem, and consider alternatives.
Let's say that you have a SQL Server connection, and you pass it to a method
that understands generic database connections, and that method calls another
object that needs to use one of the SQL-specific properties...
I'd say that you need to use strategy patterns in combination with factory
methods. If the generic class gets its caller as a parameter, and the
caller provides the custom methods that the generic class requires, then the
generic method never needs to know the to specific type. Similarly, your
calling code could create a concrete class that performs specific activities
on the "connection" object that the generic code needs performed. The
calling class could pass in one of the "adapter" objects for the generic
code to use. (This pattern is used in the .Net framework).
Alternatively, your calling class and the "one step removed" dependent class
can be tied together using an abstract factory and a singleton. In this
case, your generic class doesn't need to cast anything or even be aware of
anything, because the generic object would turn to the factory to generate
the object to call, and that object would already EXPECT and GET a SQL
Server connection.
In other words, if you examine where you are creating coupling between your
classes, you can nearly always clear up these ambiguities by controlling
object creation more carefully.
I hope this helps,
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Mark McDonald" <Ma**********@discussions.microsoft.com> wrote in message
news:0A**********************************@microsof t.com...
This question kind of follows on from Mike Spass' posting 10/11/2004; I
don't understand why you can't declare an implicit operator to convert a base
class to a derived class.
The text books say "neither the source nor the target types of a
conversion can be a base type of the other, since a conversion would then already
exist". But this is not really true, whilst automatic (implicit)
conversions do occur from the derived class to the base class, they do not go the
other way because there is no way of knowing what items are in the derived class
that are not inherited from the base.
Each time I look at this I keep coming back to the same question: why can
't I write an operator that states what to do with the other items?
