Class design like I'm using Java

[ecastanedo]

I want to be able to "package" the system enough to where plugging it in to a site that has a different look and feel to it is not very hard.

Just as we thought this thread could not get any more complicated, I think I will throw another dimension into the mix? Have you ever thought about using UML to design your system? It sounds like what you may need to do is take a step back and really think about this framework which you seem to be putting together. I don't mean that you have to use UML, but I do see a need for your project to be thought out if your goal is reusability.

You will not be able to include all scenarios in version 1 of your framework, but you may be able to iron out just enough of the wrinkles in order to make it work for most of your projects. This is what projects like Jakarta Struts have been designed for.

The reason that I bring up UML or even just a paper and pencil approach is because sometimes it helps if you first write out all of the objects or code modules that will be involved in your application, be it object-oriented or procedural. Looking at your application as a picture may clue you in to its complexity or simplicity. It may also give you an idea as to what approach you may want to take (i.e. OO or Procedural).

Just as there are many religions in the world, there are probably just as many programming languages. They all have different belief systems. Which you choose is entirely up to you. There are even those that have mixed and matched, in order to make it work for the individual.

My advice is to learn as many ways of doing things as possible. Then take the best out of all of those and use the ones that makes sense to you on a case by case, or project by project basis.

[DougBTX]

I think Hartmann's Requirement 2 was a little too far afield. Let's say Requirement 1 was get an item (all I would want added to the code above is to be able to get a quality). Then Requirement 2 should be add an item.

And then naturally: Requirement 3. Remove an item

BTW: is this "Class design like I'm using Java" or just "Class design"? My Java skills are limited, so I can't really tell.

Douglas

[lastcraft]

Hi...

So we have a customer, we have a cart, we need to model the different aspects of what the customer can do.

Yes. Let's visualise for a moment. Our customer is the developer who is about to use our cart library to build their web site. Let's sit down next to them and think through what they want. Some random thoughts...

They will make calls to our classes, instantitiate our classes, subclass our classes, edit our templates or use their own. They are also in a hurry and will want to see something working quickly. The developer will write all of the glue code that combines components together. They also need all of the business decisions to be under their control, either by direct calls or their own subclasses.

They already have a customer class and they probably don't want to rewrite a lot of it, hence an intermediate object. If they have to subclass an object you need to keep the base class as simple as possible so that there is no invisible code to figure out, hence why interfaces are prefered. I can think of two points of contact with the customer, the destination address and a confirmation email address. The destination is data only and so easy to explain.

A more interesting one is the sending out of e-mails, because that mechanism could be system dependent. It might even be text messages if the target audience is mobile users. Are we responsible for sending (templated) messages? Or do we push that out and leave it to the developer? Just a yes or a no (you can change your mind later).

Such as billing. Do we handle that as an object? I mean, it really is a very small piece. Basically it covers all of the billing information per customer. I am guessing that this functionality could be done in the Customer class.

An application writer will already have some kind of payment gateway set up. I think that's the subject of the glue code, not us. We have to supply sufficient information so that the developer can extract it at a timely manner.

When you say it's tiny, what do you see it doing?

What I am thinking next is maybe the items/products that need to be displayed. A product has an image, description, price, etc. tied to it so all of those things need to be displayed.

Most template engines send hashes of substitutions to the template painter. If we have a CartView class (us only) that gets it's data from an ItemView (developer can subclass) then when the developer goes...

$substitutions = $view->getSubstitutions() 

They can merge it into the rest of the data for that page. We would supply some default templates using a simple engine (Savant say) or a popular one (Smarty), but lexposing flex points so that they can change their minds.

I am basically inventing these possible scenarios...
1) Developer writes glue code and uses default template.
2) Glue code and hacks our template.
3) Glue code and adds their own page stuff to our template (or subclasses ItemView).
4) Glue code and takes bits of our template and plugs it into theirs.
5) Glue code and uses their own template engine.
6) Glue code and skips the ItemView altogether, just accessing the Item accessors.

We need...

class ItemView {
    function getSubstitutions() { }
}

class CartView {
    function CartView(&$cart, $view_class) { ... }

    function getSubstitutions() {
        $substitutions = array();
        $balance = $this->_cart->getBalance();
        $substitutions['balance'] = $balance->asString();
        foreach ($this->_cart->getItems() as $item) {
            $class = $this->_view_class;
            $view = new $class($item);
            $substitutions['items'][] = $view->getSubstitutions();
        }
        return $substitutions;
    }
} 

If you don't like the class name hack then a factory object can be passed in instead.

I want to be able to "package" the system enough to where plugging it in to a site that has a different look and feel to it is not very hard.

I have punted at what I think you want. Do you have a scenario that breaks the above scheme? Is it too complicated?

yours, Marcus

[Hartmann]

lastcraft,

It's not that's too complicated. I think it is great and easy to understand. My hangup now is deciding if it is really what I/the people I work for want to do. The thing I am trying to work towards is using this system as a base for others, which, I think that you have done. So if I build this abstract enough I can instantiate a new Cart object in my code and then call it's methods when I need them. My question is, should these classes and their methods generate HTML or should I call the functions that display the values in my already built HTML?

How much do we seperate PHP from HTML? At what point do we use templating systems?

It's just a whole lot to digest.

[Hartmann]

And then naturally: Requirement 3. Remove an item

BTW: is this "Class design like I'm using Java" or just "Class design"? My Java skills are limited, so I can't really tell.

Douglas

Doug, the reasoning behind the thread name was that my original post was to know how much "abstraction" I should use in designing my classes. Since I am coming from a Java background I have a very heavy reliance on using methods for doing very specific tasks.

Anyway, I guess the thread name could be changed now though.

[hantu]

It's good that this thread transformed from a theoretical war into a practical discussion

I just want to add a theoratical point that IMHO has been missed:

To model a class with get* and set* accessors (like the initial question was) matches the concept of a Java Bean.

AFAIK Beans were invented to give the programmer the ability to deal with classes of which the implementation is not initially known.

Everything that needs to be accessible as an "attribute" of the object has to have a getter method.

Remember: a class could have member variables that shouldn't be accessible (you won't have to care about that with PHP5) or "attributes" that consist of the state of more than one member variable. That's why direct access to members doesn't give you enough possibilities.

Using Reflection, you can do a lot of things generally with unknown "Beans" and therefore you won't need to write code for each class taking part in a certain activity. I've been told that this was the main cause for the invention of Beans.

For example I use bean-like classes and a Reflection in a lot of ways, some simple examples:

You can auto-generate forms from beanlike classes

...

$methods = get_class_methods(get_class($myBean));

foreach($methods as $method) {
  if (substr(0,3, $method) == 'get') {
    $attribute = substr(4, strlen($method), $method);

    $myFormObject->addField($attribute);
    $myFormObject->setFieldVal($attribute, $myBean->$method());
  }
}

... 

You can easily populate beanlike objects from database query results given as arrays in a similar way and I think O/R Mapping uses similar Reflection methods to persist objects.

[arborint]

How much do we seperate PHP from HTML? At what point do we use templating systems?

I think lastcraft and DougBTX have showed very nicely how to create small focussed pieces of code that each do a clearly defined job. If you look at DougBTX's post #59, it is at the level of BalanceSheetView that you would preferrably use templates instead of imbedded HTML.