First Steps in OOP (n00bs digest)

[arborint]

Not sure what you are trying to do, but it looks like a Form Controller. Building a good Controller architecture is not that easy, but go for it. All of these:

    var $loginForm;
    var $searchForm;
    var $clientSelectForm;
    var $divisionSelectForm;
    var $categorySelectForm;
    var $clientForm;
    var $divForm;
    var $dealerForm;
    var $dealerAddForm;
    var $dealerEditForm;
    var $catForm;
    var $productForm;
    var $productAddForm;
    var $productEditForm;
    var $orderForm;
    var $orderViewForm; 

would be separated and hopefully at a minimum would have a View and Model class for each.

[mx2k]

sorry i'm probably late in posting this,

back to use cases, admin and user are two different 'actors' which require different cases, however if you wish you could diagram the actors and cases and show how they relate.

as for forms, its great to have a way to check if any fields have been posted, however
it also helps to add javascript validators to the form so that the user doesn't have to keep submitting in order to fix mistakes.

to an above post, i've never had the submit issue with IE, but i wonder how many othe r people have?

[melancholic]

Hi there,

Not sure what you are trying to do, but it looks like a Form Controller. Building a good Controller architecture is not that easy, but go for it.

To be quite honest with you, I'm not exactly sure on what I am trying to do. I am just moulding objects to my needs following the five basic principles of OOP stated in Thinking in Java by Bruce Eckel.

- Everything is an object
- A program is collection of objects
- Each object has it's own memory made up of other objects
- Every object has a type
- All objects of a particular type can receive the same messages

So I have a static god class that instantiates the database class, the page class and the formwriter class.

If the form is submitted, the static class calls upon the processor class and feeds it information gathered from the form submision.

On the front end scope I have a user class which utilises a session class

The database class is lended to the form writer and form processor classes

As you can see it's still a little more structural rather than role based, so I'm going to refactor to try and do it the way

would be separated and hopefully at a minimum would have a View and Model class for each.

That sounds like a direction that I would like to take arborint, can you guys give an example as to how you'd use the MVC pattern on one of the listed classes above? say... "$productEditForm; " - it would help greatly.

I've read up on existing discussions, but most of them end up in a debate about what the controller's domain is. So it is quite unclear for me.

back to use cases, admin and user are two different 'actors' which require different cases, however if you wish you could diagram the actors and cases and show how they relate.

I see what you mean. Thanks for confirming.
The use case diagrams provided on the net had confused me a little. Thanks for clearing it up. It was always a hang up, when I was trying to translate it into something useful.

[melancholic]

heh, just came accross something :P

25. Watch out for “giant object syndrome.” This is often an
affliction of procedural programmers who are new to OOP and who
end up writing a procedural program and sticking it inside one or
two giant objects. With the exception of application frameworks,
objects represent concepts in your application, not the application
itself.

I should have read this before I wrote the classes. It's going to be a pain to refactor the mofo'!

[arborint]

That sounds like a direction that I would like to take arborint, can you guys give an example as to how you'd use the MVC pattern on one of the listed classes above? say... "$productEditForm; " - it would help greatly.

A web form is a straightforward MVC problem.

- You have code that deals with manipulating, reading and saving data in a database (or to be emailed, etc.): that's the Model;

- You have the HTML and any code that generates HTML or fills in the HTML with the data from the Model: that's the View;

- You have the Controller code that has three basic states:
1) first time in, get the data (or blank),
2) form submitted but errors, so show error messages and redisplay,
3) form submitted, everything ok, save the data and forward

And finally, smart people before us have discovered that if the Model doesn't depend on any code in the View and Controller, and if the View doesn't depend on much code in the Controller, then the system is easier to change.

So first separate your Model code and then try to seperate the View from the Controller as best you can.

[melancholic]

whoa...

...just like that?

You must spread some Reputation around before giving it to arborint again.

You have my thanks, I'll get cracking and post what I come up with.
Your explanation definitely lights the way ahead!

[melancholic]

A quick question - on some examples of MVC, I've seen references to "dispatcher" objects...

what's a dispatcher object do?

[sweatje]

Chooses an object among many choices, and executes a method of the object. AKA, the Comand pattern. It is called dispatching because you are handing over execution of the flow of your program to that object. As a strech analogy, if any particular run through your code was a "rider" and each command was a "taxi" then the dispatcher would select the appropriate $taxi->transport($rider)

[melancholic]

Thanks j.e.sweat, I appreciate the explanation... I'm sure it will make more sense to me down the track...

After reading up on MVC, I've seen that ppl are confused (and still are confused) about it. Some are arguing that it's like fitting a square peg into a circle port and just cutting off the edges to make it fit.

But by doing so leaves gaps.

Considering that I've just gotten my head around such things, is it a good thing that I dive right into MVC?

It's just that I feel another case of "Analysis Paralysis" coming on...

[arborint]

After reading up on MVC, I've seen that ppl are confused (and still are confused) about it. Some are arguing that it's like fitting a square peg into a circle port and just cutting off the edges to make it fit.

People aren't confused by MVC, they are resistant to its premises. The core of MVC is the layer separation between the Model and the Presentation (View + Controller). That separation is proabaly the most important thing a programmer can do when designing an application.

The problem is that separating the Model and the Presentation is hard work and requires experience to achieve. Most programmers (including myself) naturally fall back to Transaction Scripts because they are easy to code up front. The benefits of Model/Presentation separation become apparent as you maintain more code. Code that implements this kind of separation also opens up possiblities for more sophisticated designs without requiring equally more sophisticated maintanence.

Quite honestly in PHP if you maintain Model/Presentation separation and use a Template system you are coding using MVC (whether you like admitting it or not).

[melancholic]

Ahh understood. Thanks again aborint. I'll be mindful of such things.

I'll guess I'll be working on gathering experience for now heh

[arborint]

I'll guess I'll be working on gathering experience for now heh

You and me both!

[sweatje]

Good judgement comes from experience...
unfortunatly, experience usually comes from poor judgement.

[melancholic]

Good judgement comes from experience...
unfortunatly, experience usually comes from poor judgement.

lol well said, life's funny like that, you only get better by making mistakes. It's said that the wisest people have made - or is witness to - many mistakes.


I'muh go make some more mistakes
lol

[melancholic]

I had an amusing short conversation with a friend of mine regarding object oriented programming.

she explained a few things regarding how she uses OOP using java.

I asked about patterns and she said she's never used them at all...

me: "but you DO know about them right?"

her: "yes, of course... but I never use them..."

me: "why not?"

her: "It over complicates things... needlessly... you don't need to worry about stuff like that at all... if all you're really trying to do is get data out of a database and displaying it and providing an interface for people, just keep it simple, there's no need to complicate things at all..."

me: "ok simple eh? right, so when would you use patterns?"

her: "I don't know, when you're building a ROCKET?!"

[Manor]

me: "but you DO know about them right?"

her: "yes, of course... but I never use them..."

me: "why not?"

her: "It over complicates things... needlessly... you don't need to worry about stuff like that at all... if all you're really trying to do is get data out of a database and displaying it and providing an interface for people, just keep it simple, there's no need to complicate things at all..."

me: "ok simple eh? right, so when would you use patterns?"

her: "I don't know, when you're building a ROCKET?!"

I think that's true to a degree. If you just want to display some simple db info, patterns can over complicate things. That is because such simple problems don't require such a pattern as a solution. Remember that OOP + patterns are there to make life easier for you, if you use difficult patterns in such an easy situation like that, they only give you headache when it is not nescesary.

On the other hand, if you are working on a more complicated problem, and you can see how a pattern fits a problem are facing, using the pattern is the most effective, and even simplest solution you can use. For example, imagine that you are having trouble with a design, and you see that the composite pattern tackles this problem very well. Using the pattern in that case is really simple, it fixes your problem, and is a lot easier then if you would be forced to design without the pattern (that would probably result in a solution harder to understand, and more difficult then a pattern fitting the problem). Plus, the pattern is known for a elegant solution, so therefor it seems an excellent, and again, simple choice.

[melancholic]

Hi everyone,

Apologies for letting the thread idle for a while, things have been extremely busy.

After building a few projects in OOPHP I've come to a basic understanding of how it all works together.

I've made some REALLY big mistakes and yes, as much as I regret to admit it - if anyone who is well versed in PHP takes a look at the first application that I've built using OOPHP the words "what a hack" would escape their lips.

So the first project developed was as expected. I developed an application using a structural decomposition with classes like:

"FormWriter" - which encompasses all form HTML

    $formWriter = &new FormWriter(); 

"FormElements" - abstracts HTML for form elements either composed or aggregated by formWriter class.

    $formElements = &new FormElements();
    $formElements->setText("fieldName","text","this is going to be a nightmare"); 

"FormProcessor" - which encompasses all form processing for the application

    $formWriter = &new FormProcessor($_REQUEST); 

As one can imagine, the classes were bloated. for each form that was created, there had to be a method in both formwriter and formprocessor classes.

I decided to add a new function and it was so convoluted that parts of the application stopped working.

Adding an extra field to a form meant that I had to look at the two super classes for the specific methods and make changes there - expected thrashing was experienced. It was hella painful.




Anyway... here's a summarised solution for the initial problem:


- Request Class - collates $_GET and $_POST variables and cleans them up for use.
- Email Class

// modified classes from harry fuecks book.
- MySQL Abstraction class
- MySQL Query class

- User Class - properties consist of details including access levels and personal details
- UserDao extends MySQL - is composed by user class

- Jobs Class - has the details for each job as a property and a list in text or HTML format.
- JobsAdmin extends Jobs - has additional display options for administrators
- Jobs Dao extends MySQL - is composed by jobs class

I've avoided using template classes and the like and used include files for the front end.
I'm still at a stage where I am using a page for each script for this project, I've got

index.php

<?php 
require_once("../conf/config.inc.php");
require_once("../class/request.class.php");
require_once("../class/mysql.class.php");

$request = &new Request($_GET, $_POST);
if (!empty($request->get("loginkey"))) {
    $user = &new User($request);
}
require_once("../templates/login.tpl.php");
?>

jobs.php

<?php 
require_once("../conf/config.inc.php");
require_once("../class/request.class.php");
require_once("../class/mysql.class.php");

$request = &new Request($_GET, $_POST);
$job = &new Job($request);
switch ($request->get("display")) {

    case "joblist":
        $job->setListHTML();
        $jobTable = $job->getListHTML();
        break;
    case "job":
        $job->setJobHTML();
        $jobTable = $job->getJobHTML();
        break;
    default:
        header("location:".SITE_URL."jobs.php?display=joblist");
        break;
}

// jobs.tpl.php echos the $jobTable variable.
require_once("../templates/jobs.tpl.php");
?>

Down the track I'll be experimenting with using a controller class that intrinsicly makes the decision on what to display.
It's all just a matter of finding the time and inclination to do it I suppose.

I've also been trying to get my head around Test Driven Development. Where do I start? It's a concept I am finding hard to get a grasp of.

At which stage of the app design/development process do I decide to write tests?
But then again, I'll be looking into it later, when I've got a complete grasp of how OOP works.

Here's a few immediate questions however:

- Is there a better way to do this?
- Am I heading in the right direction?
- Should I have structured my classes differently?
- Have I made any fundamental app design errors?
- Does my snobbing off templating systems work for or against development?

Thanks in advance,

'cholic

[Ezku]

As a strech analogy, if any particular run through your code was a "rider" and each command was a "taxi" then the dispatcher would select the appropriate $taxi->transport($rider)

That isn't streched at all. You make a call to order a taxi at your door ($rider is passed to $dispatcher). A taxi is sent your way (appropriate Taxi is created). The taxi picks you up ($taxi->transport($rider)). Isn't that a perfect analogy?

[sweatje]

That isn't streched at all. You make a call to order a taxi at your door ($rider is passed to $dispatcher). A taxi is sent your way (appropriate Taxi is created). The taxi picks you up ($taxi->transport($rider)). Isn't that a perfect analogy?

Holy resurected threads Batman! I didn't even remember writing about that