First Steps in OOP (n00bs digest)

[been]

If you can't wait for payday, you might want to take a look at Bruce Eckel's "Thinking in Java", it's free for download

[Dr Livingston]

Umm...

Thanks for the inspiration Melancholic, I didn't think I was in that high a regard Sometimes I have a brain drain when it comes down to putting down the roles and responsibilities of classes, and this is the difficult part as I see it (to me anyways).

But the more you do design, you have more experience to question your design in regards to class naming for one, but the messaging between the classes, if that's an acceptable phrase? ie Communication

What I can advice is that what I'm seeing more and more is that Unit Testing is helping me a lot more than what I was doing, without it yes? I can sit down and get a rough idea of what I have in mind.

Then I try to compose some responsibility to those classes via Unit Testing. I find that if I need to pass in an object to a class, to allow it to communicate via this class to another class (eh?) I may need to rethink the design?

But I'm still learning as well, btw I would recommend you buy, borrow, beg or steal a copy of Domain Driven Design (Evans) which I'm reading at the moment. For me I need to read a book 2/3 times to get a general idea of things, but I it helping me a lot, in the sense of breaking down a requirement into roles/responsibilities.

[melancholic]

Ok...

Here's a list of books I'm planning to purchase:
- Refactoring
- Domain-Driven Design
- Patterns of Enterprise Application Architecture
- Thinking in Java

<edit>
Damn what a load of crap I had put up... Ok so suffice to say that I went and studied a little and found out that I was again just touching on the tip of the iceberg...

Made some notes, they were at best Jibberish a summary of the history of programming languages and methods and how they've come about - very basic but extremely new to someone like myself who did not come from a programming background.

My research has led me to UML which has led me to OOA&D (yes in that backwards order).

I've applied the software design process and have read up on patterns... Although I still don't understand completely how it all fits in together.
</edit>


Regards,

'cholic

[melancholic]

Taking it back to the start again... the OO Analysis Phase:

What does the application do?

- The timesheets application displays a list of tasks performed on projects during a working day

- The way the timesheets are displayed can be changed through the use of dropdown box elements

- Users can login, logout, add, edit and delete their own activities on projects.

- An Administrator can login, logout, add, edit and delete projects, users or clients.

- An Administrator can view all jobs

- The application will be using a MySQL database as it's data repository


a rough draft of candidate classes in package "timesheets":

- timesheet
- users
- administrator
   - clientManager
   - jobManager
   - userManager
- projects?
   - tasks?
- forms
- database
   - queryResult

I'm now doing some research on OOA&D and still have not read any of the books I've listed above - a web developer who is very much into procedural/modular ASP1/PHP and very much against OOP is saying that in this whole time I've been messing around with OOP, I could have built the whole thing in procedural... just to taunt me, he's built one for himself

But this is not the point of course. I want to learn this approach so that I have a more complete understanding of PHP.

I know this is somewhat the long way, but I want to understand things and do it the "right" way rather than the "fast way"

regards,

Melan'

[melancholic]

i) I've drafted a more complete list of requirements and currently researching on how to use Use Case diagrams...

I'll put the list up in the next few days.

ii) I'm using argoUML to do my Use Case diagram(s) - haven't started yet.

iii) After doing this, I'll be creating UML Class diagrams also with argoUML and use the source code created from there to produce the empty classes.

I feel like I'm slowly understanding the process and it's exciting in a way. Keep in mind also that I started out as a line for line PHP hacker feeding off the numerous tutorials spread accross the internet.

I'll post them up when done...

regards,


'cholic

[arborint]

I'm now doing some research on OOA&D and still have not read any of the books I've listed above - a web developer who is very much into procedural/modular ASP1/PHP and very much against OOP is saying that in this whole time I've been messing around with OOP, I could have built the whole thing in procedural... just to taunt me, he's built one for himself

Well your buddy probably has a point that OOP is not for him. And it may not be for you. Your design is still procedural at its core.

lastcraft noted a brilliant observation by one of his associates recently (which I will probably badly misquote) that OOP is not about the code -- it's about the connections between the code. Every program that does a thing has to do essentially the same steps. The question is how those bits of code get connected together. And it is the connections that determine how flexible and testable code is, not necessarily the code itself.

[melancholic]

Hi there,

Well your buddy probably has a point that OOP is not for him. And it may not be for you.

Now, now... don't lose faith just yet

I don't think it could really be said that a design approach is for or not for anyone. For me, I see it in a way that it's all in about understanding the approach.

For instance, one child could learn to ride a bike without any help or anyone showing him/her how to do so with no problems whatsoever, while another would need 6 months on training wheels, other kids go to bike school to learn how to ride a bike and develop a more methodical approach to balancing on two wheels

I don't think that it's a "you're either made for OOP or you're not" scenario

<edit> deleted chatty crap </edit>

I'll get a grasp of OOP soon enough... it's only just a matter of time.

lastcraft noted a brilliant observation by one of his associates recently (which I will probably badly misquote) that OOP is not about the code -- it's about the connections between the code. Every program that does a thing has to do essentially the same steps. The question is how those bits of code get connected together. And it is the connections that determine how flexible and testable code is, not necessarily the code itself.

That's exactly where I'm headed... I hope.

...Your design is still procedural at its core.

Hey, thanks for the feedback, that's the kind of stuff I'm after.

Some questions though:

i) When you say that my design is still procedural at its core, can you point out exactly where it is? take my last example for instance...

Why is it still procedural at its core?

I have my hunches as to why in a sense, that the objects are not real-world models but more like part of the program - but I'd like to hear it from you.

ii) Going back to what you and the other guys have said a bit about role based compositions...

I can see now that what I'm making are modules, which is how I currently code my procedural projects.

But what is confusing me is that there is a need for the database class which in itself is does not have a role in the same respect as the other classes would.

Unless of course, that's considered to be on a data access layer and is to be considered a special case because it's purpose is to abstract the database?

iii) Finally, how does "user" or "task" classify as a good candidate for a class where "form" would be a bad candidate? or are they both good?

Thanks in advance!


regards,

melan'

[Dr Livingston]

Umm...

From the last known example I found you posted, you have this part...

...
$this->id = $this->userinfo[0][1];
... 

Instead, I would have something like this

...
$this -> req -> setSession( 'id', $person -> getId() );
$this -> req -> setSession( 'username', $person -> getUsername() );
$this -> req -> setSession( 'password', $person -> getPassword() );
... 

Where $person is an object that has the information you've pulled out of the database, based on what login details have been submitted from a login form. This is 'more' OOP than your example, and is the way it is done by most people using OOP.

Hope that helps anyways

[melancholic]

Ahh, I see... that makes sense.
thank you DL

[sid egg]

ii) Going back to what you and the other guys have said a bit about role based compositions...

I can see now that what I'm making are modules, which is how I currently code my procedural projects.

But what is confusing me is that there is a need for the database class which in itself is does not have a role in the same respect as the other classes would.

Unless of course, that's considered to be on a data access layer and is to be considered a special case because it's purpose is to abstract the database?

The main reason, in my opinion is abstraction, however, another good reason is that it does fit the "Is a" approach. See this example:

$db1 = new Database("localhost", "user", "pass", "user_db");
$db1->query("asdfasdf");
// ....
$db2 = new Database("localhost", "user2" //...
$db1->query("asdfasdf");
$db2->query("asdfasdf");


See how it is treated as an object? How you can have more than one, and they are queried? In essence it is an object.

iii) Finally, how does "user" or "task" classify as a good candidate for a class where "form" would be a bad candidate? or are they both good?

Form is a great one! I use form for everything! I based my form class off the Mambo ones so you use them like this:

$login = new Form("login", "login.php", "POST"); // ... Form has many inherited parts, inherited versions usually just overload render();
$user = new Text("user", "Username:", 50, 70);
$pass = new Text("pass", "Password:", 30, 50, true);
$login->addFormElement($user);
$login->addFormElement($pass);
echo $login->render(); // loops through all the elemnts, and calls their render member in it's respective location 

[melancholic]

The main reason, in my opinion is abstraction, however, another good reason is that it does fit the "Is a" approach. See this example:

I've come accross some article on the net that says that it's part of the system and should not be considered as a role. Roles are filled for things are outside of the system scope such as users and catalogue systems.

I guess the same can be thought of the form class in the same respect. It's part of the entire system so it won't be considered as a role.

regards,

mel'

[Dr Livingston]

Use cases I believe can help clarify what a role is or not. A role for example, is a login - not the process of logging in, just the 'login' from what I can make out of it

Another use case/role could be clicking on a shopping basket for example.

[melancholic]

Great! then I know that I'm researching the right subjects.
Use cases is what I've been reading up on for the past day or so

I have the following use cases for the system I'm developing:

- User logs in to system
- User manages tasks
- User logs out

My actors consist of the user the tasks system and administrator (or should it be administration system?)

I'm pondering on whether I should create an administrator role as a generalisation of the user actor...

Actor: User -------------------------- Use case: Log in
       A
       |
       |
       |
Actor: Administrator ------------------ Use Case: Manage clients/users/tasks

I'm also unsure if both the administrator and the user should be on the same diagram since they are essentially on different use cases... What's the standard practice with use case diagrams anyway? does it have to all be on the 1 diagram?

meh, I dunno... I'm taking in some information that i know that will be relevant to the requirement gathering process, but there's too much uncertainty with regards to whether or not I'm going the right way

thanks for feedback Dr, always appreciated.

[Dr Livingston]

I'm just starting out much like yourself so my knowledge is limited

[geniusgoalie]

Wow, this is a great thread for OOP n00bs (like me!). Good job, Melancholic!

[Daimaju]

- User logs in to system
- User manages tasks
- User logs out

I think "User manages tasks" is quite a large/abstract use case, compared to "User logs out", which is one action.
"User manages tasks" could be split into (at least):
- User adds new task
- User marks task as finished
- User edits task
- User abadons task

But i'm by no means a expert in use cases

[melancholic]

Hi there,

I think "User manages tasks" is quite a large/abstract use case, compared to "User logs out", which is one action.
"User manages tasks" could be split into (at least):
- User adds new task
- User marks task as finished
- User edits task
- User abadons task

But i'm by no means a expert in use cases

Thanks for the input.
And of course, you're right.

But I do this down in the Basic flow part of the Use Case analysis.
I start off with "User manages tasks" and break it down afterwards.

[melancholic]

I've had a bad case of "analysis paralysis" reading something, thinking about it, thinking how do I do that?
what next?
why do I do that?
what's the right way to do it?
So I go through google and read through the squillions of articles and found my way from OOP through to RUP, UML etc - software engineering. Most of which I wanted to absorb, but most of which I didn't feel related to what I am after at this point in time.

It was a good thing though, what reading has done for me is that it's made me aware of techniques.
Practicing is what puts it all together.

This is what I've put together so far... between idling with jobs and doing R&D.

I've actually put myself in a rutt. I thought I would have been able to absorb the OOP concept well enough to implement an online catalogue. So with a new project at hand and a somewhat basic understanding of OOP, I tried my hand at it. Halfway through development it's become convoluted. GeeZ!... it was very painful. and still is.

I've done the front end screens and it's taken me twice as long to do it. The deadline is due in a weeks time and I've left myself about five days to do the backend section, which I will do in functional/procedural php for now. I'll recode the messy as heck front end screens from it's hybrid oop/spaghetti notation back to procedural as well when the deadline is met and I can go easy.

Having said that tho', this is what I've got so far on the "timesheets project". It's making a little more sense now.

index.php

<?php
require_once("../class/database.php");
require_once("../class/page.php");
require_once("../class/forms.php");
require_once("../class/loginform.php");

$loginPage = &new Page();
$loginform = &new LoginForm();
if (isset($_POST['submit'])) {
    $db = &new Database();
    $loginform->processForm(&$db);
}
$loginPage->setHeader();
$loginPage->setBody($loginform->getForm());
$loginPage->setFooter();
echo $loginPage->getPage();
?>

it's a little halfbaked but eh... I'd write more, but I'm kinda short of time at this point.


regards,


Melan'

[Dr Livingston]

Hello,

...
if (isset($_POST['submit'])) {
    $db = &new Database();
    $loginform->processForm(&$db);
}
... 

Just a quick refactor I think? Instead of passing the database connection to the form, which I assume then does an INSERT/UPDATE, what I'd do is to pass the validated form data to a separate object instead, which has the database connection already setup, to do the INSERT/UPDATE.

This way, you remove the dependency of the form class having the database connection, which is entirely non related anyways

For example, once the form has finished validating, you'd return the form inputs as an array, or even an Iterator depending on the Interface of the class you have doing the INSERT or UPDATE.

Hope this helps anyways.

[melancholic]

Hi there,

Thanks for reply!

It's a good sign that I've learnt a few things because I actually understand what you are saying

The database is indeed not related to anything - it's part of the system.

I have put some thought into data Validation, but the thing I got stuck with is, is Validation a method of LoginForm class? Or do I make a separate "Validator" object?

Do I do the same with the Form object and make it a Generalisation of a LoginForm one or many subclasses? Would it be wrong if I did it this way?

Will the "Validator" object then agregate the database object or does it compose it's own database object or source for data to match?

"LoginForm is a Form"

current Form class

class Form {
... 

current LoginForm class

class LoginForm extends Form {
...
} 

"LoginValidator is a Validator"

validator class

class Validator {
// database object
// isvalid
... 

OR

class Validator {
// isvalid
...
function connectToSource
{
} 

LoginValidator

class LoginValidator extends Validator {
...
// test data specific to login
} 

regards,


Melan'

[arborint]

if (isset($_POST['submit'])) { 

Not sure if others have noticed this problem, but IE does not send the button value if the user uses the Enter key to submit the form field. The form is submitted but the value of the submit button is not set. My form controller checks a form field to see if the form has been submitted.

[sweatje]

I sometimes use count($_POST) to see if any fields have been posted, but it would probably be better to check specific fields you know you are posting in the form.

[arborint]

The count($_POST) is an interesting idea. Thanks.

[melancholic]

hi, thanks for the tips arb and JEsweat
I'll be keeping them in mind...

I'm in a dillema at this point in time however...

I'm thinking about making FormValidator, FormProcessor and FormMaker classes...

Is this going the right way? Have I gone too far with allocating roles for each part of my initially intended form class?

Should I be doing it more this way?

class LoginForm {

    var $html;

    function LoginForm() {...}

    function set() {...}

    function get(){...}

    function process() {...}

    function validate(){...}

} 

Or... This way?

class FormWriter {

    function write() {die ("please use subclass"); }

}

class LoginFormWriter extends FormWriter {
    function write() {...}
}

class SearchFormWriter extends FormWriter {
    function write() {...}
} 

class FormValidator {
     function validate() { die("Please use subclass"); }
}

class LoginFormValidator extends FormValidator {
    function validate() {...}
}

class SearchFormValidator extends FormValidator {
    function validate() {...}
} 

class FormProcessor {
     function process() { die("Please use subclass"); }
}

class LoginFormProcessor extends FormProcessor {
    function process() {...}
}

class SearchFormProcessor extends FormProcessor {
    function process() {...}
} 

Is one or both the right or wrong way?

please help with feedback.

Thanks in advance

[melancholic]

Hi there...

I've decided to throw myself into the deep end and apply my still developing knowledge of OOP to a "goodwill" project.

I think I've made my first documentable mistake extremely basic form of OOP but it gave me a great insight as to what I've done and how to do it better.

formwriter class (1028 lines of code) - this writes the forms which are used to update an online catalogue I am working on.

class FormWriter {
    
    var $elements;
    var $db;
    var $method;
    var $action;
    var $name;
    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;
    
    function FormWriter(&$db, &$formElements)
    {
        $this->elements = &$formElements;
        $this->db = &$db;
        $this->method = "";
        $this->action = "";
        $this->name = "";
        $this->loginForm = "";
        $this->searchForm = "";
        $this->clientSelectForm = "";
        $this->divisionSelectForm = "";
        $this->categorySelectForm = "";
        $this->clientForm = "";
        $this->divForm = "";
        $this->dealerForm = "";
        $this->dealerAddForm = "";
        $this->dealerEditForm = "";
        $this->catForm = "";
        $this->productForm = "";
        $this->productAddForm = "";
        $this->productEditForm = "";
        $this->orderForm = "";
        $this->orderViewForm = "";
    }

    /* Setters */
...
            /* getters */
... 

I then have a form processor class which processes forms written by this class...

Of course, this is very, very wrong... and somewhat procedural in essence it's just a function library wrapped inside a class

I did as lastcraft said and did it one story at a time and that's how I kept things organised and unconsciously reached 1000+ lines!

It's been a while since I've read this thread, but reading over it after having experience trying to write OOP makes a big difference.

FOr instance, after reading Manor's post midway through typing this, I get the feeling that my plans at refactorig will probably land on it's a$$... But hey, I'll document that too.



I'm thinking about refactoring so that:

[li]the related information have their own classes (clients class, categories class, products class, divisions class, dealers class, orders class)[/li]

[li]will be a subclass to a parent form class which will compose the Form Elements class.[/li]

[li]the parent form class also aggregates the Database class[/li]

Still a little murky, but it's an experience. At this point in time, I've decided to stop leeching from the gurus (thanks for the advice, it's always appreciated). Give me some feedback if you will, as it's always appreciated. But I guess this kind of stuff is a hard to teach to someone who does not have the least bit of knowledge about certain concepts etc. and for that, many thanks again to the others patience I am most grateful.

Best regards,

Melan'