Exposing a Property for a Derived class

[Magnus.Moraberg]

Hi,

I have the following classes -

Result
{
public Person Person{get{return person;}}

public Result(Person person)
{
this.person = person;
}

// private
Person person;
}

FarmerResult : BaseClass
{
public Farmer farmer{get{return ???;}}

public FarmerResult (Farmer farmer)
: base(farmer)
{
}
}

I wish to have a public get for my FarmerResult which returns the
Farmer in question, rather than using the Person accessor. In other
words, farmerResultObj.Farmer rather than farmerResultObj.Person.

The above code is just an example, in my case I have very abstract
names for my base classes. For example, the user can view information
for a Test in terms of either Scenarios or User Functions. The
information stores in the Scenarios and User Functions classes are
near identical so I've used a base class to represent this, a base
class with a very abstract name and so on...

Thanks,

Barry.

 

[Marc Gravell]

So since you know that the person is a farmer, you can simply cast:

public Farmer Farmer {get{return (Farmer)base.Person;}}

Acutally, I'd be inclined to re-declare the same property-name, to avoid
hanving duplicate-looking properties:

new public Farmer Person {get{return (Farmer)base.Person;}}

Assuming that Farmer : Person, another option is generics:

class Result<T> where T : Person
{
private T person;
public T Person { get { return person; } }
public Result(T person)
{
this.person = person;
}
}

Here you can have a Result<Person> and a Result<Farmer> - each will
automatically only accept the correct type, and expose (via the Person
property) an object of that type.

Marc

 

[Brian Gideon]

Hi,

I have the following classes -

Result
{
  public Person Person{get{return person;}}

  public Result(Person person)
  {
    this.person = person;
  }

  // private
  Person person;

}

FarmerResult : BaseClass
{
  public Farmer farmer{get{return ???;}}

  public FarmerResult (Farmer farmer)
    : base(farmer)
  {
  }

}

I wish to have a public get for my FarmerResult which returns the
Farmer in question, rather than using the Person accessor. In other
words, farmerResultObj.Farmer rather than farmerResultObj.Person.

The above code is just an example, in my case I have very abstract
names for my base classes. For example, the user can view information
for a Test in terms of either Scenarios or User Functions. The
information stores in the Scenarios and User Functions classes are
near identical so I've used a base class to represent this, a base
class with a very abstract name and so on...

Thanks,

Barry.

I'm assuming that FarmerResult is a subclass of Result and not
BaseClass?

public Farmer Farmer
{
get { return (Farmer)Person; }
}

 

[Magnus.Moraberg]

I'm assuming that FarmerResult is a subclass of Result and not
BaseClass?

public Farmer Farmer
{
  get { return (Farmer)Person; }

}

Yeah sorry about that. Thanks for the reply.

Lets say I have a Results class which stores an array of type Result.
And lets say I expose each member of the array as follows -

Result[] results;
public Result this[int index]
{
get
{
if (index >= 0 && index < results.length)
return results[index];
else
throw new KeyNotFoundException();
}
}

Now lets say that FarmerResults inherits from this class, then I won't
be able to do something like this -

FarmerResults farmerResults = new FarmerResults();
farmerResults.Farmer

since this[] returns a Results object.

So I would have to implement this[] for FarmerResults also. Correct?

Thanks again,

Barry.

 

[Marc Gravell]

The second part of your example isn't clear, but I suspect the answer is
"yes", unless you use generics in which case it might get a lot easier.

Aside: that should probably be an IndexOutOfRangeException (not that it
matters a great deal).

Marc

 

[Magnus.Moraberg]

The second part of your example isn't clear, but I suspect the answer is
"yes", unless you use generics in which case it might get a lot easier.

Aside: that should probably be an IndexOutOfRangeException (not that it
matters a great deal).

Marc

Thanks again.

I don't understand how using Generics would allow me to do the
following -

Person personOfResult = result.Person
Farmer farmerOfResult = result.Farmer

Instead I would have to use -

Person personOfResult = result.Person
Farmer farmerOfResult = result.Person

And thats my issue, I wish to expose clear names for my derived
classes, since my bases have abstract names like -

TestChildResult

where UserFunctionResult and ScenarioResults inherit from
TestChildResult. Now, a Test, a UserFunction and a Senario have no
real parent-child relation other than when I present their results. In
this case, the display is organised in a manner where UserFunctions
and Scenarios appear at the same level on the display. And as a
result, share a large amount of info, hence the base class
TestChildResult. Its a real pain to have UserFunctionResult and
ScenarioResults as completely separate classes since a change in one
usually coincides with a change in the other.

 

[Marc Gravell]

With generics, rather than making the *property* clear, you make the
*type* clear...

Result<UserFunction> result = ...
UserFunction funcOfResult = result.Value; // perhaps - or some

If you want to add extra properties to one of them, you can always do:

class ScenarioResult : Result<Scenario>
{
public string ScenarioName {get;set;}
}

this then has the inherited properties of Result<T> (typed as
T=Scenario), and the additional ScenarioName.

If I've completely misread your question, please do tell me...

Marc

 

[Marc Gravell]

With generics, rather than making the *property* clear, you make the
*type* clear...

Result<UserFunction> result = ...
UserFunction funcOfResult = result.Value;
// (.Value could be called anything suitable clear)

If you want to add extra properties to one of them, you can always do:

class ScenarioResult : Result<Scenario>
{
public string ScenarioName {get;set;}
}

this then has the inherited properties of Result<T> (typed as
T=Scenario), and the additional ScenarioName.

If I've completely misread your question, please do tell me...

Marc