Re: Abstract class variables question
- From: Peter Duniho <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Tue, 13 Nov 2007 20:00:20 -0800
On 2007-11-13 16:46:12 -0800, "tshad" <tfs@xxxxxxxxxxxxxx> said:
Using VS 2003, I am trying to take a class that I created to create new
variable types to handle nulls and track changes to standard variable types.
This is for use with database variables. This tells me if a variable has
changed, give me the original and current value, and whether the current
value and original value is/was null or not.
This one works fine but is recreating the same methods over and over for
each variable type.
What I wanted to do was create an Abstract class that did most of the work
and create a class for each variable type that only does what is needed.
I can't seem to get it to work correctly.
If I understand your question correctly, you have at least a couple of goals
* To share the repetitive functionality
* To preserve type safety
It's unfortunate that you can't move to 2.0, because writing a generic class would actually be the natural solution here. Nullable types are actually a special case of generic class (Nullable<T>), which is why they came up in Chris's reply but of course they don't support the other behaviors you want.
I think that with .NET 1.1, you're going to experience at least a little pain. There's not really what I'd call a "good" way to do this. That said, it shouldn't be too bad.
The main caveats:
* There's no good way to deal with value types. If you want to use the same field to store different kinds of data, you have to accept that value types will be boxed.
* You'll have to perform a cast somewhere.
That said, it seems to me that something like this would at least approach what you're trying to do:
abstract class DataType
{
protected object _objInitial;
protected object _objCurrent;
private bool _fChanged;
public bool IsNull
{
get { return _objCurrent == null; }
}
public bool IsFirstNull
{
get { return _objInitial == null; }
}
// You could just use the Data property to set the value to null
// as well. I'm not sure this method is really needed.
public void SetNull()
{
_objCurrent = null;
}
// I left out SetFirstNull()...shouldn't the initial value be
// set in the constructor and not touched after initialization?
// Likewise, I left out the setter for the First property
public object First
{
get { return _objInitial; }
}
public object Data
{
get { return _objCurrent; }
set
{
if (value != null)
{
_ValidateType(value);
}
_objCurrent = value;
_fChanged = true;
}
}
// Likewise, I don't think Changed should include a setter
public bool Changed
{
get { return _fChanged; }
}
// This is what deriving classes will define so the type can be checked
abstract protected Type _TypeRequired;
private void _ValidateType(object obj)
{
Type typeRequired = _TypeRequired;
// Depending on how you're using this class, you may instead prefer
// to check for exact type equality. The below simply requires that
// the passed-in object has the required type it its inheritance chain.
if (!typeRequired.IsInstanceOfType(obj))
{
throw new ArgumentException("assigned value type of " +
obj.GetType().Name + " is incompatible with required type of " +
typeRequired.Name);
}
}
}
class BoolType : DataType
{
// Each class defines this so that the base type can validate the data's type
protected Type _TypeRequired
{
get { return typeof(bool); }
}
// A convenience method so that no casting is needed when you already have
// a fully typed object
public bool TypedData
{
get { return (bool)Data; }
set { Data = value; }
}
}
class StringType : DataType
{
protected Type _TypeRequired
{
get { return typeof(string); }
}
public string TypedData
{
get { return (string)Data; }
set { Data = value; }
}
}
I provided an example of using it with a value type and with a reference type. As you can see, they are basically the same. In the case of the value type (BoolType) the act of setting the value to an object type boxes the value, and casting the object back to bool unboxes it.
If the above example doesn't accomplish what you want, then hopefully it's at least a good starting point for a discussion where you clarify the need.
Pete
.
- Follow-Ups:
- Re: Abstract class variables question
- From: tshad
- Re: Abstract class variables question
- From: Peter Duniho
- Re: Abstract class variables question
- References:
- Abstract class variables question
- From: tshad
- Abstract class variables question
- Prev by Date: Re: How: multiple program instances sharing same data
- Next by Date: Re: Abstract class variables question
- Previous by thread: Re: Abstract class variables question
- Next by thread: Re: Abstract class variables question
- Index(es):
Relevant Pages
|