Polymorphism - right or wrong?

I have classes Section_Input and Content_Input which are both dreived from an Input class. They both implement a method called delete.

The behviour of the delete method is dependant on the sub class from which it is being called. I.e: if the delete method is called from the section_input class then it instantiates a new object called Section and if the delete method of the Content_Input class is called is instantiates a content class.

At present I am setting a property in each sub class called Action_Class_Name, which holds the name of the class it should create when the deelete method is called. Is doing it this way bad practice? Should each subclass have its own delete mehtod?

I would say yes - each should override a delete method from a common ancestor.

It comes down to what the delete method is doing. If the action is similar in nature, but has some differences (operates on other class-types, needs different input data, etc.), then you should use polymorphism.

If the action is not similar, basically the only similarity being the name, then you should not use polymorphism.

Quote:

---

Originally Posted by KTottE

It comes down to what the delete method is doing. If the action is similar in nature, but has some differences (operates on other class-types, needs different input data, etc.), then you should use polymorphism.

If the action is not similar, basically the only similarity being the name, then you should not use polymorphism.

---

Yes, both methods are similar. They create an instance of another class and invoke its delete method, so I am quite sure I need polymorphism. The input classes are there as a front end to a web application and the delete method of the input class first finds the "id" of the object to delete.

The problem I am running into here is how best to do it. Like I say at present I am using a property with the name of the class that the delete method should instantiate. This property is set in each sub class and the delete method resides in the superclass.

I am doing it like this because the user input is an array of id's which are to be deleted. The array is then traversed, an instance of each item created and its delete method invoked. If I do this by overriding the delete method in the superclass then this will mean duplicating the code and in my eyes that seems a little pointless -- but maybe I have the wrong idea here :confused:

I haven't really gotten into this in .NET, but in C++, if you have three classes:

MyBase, MyChildA, and MyChildB, where both the MyChild classes are derived from the MyBase, and if you have a delete function in each, with the function in MyBase declared virtual, then if you call delete from a pointer to a MyBase object, the proper function in the child class will run.

Yes, that would duplicate code, because there must be an implementation of Delete in both child classes, and the implementations would be very similar. The question then would be whether calling the function through the base is more convenient than copying the code into the different derived classes.

I assume similar functionality exists in .NET, though I haven't really looked into it. You probably have to interpret all the objects as MyBase, then call the delete function, and the proper delete function in the child will be called.

Quote:

---

Originally Posted by visualAd

I am doing it like this because the user input is an array of id's which are to be deleted. The array is then traversed, an instance of each item created and its delete method invoked. If I do this by overriding the delete method in the superclass then this will mean duplicating the code and in my eyes that seems a little pointless -- but maybe I have the wrong idea here :confused:

---

Could you not use a static (shared in vb) method of the superclass that is Delete with one or two arguments passed along?

So are you saying that both my base classes should implement the delete function and if need be call the delete function of the superclass using a pointer to new class instances?

Yeah, I'm using PHP 4, here, so it won't handle anything like virtual functions - at the moment each base classs has a property called action_class_name which contains the name of the class which the delete function should create an instance of and I am just implementing the delete function in the superclass.

At the moment this seems the easiest method but I am not sure whether this is bad practice or whether it could potntially cause problems if i need to make changesto it in the future.

Quote:

---

Originally Posted by visualAd

So are you saying that both my base classes should implement the delete function and if need be call the delete function of the superclass using a pointer to new class instances?

Yeah, I'm using PHP 4, here, so it won't handle anything like virtual functions - at the moment each base classs has a property called action_class_name which contains the name of the class which the delete function should create an instance of and I am just implementing the delete function in the superclass.

At the moment this seems the easiest method but I am not sure whether this is bad practice or whether it could potntially cause problems if i need to make changesto it in the future.

---

You should use polymorphism. It creates the best solution because it makes adding to a library almost plug and play. It's eaiser to maintain and saves you coding time. If You didn't use poly then you would have to use switch logic.

Quote:

---

Originally Posted by Maven

You should use polymorphism. It creates the best solution because it makes adding to a library almost plug and play. It's eaiser to maintain and saves you coding time. If You didn't use poly then you would have to use switch logic.

---

I am using polymorphism, or so I think. I'm just not sure whether or not what I am doing is correct. I have two objects which both implement the same method called update.

This method is nearly 100 lines of code and only have two minor differences. So what I have done is implemented the update function in the parent class and set a private proerty in each child class which is used by the update method in the ancestor calss when it is called.

I have a feeling this is bad paractice however and need your oppinions on the some alternate methods of doing this. Thanks.

Quote:

---

Originally Posted by visualAd

I am using polymorphism, or so I think. I'm just not sure whether or not what I am doing is correct. I have two objects which both implement the same method called update.

This method is nearly 100 lines of code and only have two minor differences. So what I have done is implemented the update function in the parent class and set a private proerty in each child class which is used by the update method in the ancestor calss when it is called.

I have a feeling this is bad paractice however and need your oppinions on the some alternate methods of doing this. Thanks.

---

So let me get this striaght, you have the update function in you're base class and you simply set properties in you're children? If that is what you're doing then no that's not very good at all.

There is 2 clean way's you can go about doing this. One is static binding and the other is dynamic (poly) binding. With static binding you would simpley say childclass.update("blah");

However with dynamic binding you would need to do something like this:

void virtualUpdatePtr (const baseclass * baseClassPtr)
{
baseClassPtr->update();
}

you would call it like so: virtualUpdatePtr(&childclassPtr);

So that is basically one way of doing it by using a function to manage the pointers. You could also just create a Base Class ptr and just reference a childclass and use the UPdate function from the base class pointer. What happens is there is a lookup on the vtable and the correct function is called. So if you use child1 then a child1 update function is called. If you use a child2 class then a child2 update function is called. It calls the correct function depending on what class you're using.

Didn't you catch that he was using PHP4?

Quote:

---

Originally Posted by Maven

You could also just create a Base Class ptr and just reference a childclass and use the UPdate function from the base class pointer. What happens is there is a lookup on the vtable and the correct function is called. So if you use child1 then a child1 update function is called. If you use a child2 class then a child2 update function is called. It calls the correct function depending on what class you're using.

---

I'm not sure I completely understand this and not sure whether PHP will allow me to do it.

Do you mean each of my child classes should still implement the update function but only the code sepcific to that class and then call the parent class update function which contains the code common to both the classes?

Or am I just not getting this? :ehh:

Quote:

---

Originally Posted by KTottE

Didn't you catch that he was using PHP4?

---

Thats alright, I do understand the C++ and can convert where possible. (most of it anyway, not sure about the vtables though) ;)

Quote:

---

Originally Posted by visualAd

I'm not sure I completely understand this and not sure whether PHP will allow me to do it.

Do you mean each of my child classes should still implement the update function but only the code sepcific to that class and then call the parent class update function which contains the code common to both the classes?

Or am I just not getting this? :ehh:

---

Yea pretty much, if you don't use it in you're parent class then make it a pure virtual function. See basically you're setting a child pointer to a parent pointer and calling update with the parent pointer. The correct update will be called depending on the object in use.

oops php lol... Hey does php even support poly?

/me runs away

Quote:

---

Originally Posted by Maven

oops php lol... Hey does php even support poly?

---

Yes it does. It supports inhreitence and function overrides, so in effect it can support polymorphism. Alot of OOP programmign in PHP 4 is down to disapline as it doesn't understand the concepts of public/private/protected, what makes it even more annoying is that it deals with objects like they are normal lets say (scaler) types. I.e: if you do this:

PHP Code:

---

$object = new Object;

$o = $object; 


---

In most OO languages if $object is of an object type $o is assigned a reference to $object. But in PHP 4 a copy of the entire object is made and then assigned to $o. Even worse the first line that creates a new instance of an object also returns a copy. It means you can easily get in a mess working with loads of copies of what you think is the same object. All this is easily fixed with the & operator, but none the less still very annoying. Thankfully PHP 5 fixes most of these caveats.

Anyway, thanks very much for your help ... I am going to use your suggestion here as it seems the most sensible and means I don't have to copy huge chunks of code in my child classes which to me seems to defeat the purpose of polymorphism. :D

Quote:

---

Originally Posted by visualAd

Yes it does. It supports inhreitence and function overrides, so in effect it can support polymorphism. Alot of OOP programmign in PHP 4 is down to disapline as it doesn't understand the concepts of public/private/protected, what makes it even more annoying is that it deals with objects like they are normal lets say (scaler) types. I.e: if you do this:

PHP Code:

---

$object = new Object;

$o = $object; 


---

In most OO languages if $object is of an object type $o is assigned a reference to $object. But in PHP 4 a copy of the entire object is made and then assigned to $o. Even worse the first line that creates a new instance of an object also returns a copy. It means you can easily get in a mess working with loads of copies of what you think is the same object. All this is easily fixed with the & operator, but none the less still very annoying. Thankfully PHP 5 fixes most of these caveats.

Anyway, thanks very much for your help ... I am going to use your suggestion here as it seems the most sensible and means I don't have to copy huge chunks of code in my child classes which to me seems to defeat the purpose of polymorphism. :D

---

Wait, it takes more then inheritance and overides to do polymorphism. You have to have the ability to create virtual functions. Apparently PHP works everything out for you, behind the curtains as I pulled a few books down to make sure.


anyway, think I'll end this with a rant:

I never did like PHP, I never did like how you mix html and code in the same page. To me it's very ugly so it's something that I haven't messed with all that much. I also hated it's network functions, I always wanted php to look a lot more like perl. It's like the language was developed as they needed it and ended up with a incomplete langauge. It's a good solution though for many web sites however because you are getting pass the CGI protocol. So in a nutshell php is not as hard on a server because of that protocol. Though I guess one could use an apache extension like Mod_Perl to get around the protocol. However that ties you into a server (Even if it's the most used). IF I was going to go through all of that, I'd probably write everything in C. Which is smoking fast if you take the time and effort to get around CGI =/

Quote:

---

Originally Posted by Maven

Wait, it takes more then inheritance and overides to do polymorphism. You have to have the ability to create virtual functions. Apparently PHP works everything out for you, behind the curtains as I pulled a few books down to make sure.


anyway, think I'll end this with a rant:

I never did like PHP, I never did like how you mix html and code in the same page. To me it's very ugly so it's something that I haven't messed with all that much. I also hated it's network functions, I always wanted php to look a lot more like perl. It's like the language was developed as they needed it and ended up with a incomplete langauge. It's a good solution though for many web sites however because you are getting pass the CGI protocol. So in a nutshell php is not as hard on a server because of that protocol. Though I guess one could use an apache extension like Mod_Perl to get around the protocol. However that ties you into a server (Even if it's the most used). IF I was going to go through all of that, I'd probably write everything in C. Which is smoking fast if you take the time and effort to get around CGI =/

---

The very reason PHP was created was as a templating language. It was oringinally a set of CGI scripts written in C that allowed you to embed instructions in HTML. I do agree with you on this though - PHP looks particually unsigtly when people use it to embed HTML inside large echo statements and SQL querys smack bang in the middle of HTML.

I am firm believer that PHP should be kept as a templating language and any backend stuff like colllecting result sets from a database should be done by a separate script which does not produce any output.

About CGI - In many cases PHP runs as a CGI script. Personally I write my applications for the CGI becuase all web server applications support CGI. Whether it is faster or not to run PHP as web server module depends on the Web server you use, but in many cases it is safer.

Te reasons I have fallen for PHP is for the following reasons:

• PHP is very flexible and at the same time very easy to learn.
• The documentation on their site is excellent and there is a function for nearly every task you can think of.
• Moving on from your point about the language being "developed as needed", i feel this is one of its big pluses. Being open source with a well documented API, it is very easy to add extensions to the language. It says something when a group of templating CGI scripts evolves into a near object orientated programming language in less than 12 years.
• Oh and did I mention it is multi platform / multi server. It means a well written script can be ran unchanged on most systems.

What does give PHP bad press is, the fact that people view it as an "easy to use language", as a result develop sloppy unmaintatinable code with many security holes. Just becuase it is easy learn doesn't mean that it makes developing a large web aplication a slap dash job thrown togetherin a few days. ;)