Constructor firing Inheritance in C#

[Guest]

I'm having a problem, and here is a simplified example of code that
demonstrates it:


public class BizObj
{
public string TableName="";
private DataSet oData;

public BizObj()
{
LoadData();
}

public void LoadData()
{
SqlConnection oConn = new SqlConnection("...");
SqlDataAdapter oAdapter = new SqlDataAdapter("SELECT * FROM
"+this.TableName,oConn);
oAdapter.Fill(oData);

}
}

public class AuthorBizObj: BizObj
{
public AuthorBizObj()
{
this.TableName="Authors";
}
}

Now, because the base class constructor fires first, LoadData is called
before the TableName can be set to "Authors".

So I try to override the TableName field in the following manner, hoping
that it will be set before the constructor methods fire:


public class AuthorBizObj: BizObj
{
public string TableName="Authors";

public AuthorBizObj()
{
}
}

But I get a compile warning: "The keyword new is required on
AuthorBizObj.TableName because it hides inherited member BizObj.TableName."

I'm not trying to hide the member, I'm trying to override it.

How can I make sure that the TableName field has the value "Authors" before
the BizObj constructor fires?

<b>This question is strictly about inheritance.</b>

You might say "Pass a value for TableName to the constructor" , but I think
that the Authors bizobj should know its table, not have its name passed into
it.

You might ask "Why do you want to call LoadData in the constructor?" or say
"Call LoadData after you have instantiated AuthorBizObj, not in the
constructor" - I'm actually not creating bizobjs, this is just some sample
code that demonstrates the problem, I'm trying to override a member field,
not figure out where LoadData should be called.

Thanks,

 

[Darren]

What about something like this? Here name gets set before the WriteLine is called.

class BaseObject
{
protected string name = string.Empty;

protected BaseObject()
{
Init();
}

protected virtual void Init()
{
System.Diagnostics.Debug.WriteLine(name);
}
}

class DerivedObject : BaseObject
{
public DerivedObject()
{
}

protected override void Init()
{
name = "MyTable";
base.Init();
}
}

 

[Mattias Sjögren]

I'm not trying to hide the member, I'm trying to override it.

Well you can't override fields.

You might say "Pass a value for TableName to the constructor" ,
Exactly.


but I think
that the Authors bizobj should know its table, not have its name passed into
it.

I don't see how that prevents you from passing it to a BizObj
constructor. Wouldn't this work for you?

public class BizObj
{
public string TableName;

protected BizObj(string tableName)
{
TableName = tableName;
LoadData();
}

...
}

public class AuthorBizObj : BizObj
{
public AuthorBizObj() : base("Authors")
{
}
}


Mattias

 

[chris martin]

I'm having a problem, and here is a simplified example of code that

demonstrates it:

public class BizObj
{
public string TableName="";
private DataSet oData;
public BizObj()
{
LoadData();
}
public void LoadData()
{
SqlConnection oConn = new SqlConnection("...");
SqlDataAdapter oAdapter = new SqlDataAdapter("SELECT * FROM
"+this.TableName,oConn);
oAdapter.Fill(oData);
}
}
public class AuthorBizObj: BizObj
{
public AuthorBizObj()
{
this.TableName="Authors";
}
}
Now, because the base class constructor fires first, LoadData is
called before the TableName can be set to "Authors".

So I try to override the TableName field in the following manner,
hoping that it will be set before the constructor methods fire:

public class AuthorBizObj: BizObj
{
public string TableName="Authors";
public AuthorBizObj()
{
}
}
But I get a compile warning: "The keyword new is required on
AuthorBizObj.TableName because it hides inherited member
BizObj.TableName."

I'm not trying to hide the member, I'm trying to override it.

How can I make sure that the TableName field has the value "Authors"
before the BizObj constructor fires?

<b>This question is strictly about inheritance.</b>

You might say "Pass a value for TableName to the constructor" , but I
think that the Authors bizobj should know its table, not have its name
passed into it.

You might ask "Why do you want to call LoadData in the constructor?"
or say "Call LoadData after you have instantiated AuthorBizObj, not in
the constructor" - I'm actually not creating bizobjs, this is just
some sample code that demonstrates the problem, I'm trying to override
a member field, not figure out where LoadData should be called.

Thanks,

I think "overriding" or "hiding" a field is bad news. How about this.

public abstract class BizObj
{
private readonly string TableName = string.Empty;

protected BizObj(string tableName)
{
this.TableName = tableName;
Console.WriteLine("BizObj Ctor");
LoadData();
}

protected void LoadData()
{
Console.WriteLine("TableName: {0}", TableName);
}
}

public class AuthorBizObj : BizObj
{
public AuthorBizObj() : base("Author")
{
Console.WriteLine("AuthorBizObj Ctor.");
}
}

 

[Guest]

Hi Darren,

Thanks for the reply.

I am trying to override a field: something that should be available in an
object-oriented language, IMO.

For example: If I create a Vehicle class with a WheelCount property, and
then I create a subclass Car, I dont think that I should have to set up a
special method just so that I can set the WheelCount to 4, I should just be
able to initialize WheelCount to 4.

And what's more annoying is that you can override a property - another
developer suggested that I should override the property:

public string TableName
{
get
{
return "Authors";
}
}

But that seems like it circumvents inheritance.

I'm trying to understand the thought process.

 

[Jon Skeet [C# MVP]]

Thanks for the reply.

I am trying to override a field: something that should be available in an
object-oriented language, IMO.

It's not been available in any of the languages I've worked in. I don't
see it's necessary, either.

For example: If I create a Vehicle class with a WheelCount property, and
then I create a subclass Car, I dont think that I should have to set up a
special method just so that I can set the WheelCount to 4, I should just be
able to initialize WheelCount to 4.

You could have a virtual *property*, as you say below.

And what's more annoying is that you can override a property - another
developer suggested that I should override the property:

public string TableName
{
get
{
return "Authors";
}
}

But that seems like it circumvents inheritance.

I'm trying to understand the thought process.

In what way does that circumvent inheritance? I'd suggest making it
abstract in the base class, even.

I prefer the idea of passing the name of the table to the base
constructor though. The business object knows the table it's part of
that way, but the business object class itself doesn't know any
specific tables. Sounds ideal to me.

 

[Guest]

Hi Mattias,

Thanks for replying

I hope what I say doesnt come across as an attack - I'm just trying to
understand.

Well you can't override fields.

What's the thinking behind that - why shouldnt fields be overridable?
Properties are, but they are public, what if I dont want it to be public?

Exactly.

That seems like a workaround - I'm trying to approach this totally from an
OOP point of view. Why have inheritance of fields if you are going to merely
pass all of the values into the constructor - and as the number of fields in
the base class(es) increase, the signature of the constructor must keep
growing.

I realize that part of the problem here is that I'm calling a method from a
constructor.

I don't see how that prevents you from passing it to a BizObj
constructor. Wouldn't this work for you?

If I know when I create a class what value a field should have, why should I
have to pass it in?

Bizobj was just an example of a class: I'm not trying to argue whether the
tablename should be passed into the constructor when I'm designing a Bizobj
class. But if I know that AuthorBizobj will have a table name "Authors" and
it will never change, why should I have to pass it in to the class?

 

[Jon Skeet [C# MVP]]

What's the thinking behind that - why shouldnt fields be overridable?

Fields aren't callable members - there's no vtable for them. I don't
think I even know what it would mean to be able to override a field.

Properties are, but they are public, what if I dont want it to be public?

Properties aren't always public. They can be private, protected,
internal etc.

That seems like a workaround - I'm trying to approach this totally from an
OOP point of view. Why have inheritance of fields if you are going to merely
pass all of the values into the constructor - and as the number of fields in
the base class(es) increase, the signature of the constructor must keep
growing.

Well, only the fields for which the base class needs information from
the derived classes need to be initialised in the constructor.

I realize that part of the problem here is that I'm calling a method from a
constructor.

Partly. Calling overridable methods in the constructor is almost always
a no-no. You need to clearly indicate in the documentation that the
method will be called before the object is fully constructed. For
instance, at that point there may be invariants which don't yet hold.

If I know when I create a class what value a field should have, why should I
have to pass it in?

So that Bizobj doesn't need to know about the Author class at all.

Bizobj was just an example of a class: I'm not trying to argue whether the
tablename should be passed into the constructor when I'm designing a Bizobj
class. But if I know that AuthorBizobj will have a table name "Authors" and
it will never change, why should I have to pass it in to the class?

Well you need to make the data available *somewhere*. I don't see why
passing it in the constructor is worse than having it anywhere else -
it's simple and it works.

 

[Guest]

Hi Jon,

Thanks for replying

I prefer the idea of passing the name of the table to the base
constructor though. The business object knows the table it's part of
that way, but the business object class itself doesn't know any
specific tables. Sounds ideal to me.

As I said in my post, I'm asking a more general question, the bizobj just
happened to be the example. I was trying to steer away from an app-specific
answer. Passing the name of the table to the bizobj speaks to the developers
thoughts on bizobjs. It works well if the hierarchy is more geared towards a
generic bizobj that won't necessarily be subclassed - you pass in the
tablename and the queries are structured programmatically.

I guess the best way to re-state my request is "I have code in a constructor
that calls out to another method . When creating subclasses of this class,
how can I override the values of fields (using initializers maybe??) so that
when the base class calls out to the method, the field is initialized to the
value appropriate for the subclass"

Thanks,
Rick

 

[chris martin]

Hi Jon,

Thanks for replying

As I said in my post, I'm asking a more general question, the bizobj
just happened to be the example. I was trying to steer away from an
app-specific answer. Passing the name of the table to the bizobj
speaks to the developers thoughts on bizobjs. It works well if the
hierarchy is more geared towards a generic bizobj that won't
necessarily be subclassed - you pass in the tablename and the queries
are structured programmatically.

I guess the best way to re-state my request is "I have code in a
constructor that calls out to another method . When creating
subclasses of this class, how can I override the values of fields
(using initializers maybe??) so that when the base class calls out to
the method, the field is initialized to the value appropriate for the
subclass"

Thanks,
Rick

You've already heard the correct answer. You don't "override" fields that
the method depends on. You have to pass the variables into the base constructor

 

[Jon Skeet [C# MVP]]

RickHodder wrote:

I guess the best way to re-state my request is "I have code in a constructor
that calls out to another method . When creating subclasses of this class,
how can I override the values of fields (using initializers maybe??) so that
when the base class calls out to the method, the field is initialized to the
value appropriate for the subclass"

You *could* have an Init method which could be overridden in derived
classes. However, my best advice would be to try to avoid that design
pattern in the first place.

Jon

 

[Darren]

It is best to keep as much of the initialization code in the base as possible.
That way, if your base class needs to change there is less impact on derived classes.