To all OOP eggheads out there. I need A bit of design help

[Angelos]

First of all I need to thank you in advance...
Now I 'll try to show you what I want do and if you can, tell me how My
class should be composed.

I have a CMS. I add content and that Content can be Published
Unpublished and Backuped. Now the content has Several Types like...
pages,news,products.

I am trying to write a class Content that will cover the common bits
that Several Content Types have and the rest will be inherited.

But I don't know how I am going to create different Contents based on
the fact they are Published Unpublished and Backuped. Those three in the
database are different tables.. Published and Unpublished is exactly tha
same table. has a backup_id as a primary key and thats the only
difference from the other two tables... (No I don't want to have
published and unpublished as a boolean)

I was thinking if it is possible to add arguments on the constructor...
so I will have

class Content {
function Content(category='unpub') {

}
}

do you have any Ideas... ? Can someone give me a rough idea of how my
class should look like (constructor, the important functions that will
interact with the 3 DB tables)

Thanks A lot...

[A. Timurhan Cevik]

You can try abstract factory pattern to create the content.

Such as, you have an abstract factory class for the content
class Content(){}
class PagesContent : Content()
{}
class NewsContent : Content()
{}
class abstract AbstractContentFactory()
{
public abstract function returnNews();
...
}
class PublishedContentFactory : AbstractContentFactory()
{
public function returnNews()
{
news=new NewsContent();
news.status='Published'
return news;
}
}
class UnpublishedContentFactory : AbstarctContentFactory()
{
public function returnNews()
{
news=new NewsContent();
news.status='UnPublished'
return news;
}
}
and such. By this design, you can add new content and have classes
based on content and keeping publish status.

Another design would be keeping the publish status in a different class
and associating the content class with this class, if methods would be
the same for all content types.

[Angelos]

A. Timurhan Cevik wrote:

You can try abstract factory pattern to create the content.

Will that work on PHP 4 ? or it needs 5 ?
I am working on 4.something...
I'll have a look anyway at your suggestion

[C.]

Like any database driven program you should start by defining your
schema - i.e. normalise your data. I'm forever finding people whom have
been nitten by the OO bug trying to use persistence as a way of storing
their data - trust me it's a very bad starting point. Trying to fit
your objects and impose persistence on top of an existing schema is a
very bad way to do things.

Assuming that Published, Unpublished and _Backed-up_ are mutually
exclusive and the item must be in one of these states then there should
only be one logical table. These are states of the item (not
properties).

If you can't fix your database schema then using the base class to
abstract the error seems like a good solution.

If there is adequate polymorphism in a relation then WTF do you need to
create derived classes to describe different content types?
C.

[A. Timurhan Cevik]

Like any database driven program you should start by defining your
schema ?
Thats not the way to oop. Never do that, if you plan to program oop.
Sure, you should do it, but if you are procedural programming or you
lack skills to construct an oo program.

I dont think I made that strong enough, do not start by defining the
schema if you are into oop. Simply do not.

In oop, business layer is business layer. Not the database layer. So,
you should keep your business objects out of persistence code. Doing
not so, makes your code tough to be reusable, encapsulated and such.
Persistence should be handled AFTER the business objects are
constructed and proven to be running good.
It would hurt too to Unit test these classes.
Sure, there are objects that handle persistence. Sure, you can make an
object for each table on your database (Active Record pattern or smth.)
but, that application should not be a big application, if it is, then
you will be making a lot of maintanence, bug fix during the project
lifetime, trying to complete it and trying to change it to meet the
requirements afterwards.

Software change. You should not make it unchangable. So, you should
design it such that changes in layers should affect other layers as
minimum as possible. Highly couling the database schema and the class
structure, you will be violating that.

[A. Timurhan Cevik]

that is 5 sorry. If you are thinking bout oop, my advice is not to
continue with php 4 and upgrade your current project code to php5. At
least, make it run at php5.

There are just not enough features in php4 to write a full oop program.
A little bit of procedural and a little bit of oop, that would be.
Which is always nearer to pp.

[Angelos Devletoglou]

Hello,

A. Timurhan Cevik wrote:

Like any database driven program you should start by defining your
schema ?
Thats not the way to oop. Never do that, if you plan to program oop.
Sure, you should do it, but if you are procedural programming or you
lack skills to construct an oo program.

Ok I see you know what you are talking about and I agree with you.
My problem you see is that At the moment I have a working application
but it is writen in a procedural way and ofcourse I short of have the
database ready... The good thing is that I don't want to migrate
anything from the old system so I start from scratch.

Now if describe you once more my case... would you be able to find me a
solution in the design and how can I simply interpret it in
programing... It is something that I have to have it before christmas
and that makes me nervous...

If you have some time read the case below again otherwise thanks a lot
for your help until now ;)

PHP4 I can't change that.
So here is the case again in parenthesis I will write how I interpret
them in programming:
A content(class) management system will be able to let registered
users(class) to add/edit/delete/publish/unpublish and
restore(content:methods) content.
When the content is added it will be unpublished. Then the user will
publish it. If the content is been edited it, the original version will
stay published but the new version will go be unpublished. Once the new
version is been published the original content gets backuped and the new
gets published.
We can have any type(content:attribute) of content, starting from
Pages,News,Events to Products and Photos.
************************************************** ***************************
Now that was sort of my case. Can you tell me how would you design the
application and your database ?
And how you would interpret them in very very brief code(Keeping in mind
the PHP Ver4.X.X).

Thank you...

[A. Timurhan Cevik]

hmmm... As I stated earlier, oop lacks important concepts in php4 and I
dont remember which was included in php4. So, I will not be able to
give you an oop solution. But using simple classes,
- class user
- class ContentContainer
{
var $contentType;
var $published;
var $unpublished;
function ContentContainer()
{
$this->published=new Content();
$this->unpublished=new Content();
}
function Publish()
{// Some business stuff here, maybe database functions
$this->published=$this->unpublished;
}
function Restore()
{
$this->unpublished=$this->published;
}

}
class Content
{
var $Body; // or smth.
var $User;
function Content()
{}
}

I prefer using some ContentMapper class haivng a content attribute for
doing the database stuff, related to a ContentContainer class,
responsible of retrieving the published and unpublished content from
persistence.

The system could evolve much more, keeping track of user behaviour on
the content, the publishment and editing history etc. Alas I dont have
more time to exercise on it more. I know I did not give you a
fascinating solution, but could give you an idea.

By the way, if you would like to use file locking, file based role
based permission setting, versioning and such, I recommend you to look
at WebDav (some contentmanagement low level framework that also has
methods built on top of http like adding put to standart get/post http
methods and being able to reach the repository using Dav:// or smth.)

[Angelos]

The system could evolve much more, keeping track of user behaviour on
the content, the publishment and editing history etc. Alas I dont have
more time to exercise on it more. I know I did not give you a
fascinating solution, but could give you an idea.

Your reply was more than helpfull thanks a lot Cevic.

Angelos.

[FluffyCat]

On 2 Dec 2005 12:47:02 -0800, "A. Timurhan Cevik" <at*****@gmail.com>
wrote:

that is 5 sorry. If you are thinking bout oop, my advice is not to
continue with php 4 and upgrade your current project code to php5. At
least, make it run at php5.

There are just not enough features in php4 to write a full oop program.
A little bit of procedural and a little bit of oop, that would be.
Which is always nearer to pp.

I agree with Cevik on this. If you want to redsign your system in PHP
using OO you would be crazy not to use PHP 5. If you use PHP 4 you
will be handicapping yourself unnecessarily for your current CMS
project, and then you will have some more unnecessary work when you do
eventually upgrade that CMS to PHP 5.