Posted by Jerry Stuckle on 09/09/05 17:48

Markus Ernst wrote:
> Jerry Stuckle wrote:
>
> Thank you for your detailled and understandable example! If I understand
> everything correctly, my problem is rather to make myself understandable (I
> am not a native English speaker and not an educated IT professional either,
> so I may have chosen the wrong words and also poor or too much simplified
> examples).

Not a problem. Your English is excellent - much better than many
Americans! No problem with your terminology, either. The problem here
is that proper inheritance hierarchies are not easy.

I did the following classes (each of which has a corresponding
> MySQL table):
>
> entity -> rubric -> page [1]
> entity -> contents element (such as text or picture or text and picture...)
> entity -> product category
> entity -> product -> book
> entity -> product -> cd
> entity -> product -> postcard
> entity -> author
> ...
>
[...]

>
> [1] I assume that the rubric -> page inheritance in my example (and the
> wrong book -> page example in my original posting) made the impression that
> I used inheritance for every kind of relations. Though it is true that a
> page is not a type of a rubric, this seemed useful to me as below a parent
> rubric there can be pages and sub-rubrics mixed. Thus specially the sort
> order handling and menu composition would be very complicated if pages and
> rubrics were handled separately.
>

But here is the problem. "A page is not a type of a rubric", so
inheritance is not appropriate. It may make things easier now, but can
cause problems in the long run.

The problem here is you need *some* relationship between "page" and
"rubric" - that is, they have some common data and methods (functions).
However, a "page" will not necessarily have ALL data and methods,
which would be true if you had a real "is-a" relationship.

Hilarion has the right idea. What you need is another level of
inheritance. Take the methods and data which are common to "page" and
"rubric" and extract them to "contents_element". That way you can
derive both "rubric" and "page" from "contents_element". Both will be
of the "contents_element" type, but there will not be a direct
relationship between the two.

>
> My original question was about how to include the methods needed for
> administration only in order to reduce server load at the front end.
> Actually entity inherited a class with lots of admin methods:
>
> common functions -> entity -> ...
>
> And also every class contains specialized admin functions; for example in
> the postcard class the method delete_postcard() will delete the postcard
> record and then call $this->delete_product(), which will delete the product
> record and call $this->delete_entity().
>
> So now I separated the admin methods into separate classes that are not
> inherited but only called when they are needed.
>
> Markus
>
>

You can separate them into different classes, but that will cause a lot
of duplication of work - if, for instance, you change your database,
you'll have twice as many classes which need to be updated, which is a
lot of what OO tries to avoid.

My first question is - do you really have a server load problem? What
is your CPU utilization? I suspect it's pretty low - few sites I've
seen average even 20-30% CPU over a one minute period during peak times.
And if you're going over 50% regularly, you probably need a faster
server anyway.

My point here is - parsing PHP code is generally pretty fast, especially
in respect to some operations like searching a database. If you are
having performance problems, it's time to look at the code to see how
you can optimize it better. Putting admin functions in another file
just won't save you much time (unless you have tens of thousands of
lines of code - and even then you won't save much).


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]