OOP concept - derived classes -C# question

[Guest]

Hi all
I have a class Parent, and two child classes class Child1
and class Child2 derived from Parent class.

In Parent class there is a method that will instantiate
child classes based on the input parameters it received.

I am able to instantiate my child class from the Parent
class, but not able to call the child class methods from
the Parent class by doing this.

Child1 ch1 = new Child1();
ch1.SomeMethod();

I think by changing the access level of SomeMethod() to
something like internal, I will be able to call the child
method from the parent class. But, I need to know if this
is the right way to do? Does it violate any OOP
recommendations? or can you recommend some other best
pratice? Thanks a lot for your help.

 

[Morten Wennevik]

Don't worry, using public methods and properties is OOP, accessing
variables in the child directly is not.

When you want the child to do anything you have to tell it so. If there
was no way to tell it anything (no public methods or properties) how could
you expect it to do anything.

Happy coding!
Morten Wennevik [C# MVP]

 

[Bjorn Abelli]

"Morten Wennevik" ...

Don't worry, using public methods and properties is OOP,
accessing variables in the child directly is not.

When you want the child to do anything you have to
tell it so. If there was no way to tell it anything
(no public methods or properties) how could
you expect it to do anything.

However, I believe the OP should think one more time about the design.

I can't tell from just the example, but forcing the superclass
to know about it's subclasses is in most cases a sign of bad
design.

// Bjorn A

 

[Guest]

Thanks for all your replies. can you please tell me what
would be a better design? My goal is to be able to call
different child classes based on conditions.

 

[Tom Porterfield]

"Morten Wennevik" ...

However, I believe the OP should think one more time about the design.

I can't tell from just the example, but forcing the superclass
to know about it's subclasses is in most cases a sign of bad
design.

// Bjorn A

Agreed. Typically the parent shouldn't care about specific items in any
derived classes, especially if there is a requirement that the class on
which the parent is invoking the method must be a child. If the original
poster will provide more details on what they are trying to accomplish,
possibly a better design pattern can be suggested. A guess might be that a
virtual method in the parent that is overriden in the child classes might be
what is desired, but impossible to say for sure without specifics.
--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.

 

[Morten Wennevik]

Actually you are completely right. I was thinking of MDIParent and Child
and not inheritance at all.

Happy coding!
Morten Wennevik [C# MVP]

 

[Joerg Jooss]

Thanks for all your replies. can you please tell me what
would be a better design? My goal is to be able to call
different child classes based on conditions.

Look at the (Abstract) Factory Design pattern:

http://www.dofactory.com/patterns/PatternAbstract.aspx

Cheers,

 

[Frans Bouma [C# MVP]]

Hi all
I have a class Parent, and two child classes class Child1
and class Child2 derived from Parent class.

In Parent class there is a method that will instantiate
child classes based on the input parameters it received.

I am able to instantiate my child class from the Parent
class, but not able to call the child class methods from
the Parent class by doing this.

Child1 ch1 = new Child1();
ch1.SomeMethod();

I think by changing the access level of SomeMethod() to
something like internal, I will be able to call the child
method from the parent class. But, I need to know if this
is the right way to do? Does it violate any OOP
recommendations? or can you recommend some other best
pratice? Thanks a lot for your help.

Your idea of having the parent creating childs (Despite the
similarities in nature ) is not that great. Parent-child relations have
to be seen as: child is-a parent, and thus adds specialization to parent.

It's also not appropriate to call methods of a child class in a
parent. If you want to do that, you should do it like this:

public class Parent
{
//...

public void Foo()
{
object var = Bar();
// other code
}

public abstract object Bar();
}

now, in child1 and child2, you 'plug in' the code for Bar:
public class Child1arent
{
//...

public override object Bar()
{
object var=null;

// do some stuff

return var;
}
}

This way you can call code in parent which is implemented in a
child class. This is called the 'strategy pattern'.

If you want to produce various classes, you should use a factory
class. A factory simply creates objects based on input and doesn't have
any relation to the objects created.

Frans.