SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 69
  1. #26
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Per
    Everything
    works on a PowerPoint slide

  2. #27
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #28
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Last edited by melancholic; Mar 28, 2005 at 21:17. Reason: deleted load of crap - geeze that was a load of crap wasn't it?

  4. #29
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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":
    Code:
    - 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'

  5. #30
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  6. #31
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Christopher

  7. #32
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi there,

    Quote Originally Posted by arborint
    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.

    Quote Originally Posted by arborint
    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'

  8. #33
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

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

    PHP Code:
    ...
    $this->id $this->userinfo[0][1];
    ... 
    Instead, I would have something like this

    PHP Code:
    ...
    $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

  9. #34
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ahh, I see... that makes sense.
    thank you DL

  10. #35
    Massimiliano Bruno Giordano sid egg's Avatar
    Join Date
    Aug 2004
    Location
    Canada
    Posts
    1,280
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by melancholic
    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:

    PHP Code:
    $login = new Form("login""login.php""POST"); // ... Form has many inherited parts, inherited versions usually just overload render();
    $user = new Text("user""Username:"5070);
    $pass = new Text("pass""Password:"3050true);
    $login->addFormElement($user);
    $login->addFormElement($pass);
    echo 
    $login->render(); // loops through all the elemnts, and calls their render member in it's respective location 
    GamesLib.com - the slickest, most complete and
    easily navigatible flash games site on the web.

  11. #36
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sid egg
    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'

  12. #37
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  13. #38
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...

    Code:
    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.

  14. #39
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm just starting out much like yourself so my knowledge is limited

  15. #40
    Non-Member bronze trophy geniusgoalie's Avatar
    Join Date
    Sep 2004
    Location
    Buffalo, USA
    Posts
    979
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wow, this is a great thread for OOP n00bs (like me!). Good job, Melancholic!

  16. #41
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    Germany
    Posts
    550
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by melancholic
    - 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

  17. #42
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi there,

    Quote Originally Posted by Daimaju
    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.

  18. #43
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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 Code:
    <?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'

  19. #44
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello,

    PHP Code:
    ...
    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.

  20. #45
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    PHP Code:
    class Form {
    ... 
    current LoginForm class
    PHP Code:
    class LoginForm extends Form {
    ...

    "LoginValidator is a Validator"

    validator class
    PHP Code:
    class Validator {
    // database object
    // isvalid
    ... 
    OR

    PHP Code:
    class Validator {
    // isvalid
    ...
    function 
    connectToSource
    {

    LoginValidator
    PHP Code:
    class LoginValidator extends Validator {
    ...
    // test data specific to login

    regards,


    Melan'

  21. #46
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    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.
    Christopher

  22. #47
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  23. #48
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The count($_POST) is an interesting idea. Thanks.
    Christopher

  24. #49
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?
    PHP Code:
    class LoginForm {

        var 
    $html;

        function 
    LoginForm() {...}

        function 
    set() {...}

        function 
    get(){...}

        function 
    process() {...}

        function 
    validate(){...}




    Or... This way?

    PHP Code:
    class FormWriter {

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

    }

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

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

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

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

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

    PHP Code:
    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

  25. #50
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    PHP Code:
    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'


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •