The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

multiple extends

Hello,
still coding under PHP 4.

I have a few apps. There are some recursive methods. As my stuff is coded now, these methods are coded in each application. I would like to group them in one class and make this class the parent class of all the parent classes of my various applications.

Like:

PHP Code:

class MainParent {

//share all the methods common to all apps

}

class Application1 extends MainParent {

//this class is the parent class of all the Application1 classes and contains the methods used by all the Application1 classes.

}

class Application2 extends MainParent {

//this class is the parent class of all the Application2 classes and contains the methods used by all the Application2 classes.

}

I think that I'm good so far.

Now to what refers parent:: in the application subclasses? or $this-> ?

"Application" classes are almost certainly trying to do too much. I think you'll need to split this up into smaller, more focussed classes with discrete roles.

Once you've encapsulated everything nicely you then need to figure out how to get everything talking to each other... Studying design patterns will help to give you some ideas. Inheritance is definitely not the way to do this and should be reserved for situations where the two classes are basically the same thing.

OOP design takes a while to get to grips with. Patterns give you some ideas about how to weave objects together but you wouldn't code to fit a pattern: you fit the patterns to your requirements. The key point is to create objects with clearly defined responsibilities which don't try to do too much.

If you're starting out with OOP you won't get it right first time - even experienced programmers won't get it right first time. It's a kind of evolutionary process. The forces of (un)natural selection are questions such as are the objects too tightly coupled? Are they cohesive? What happens if you stress the design with a certain type of change such as a switch to a different database? If you're testing, the bottom line is do the unit & etc tests run green?

It's a strange mix of philosophy and engineering. You're free to invent your own entities to carry out particular roles although they also have to relate closely to practical requirements. You'll get killed in programming with any lack of clarity all the way from variable and method names right up to the top level client requirements and the first step is to identify exactly what your requirements are then code to these. Modern practices like Extreme Programming put a strong emphasis on clear requirements and use testing to stay focussed on these.

OOP design takes a while to get to grips with. Patterns give you some ideas about how to weave objects together but you wouldn't code to fit a pattern: you fit the patterns to your requirements. The key point is to create objects with clearly defined responsibilities which don't try to do too much.

If you're starting out with OOP you won't get it right first time - even experienced programmers won't get it right first time. It's a kind of evolutionary process. The forces of (un)natural selection are questions such as are the objects too tightly coupled? Are they cohesive? What happens if you stress the design with a certain type of change such as a switch to a different database? If you're testing, the bottom line is do the unit & etc tests run green?

It's a strange mix of philosophy and engineering. You're free to invent your own entities to carry out particular roles although they also have to relate closely to practical requirements. You'll get killed in programming with any lack of clarity all the way from variable and method names right up to the top level client requirements and the first step is to identify exactly what your requirements are then code to these. Modern practices like Extreme Programming put a strong emphasis on clear requirements and use testing to stay focussed on these.

The mainparent class isn't instantiated... maybe that's why why I can't get it? It's like the Application class can use the vars set in MainParent but not DoSomething...
Does anyone have an idea why? Any usual suspect around?

Constructors sorta bubble up the inheritance hierarchy. The interpreter looks for a constructor in the instantiated class; if it doesn't find it there, it looks in its parent class, and so on. As soon as it finds one, the interpreter executes it and stops looking.

You need to call the base class constructor in Application's constructor, since you supply an explicit constructor (base class constructors are only called implicitly if there is no explicit constructor in the derived class).