about where to do the implementation for an interface

[Tony Johansson]

Hello!

Below I have an abstract class called Animal as you can see.
I have two questions about this.
1. I must be able to access some of the field from the derived classes what
is the best approach.
Is it to change the fields from private to protected or use public
property that the derived classes can access.

2.Here is an example of an interface that this class Animal implements
interface IAnimal
{
string ID { get; set; }
EaterType Eater { get; set; }
bool Aggressive { get; set; }
GenderType Gender { get; set; }
}

Now where is it most appropriate to do the concrete implementation for these
methods/properties
As I understand this if we for example take the first member ID of the
interface IAnimal we can make the concreate
implementation in the Animal class if we just want to return the ID that is
stored in the Animal class.
If we take the second member which is the property Eater we can do the
concreate implementation in the Animal class because
we only access the eater field
If we take the third member which is the property Aggressive we can do the
concreate implementation in the Animal class because we only access the
aggressive field.
If we take the fourth member which is the property Gender we can do the
concreate implementation in the Animal class because we only access the
gender field
Now in this example all concrete implamentations was done in the Animal
class.
So accoding to my knowledge we can always do the concreate implamentations
in the base class if the derived class hasn't any fields to add to the
implamentations

So can anyone give an good example when it would be nessessary to make the
concrete implementation of one of the methods/properties in one of the
derived classes ?


abstract class Animal :IAnimal
{
private string name;
private string id;
private double age;
private GenderType gender;
private HousingType housing;
private EaterType eater;
private bool aggressive;
private FoodItem food;

public Animal(string name, string id, double age, GenderType gender,
HousingType housing,
EaterType eater, bool aggressive, FoodItem food)
{
this.name = name;
this.id = id;
this.age = age;
this.gender = gender;
this.housing = housing;
this.eater = eater;
this.aggressive = aggressive;
this.food = food;
}

public string Name
{
get { return name; }
set { name = value; }
}

public string ID
{
get { return id; }
set { id = value; }
}

public double Age
{
get { return age; }
set { age = value; }
}

public GenderType Gender
{
get { return gender; }
set { gender = value; }
}

public HousingType Housing
{
get { return housing; }
set { housing = value; }
}

public EaterType Eater
{
get { return eater; }
set { eater = value; }
}

public bool Aggressive
{
get { return aggressive; }
set { aggressive = value; }
}

public FoodItem Food
{
get { return food; }
set { food = value; }
}

#region IAnimal Members abstract definitions

public abstract string AnimalLikesTheFood(string food);

#endregion
}

//Tony

 

[Arne Vajhøj]

Below I have an abstract class called Animal as you can see.
I have two questions about this.
1. I must be able to access some of the field from the derived classes what
is the best approach.
Is it to change the fields from private to protected or use public
property that the derived classes can access.

2.Here is an example of an interface that this class Animal implements
interface IAnimal
{
string ID { get; set; }
EaterType Eater { get; set; }
bool Aggressive { get; set; }
GenderType Gender { get; set; }
}

Now where is it most appropriate to do the concrete implementation for these
methods/properties
As I understand this if we for example take the first member ID of the
interface IAnimal we can make the concreate
implementation in the Animal class if we just want to return the ID that is
stored in the Animal class.
If we take the second member which is the property Eater we can do the
concreate implementation in the Animal class because
we only access the eater field
If we take the third member which is the property Aggressive we can do the
concreate implementation in the Animal class because we only access the
aggressive field.
If we take the fourth member which is the property Gender we can do the
concreate implementation in the Animal class because we only access the
gender field
Now in this example all concrete implamentations was done in the Animal
class.
So accoding to my knowledge we can always do the concreate implamentations
in the base class if the derived class hasn't any fields to add to the
implamentations

So can anyone give an good example when it would be nessessary to make the
concrete implementation of one of the methods/properties in one of the
derived classes ?

Those properties all belong to Animal because the backing field
is there so of course they should be implemented in Animal.

But if you have a property where the field is not in Animal
or a method that Animal can not implement, then the
implementation should be in the sub class.

A classic example:

public interface IAnimal
{
void Say();
}

public class Animal : IAnimal
{
public abstract void Say();
}

public class Dog : Animal
{
public void Say()
{
Console.WriteLine("Vov vov");
}
}

public class Cat : Animal
{
public void Say()
{
Console.WriteLine("Mjav majv");
}
}

Arne

 

[Arne Vajhøj]

Below I have an abstract class called Animal as you can see.
I have two questions about this.
1. I must be able to access some of the field from the derived classes what
is the best approach.
Is it to change the fields from private to protected or use public
property that the derived classes can access.

I forgot that one.

If the properties does not contain any functionality besides
accessing the field, then it does not have any practical
impact what you do.

If they do, then you need to decide on whether you want
that functionality or not when sub classes access the
fields.

If the properties are virtual then I would tend to prefer
the direct field access, because someone overriding those
will not know how they get called internally and that
could give some unexpected results.

Arne