References between nested objects (PHP4)

[Markus Ernst]

Hello

In a content administration tool I call classes from inside classes in order
to separate the admin functions from the display-only functions:

class book
{
var $title;
var $author;
var $adminfunctions ;

function book($admin = false)
{
if ($admin) {
$this->adminfunctio ns =& new book_admin($thi s);
}
}

function display_book()
{
return $this->author.": ".$this->title;
}
}

class book_admin
{
var $boss;

function book_admin(&$bo ss)
{
$this->boss = $boss;
}

function update_book($au thor, $title)
{
$this->boss->author = $author;
$this->boss->title = $title;
}

[lots of other methods]
}

The admin code will be something like:

$book =& new book(true);
$book->adminfunctio ns->update_book("M ichael Crichton", "Jurassic Parc");
echo $book->display_book() ;

As you see there is a circle reference, as book_admin::bos s is a reference
back to book. I assume this is bad, and actually there are some problems
that I suspect are originated there.

Is there another possibility to access properties of the calling object? I
did not find any syntax similar to the parent::propert y syntax, and I can't
use inheritance, as there is already a vertical inheritance (such as page
extends book extends library...), and it is not possible to inherit two
classes.

Thanks for a hint!
Markus

[Markus Ernst]

Jerry Stuckle wrote:

[...]

But herein lies the problem. Inheritance is not applicable here. A
text element is not a "type of" a page. Rather, a page "contains" one
or more text elements.

A biography is a "type of" a book, so it would be applicable to derive
biography from book. The book also "has an" author, but the author is
not a "type of" text element (or vice versa).

[...]

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). 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
....

The main properties of entity are id, parent, active/inactive and sort
order. So for all kinds of common tasks - handle sort order,
activate/deactivate display... - I have one method at entity level, and I
can flexibly handle all kinds of 1:n relations at entity level by assigning
the id value of one object to the parent value of another one, regardless of
what type the objects are of.
So I can assign a page not only to a rubric (which is the natural container
for pages), but also for example to an author. Or assign a text element not
only to a page (which is the natural container for text elements), but also
to an author. Like that I can reduce the author data record to the very
basic - name, picture, contact information... - and still freely add
additional info where appropriate.
Of course n:m relations such as the product/author relation are handled
separately.

[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.
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

[Hilarion]

> entity -> rubric -> page [1]

entity -> contents element (such as text or picture or text and picture...)
Why not something like that:

entity -> contents element -> rubric
entity -> contents element -> page
entity -> product category
entity -> product -> book
entity -> product -> cd
entity -> product -> postcard
entity -> author
...

The main properties of entity are id, parent, active/inactive and sort
order. So for all kinds of common tasks - handle sort order,
activate/deactivate display... - I have one method at entity level, and I
can flexibly handle all kinds of 1:n relations at entity level by assigning
the id value of one object to the parent value of another one, regardless of
what type the objects are of.
Do you need such general way of referencing? If you do not know the nature
of referenced entities, then the reference is (almost) useless.
So I can assign a page not only to a rubric (which is the natural container
for pages), but also for example to an author.
To assign rubric as a part of page you should build collection "visually contains"
of content elements in content element class.

Or assign a text element not only to a page (which is the natural container
for text elements),
As above.

but also to an author.
What for? If the text has an author, then make "author" property in content
element class (from which text element should probably be derived).

Like that I can reduce the author data record to the very
basic - name, picture, contact information... - and still freely add
additional info where appropriate.
By the ways above you could also do it, but without mixing things.

Of course n:m relations such as the product/author relation are handled
separately.

[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.
Why do not do it on contents element level? This way many content elements
could have subelements. You could also make more levels of inheritance
by doing it like this:

entity -> contents element -> text element
entity -> contents element -> contents collector -> rubric
entity -> contents element -> contents collector -> page

And create "visually contains" collection of contents elements in contents
collector class and this way separate simple elements (which do not
contain other elements) from complex elements (like rubrics or pages).
The ordering mechanisms would appear in the collection (so on contents
collector class) and rendering mechanisms in contents element class.

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.

That should be a bit better. The administrative hierarchy could be
related to logical hierarchy (class responsible for persistance of rubric
class could inherit from class responsible for persistance of contents
collector class or it could contain reference to instance of such class).
Hilarion

[Jerry Stuckle]

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_eleme nt". That way you can
derive both "rubric" and "page" from "contents_eleme nt". Both will be
of the "contents_eleme nt" 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.
js*******@attgl obal.net
=============== ===

[Markus Ernst]

Jerry Stuckle wrote:

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).

Thank you - this is really good to know, as it helps deciding where to look
for optimization potential.

I highly appreciate your input as well as Hilarion's and Chung's, they
helped me gain a better understanding of OO and improve my work.

--
Markus