SitePoint Sponsor

User Tag List

Page 4 of 5 FirstFirst 12345 LastLast
Results 76 to 100 of 116
  1. #76
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What I could of course do is always supply the constructors of person and department with a result set, but all result sets have something in coming: the variables that will be important for the department and person classes are always called the same.

    Code sample:

    PHP Code:
    class task {
        var 
    $title '';
        var 
    $owningMember '';
        var 
    $owningDepartment '';
        
        function 
    task($row) {
          
    $connection = &$this->getConnection();
            
    $this->title $row['title'];
            
             
    $this->owningMember = &new person($row);     
            
    $this->owningDepartment = &new department($row);
        }
        
       function 
    getOwningMember() { 
            return 
    $this->owningMember;
        }
        
       function &
    getOwningDepartment() { 
            return 
    $this->owningDepartment;
        }
    }

    class 
    department {
        var 
    $id '';
        var 
    $name '';
        
       function 
    department($row) {
            
    $this->id $row['deptId'];
            
    $this->name $row['deptName'];
        }    
       function &
    getMembers() { }
    }

    class 
    person {
        var 
    $id '';
        var 
    $name '';
        var 
    $email '';
        
       function 
    person($row) { 
            
    $this->id $row['memId'];
            
    $this->name $row['memName'];
            
    $this->email $row['memEmail'];
        }
       function 
    getName() { }

    But that could of course cause some problems if I for some reason query two diffeerent departments from the db and have to call them something useful in order to make it visible what they are used for, for example userDeptId, someOtherMemberDeptId.

    Then of course that code above would not work. Arrrgh! I guess I need some help here.

  2. #77
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm, probably I should just set up a ton of setMemId, setMemEmail, etc. methods and handle each result set differently. That will make up for better flexibility yes? Having some optional parameters in the constructors allows us to calc some of the other properties (think members of a department) and add them later through the set-methods. Does that make sense?

    Code:

    PHP Code:
    class task {
        var 
    $title '';
        var 
    $owningMember '';
        var 
    $owningDepartment '';
        
        function 
    task($row) {
          
    $connection = &$this->getConnection();
            
    $this->title $row['title'];
            
             
    $this->owningMember = &new person($row['memId'], $row['memName']); 
             
             
    // later then add the email
             
    $this->owningMember->setEmail($row['memEmail']);
             
            
    $this->owningDepartment = &new department($row['deptId'], $row['deptName'];
            
            
    // calculate which users belong to the dept and later add them
            // $members = array();
            
    $this->owningDepartment->setMembers($members);
        }
        
       function 
    getOwningMember() { 
            return 
    $this->owningMember;
        }
        
       function &
    getOwningDepartment() { 
            return 
    $this->owningDepartment;
        }
    }

    class 
    department {
        var 
    $id '';
        var 
    $name '';
        var 
    $members = array();
        
       function 
    department($id$name$members = array()) {
            
    $this->id $id;
            
    $this->name $name;
            
    $this->members $members;
        }
        
        function 
    setId($id) { 
            
    $this->id $id;
        }
        function 
    setname($name) { 
            
    $this->name $name;
        }
        function 
    setMembers($members) {
            
    $this->members $members;
        }
        
       function &
    getMembers() {
            return 
    $this->members;
        }
       function &
    getId() {
            return 
    $this->id;
        }
       function &
    getname() {
            return 
    $this->name;
        }
    }

    class 
    person {
        var 
    $id '';
        var 
    $name '';
        var 
    $email '';
        
       function 
    person($id$name$email='' ) { 
            
    $this->id $id;
            
    $this->name $name;
            
    $this->email $email;
        }
        
        function 
    setId($id) { 
            
    $this->id $id;
        }
        function 
    setname($name) { 
            
    $this->name $name;
        }
        function 
    setEmail($email) {
            
    $this->email $email;
        }
        
       function &
    getName() {
            return 
    $this->name;
        }
       function &
    getEmail() {
            return 
    $this->email;
        }
       function &
    getId() {
            return 
    $this->id;
        }

    Looks good yes?

    PS: As you probably noticed I added some get-accessors as well.

  3. #78
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, now I added the calculation of the members of the owning department. You like it?

    PHP Code:
    class taskFinder {
        function 
    taskFinder() {}
       function &
    findByProjectName($project_name) { }

       function &
    findByName($name) {
           
    $sql "select t.title, m.memId, d.id as deptId".
                    
    " m.name as memName, m.email as memEmail".
                    
    " d.name as deptName".
                    
    " from tasks as t".
                    
    "    left join members as m on (t.mem_id = m.id)".
                    
    "    left join departments as d on (t.dept_id = d.id)".
                    
    "    where t.name='$name'";
          
    $connection = &$this->getConnection();
          
    $iterator = &$connection->query($sql);
          if (! 
    $iterator) {
              return 
    false;
             }
             return new 
    task($iterator->next());
        }    
    }

    class 
    taskIterator {
       function 
    taskIterator($database_result) { }
       function &
    next() { }
    }

    class 
    task {
        var 
    $title '';
        var 
    $owningMember '';
        var 
    $owningDepartment '';
        
        function 
    task($row) {
          
    $connection = &$this->getConnection();
            
    $this->title $row['title'];
            
             
    $this->owningMember = &new person($row['memId'], $row['memName']); 
             
             
    // later then add the email
             
    $this->owningMember->setEmail($row['memEmail']);
             
            
    $this->owningDepartment = &new department($row['deptId'], $row['deptName'];
            
            
    // calculate which users belong to the dept and later add them
            
    $finder = &new personFinder();
            
    $members = &$finder->findByTaskName($this->name);
            
    $this->owningDepartment->setMembers($members);
        }
        
       function 
    getOwningMember() { 
            return 
    $this->owningMember;
        }
       function &
    getOwningDepartment() { 
            return 
    $this->owningDepartment;
        }
    }

    class 
    department {
        var 
    $id '';
        var 
    $name '';
        var 
    $members = array();
        
       function 
    department($id$name$members = array()) {
            
    $this->id $id;
            
    $this->name $name;
            
    $this->members $members;
        }
        
        function 
    setId($id) { 
            
    $this->id $id;
        }
        function 
    setname($name) { 
            
    $this->name $name;
        }
        function 
    setMembers($members) {
            
    $this->members $members;
        }
        
       function &
    getMembers() {
            return 
    $this->members;
        }
       function &
    getId() {
            return 
    $this->id;
        }
       function &
    getname() {
            return 
    $this->name;
        }
    }

    class 
    person {
        var 
    $id '';
        var 
    $name '';
        var 
    $email '';
        
       function 
    person($id$name$email='' ) { 
            
    $this->id $id;
            
    $this->name $name;
            
    $this->email $email;
        }
        
        function 
    setId($id) { 
            
    $this->id $id;
        }
        function 
    setname($name) { 
            
    $this->name $name;
        }
        function 
    setEmail($email) {
            
    $this->email $email;
        }
        
       function &
    getName() {
            return 
    $this->name;
        }
       function &
    getEmail() {
            return 
    $this->email;
        }
       function &
    getId() {
            return 
    $this->id;
        }
    }


    class 
    personFinder {
        function 
    personFinder() {}

       function &
    findByTaskName($name) {
           
    $sql "select m.memId, m.name as memName, m.email as memEmail".
                    
    " from tasks as t".
                    
    "    left join members as m on (t.mem_id = m.id)".
                    
    "    where t.name='$name'";
          
    $connection = &$this->getConnection();
          
    $iterator = &new personIterator($connection->query($sql));
          
          
    $members = array();
          while(
    $iterator->next()) {
                
    $members[] = $iterator->next();
            }
            
            return 
    $members;
        }    
    }

    class 
    personIterator {
       function 
    personIterator($database_result) {
        }
       function &
    next() {
        }


  4. #79
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was only thinking aloud I suppose, but I think this example is reasonable ?

    PHP Code:
    class task 
        var 
    $title ''
        var 
    $owningMember ''
        var 
    $owningDepartment ''
         
        function 
    task($row) { 
          
    $connection = &$this->getConnection(); 
            
    $this->title $row['title']; 
             
             
    $this->owningMember = &new person($row);      
            
    $this->owningDepartment = &new department($row); 
        } 
         
       function 
    getOwningMember() { 
            return 
    $this->owningMember
        } 
         
       function &
    getOwningDepartment() { 
            return 
    $this->owningDepartment
        } 


    class 
    department 
        var 
    $id ''
        var 
    $name ''
         
       function 
    department($row) { 
            
    $this->id $row['deptId']; 
            
    $this->name $row['deptName']; 
        }     
       function &
    getMembers() { } 


    class 
    person 
        var 
    $id ''
        var 
    $name ''
        var 
    $email ''
         
       function 
    person($row) { 
            
    $this->id $row['memId']; 
            
    $this->name $row['memName']; 
            
    $this->email $row['memEmail']; 
        } 
       function 
    getName() { } 

    As the refactored examples that have sprung from this one (above)

  5. #80
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What does Marcus say? Because of what I already said in post #76..could be that I need to grab two different deptIds for some reason..then create two objects and pass them each the result set. But with that current set up how would the second object get its deptId, because I cannot make a query where I get two different deptIds that I both call 'deptId'. Makes sense?

  6. #81
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One question I have still: When looking at taskFinder you see that it has methods that *should* return one object (getBasedOnName) and that there could be methods that *should* return an array of objects (getBasedOnUser).

    How would you handle that? Should always be an array of objects returned? That would be silly yes? But then we'd need to add extra functionality to again iterate over such return arrays. *sigh*

    Ideas?

  7. #82
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by DarkAngelBGE
    What does Marcus say?
    Well, Marcus doesn't want to dominate the thread . But as you asked...

    I like the join, but do you actually have to separate the joined attributes into their separate objects. The object model doesn't have to match the tables. As task object could legitimately have accessors like getOwningDepartmentName() and just pull it from it's internal copy of the row.

    The XPers have a saying: YAGNI. It stands for "You aren't gonna need it". When you need separate internal objects, implement them then.

    Regarding the array issue you don't need to load them all at once. When you run a select query against MySql you get a result ID. Pass that result ID to the iterator (along with the class name). On each call to next() the iterator can call mysql_fetch_row() (or whatever the call is) to get the next row...
    PHP Code:
    class TaskIterator {
        var 
    $_result;

        function 
    TaskIterator($result) {
            
    $this->_result $result;
        }
        function &
    next() {
            
    $row mysql_fetch_row($resultMYSQL_ASSOC); // Syntax?
            
    if (! $row) {
                return 
    false;
            }
            return new 
    Task($row);
        }

    That way each object is fetched only as it is needed.

    The next obstacle that will be faced is who owns the connection. If you are doing work as part of a transaction then all the work has to be handled through the same connection. This may mean passing the appropriate connection around, or having just one object responsible for it.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  8. #83
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sounds good, the iterator approach.

    Yeah well that raises the question again of a DB singleton or even registry or what not...I hate DB connections.

    Then again we also need a mysqlResultIterator and FileIterator to make this independant of a DB. *sigh*

    I like the join, but do you actually have to separate the joined attributes into their separate objects
    Could you back this up with some code please?

    Well I always thought that it is not a must, but would be cool if the object model is like the data structure in the DB...

  9. #84
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
            $members = &$finder->findByTaskName($this->name);
            
    $this->owningDepartment->setMembers($members); 
    Now for that, I guessed it right, I'd need the personIterator no?

  10. #85
    SitePoint Member
    Join Date
    Jul 2004
    Location
    United Kingdom
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just a quick question to some of the experts in here:

    Reading this thread, it seems apparent that you have a great liking for iterators. I was wondering why this is; why iterators are used in preference to, say, foreach'ing through an array of results (getting all the information at once, not having to worry about maintaining connections). Is this just an abstraction issue?

    At the moment, it just seems to be using OO where there's no immediately obvious gain by doing so. I'm no PHP professional, just an interested observer Tim referred here, so I'm curious what you percieve the advantages to be.

  11. #86
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By the way, Mark is the one that was the main helper with my subtasks problem in the other thread.

    Thanks Mark for stopping by.

  12. #87
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Marcus,

    This may mean passing the appropriate connection around, or having just one object responsible for it.
    Do you have something up your sleeve ?

    Tim,

    Kind of still pondering on all what Marcus has been saying, finding it difficult to keep up with it all in fact

  13. #88
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    finding it difficult to keep up with it all in fact
    Well, it is good though that we are mostly always only 3 guys herein. That way it is not TOO difficult to keep up with everything.

  14. #89
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by WFG_Mark
    why iterators are used in preference to, say, foreach'ing through an array of results (getting all the information at once, not having to worry about maintaining connections). Is this just an abstraction issue?
    In the case of DB work, iterators are a pretty close match to how the database works. Also you don't need to keep much in memory as the old row can be discarded before the new one is loaded. With foreach in PHP4 you would have to load the whole array and then iterate through it. You can also hide things behind the OO interface and have things like decorators and adaptors applied without changing any client code (design patterns again).

    Foreach is very close to iterators anyway, and in PHP5 you can create iterators that work with foreach without losing the advantages above.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #90
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Widow Maker
    Do you have something up your sleeve ?
    Might have .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  16. #91
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay guys let's continue with this thread then.

    I learned Java and am now much more into OO than ever before. I understand its principles much clearer now and I agree, that an OO approach would suit this project greatly.

    Here is a class diagram for this project I have been working on. Please tell me what you think or ask any questions.

    Thanks for helping me getting into the OOP world.
    Attached Images Attached Images

  17. #92
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not too involved with UML myself (yet) though the relationships between your objects looks okay, to me

    But I'm still learning UML, as I say

  18. #93
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Neato. Not quite sure though what exactly taskList, DepartmentList etc. should do - but probably, as I laid it out, be the controller where the ObjectFinder and the ObjectIterator meet.

    Now on to adding a Front Controller/Page Controller set up to the diagram.

  19. #94
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One thing that concernes me about performance, though, is the following:

    Say I want to list all departments and underneath each department name I want to list the names of all tasks that belong to that department.

    Well I would get an instance of DepartmentList, switch on the finder and get all departments. One query, alright.

    Now when iterate over the list with DepartmentIterator I create an instance of TaskFinder in each iteration. I launch TaskFinder::findByDepartmentName and get a list of Tasks for that department. Using TaskIterator within Department Iterator is alright and I can quickly get the required job done.

    Where is the problem? Well, I have nested datasource queries, which is alright with files, but assuming my datasource is a mysqlTable I am screwed.

    Comments/ideas?

  20. #95
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well that would be the way the OO guy would do it yes? Now probably I need to find all tasks and sort them by department name (well, for that I have to call Task::getOwningDepartment in every iteration, which either means nested queries again or I have somehow stored all departments somewhere else and calculate which department belongs to which task) and the iterate over them and output them..

  21. #96
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, here is an update of the class diagram. Any thoughts?

    Edit: It seems a bit unlogical to me that a task has an owning department (Marcus proposed this a while ago). The only way a task should know about its Department is over the Person it is assigned to. Agree?
    Attached Images Attached Images

  22. #97
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Another thought would be if TaskIterator, DepartmentIterator are needed or if I just use FileIterator, MysqlResultIterator, etc. ?

  23. #98
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Canada
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up

    I like this new design better than the previous ones. It's modular and powerful enough for the job at hand, I think. I also think it's a good idea to make your own Iterators and Lists, since that separates you from dependence on MySQL (and even if you use MySQL, you can redesign the tables and all the changes will be localized).

    There are a couple of things that bother me though:

    - First, why do you have the blank interfaces Iterator, List and Finder? Interfaces that contain no methods are generally not useful, because you don't guarantee that the object can do anything. For example, why would a method be declared as returning an Iterator, or as taking an Iterator as a parameter? How would this be any different than just taking or returning an object of unspecified type?

    (In fact, I'm lying - there are a few rare occasions when a blank interface does make sense. For example, in Java, Serializable is an interface that defines no methods: it just marks an object as "yes, this object should be serialized to an output stream". The reason for this is that there are objects which are inherently not serializable, such as a Window or an InputStream, yet if an object is serializable it doesn't really need to declare any methods (Java serializes it on its own, by finding and writing all its primitive-type fields to the file as well as any Object fields that implement Serializable). However, this isn't true in your system. There's no reason to treat a List differently from any other object anywhere.)

    The reason for this is probably that you declared a different return type for the methods; for example findNamed() finds a Department for DepartmentFinder but a Task for a TaskFinder. There are two ways to get around this:
    a) Just make the methods return object, of any type; then you can declare them in the Finder interface as well. I don't think PHP is strongly typed anyway.
    b) Use a language that supports generics or templates. This allows you to declare Finder as a generic interface Finder<T>, which contains methods T getByName(), T getById(), etc; then TaskFinder can implement Finder<Task>, DepartmentFinder can implement Finder<Department>, etc. I don't think PHP supports templates though.

    I do think that it's good to have these interfaces around, since you can perhaps design some code that works with any kind of Finder.

    - Second, I don't see any methods that create or return Finders, although I may be missing something. It would be good if each department had a TaskFinder to find tasks within it for example, or if TaskFinder had a constructor where you could supply some constraints (for example, look for all tasks started in the last week). The latter can be done easily by passing some SQL directly to the constructor.

    - Third, some get methods are missing (for example, no getOwnedTasks in person, no getTasks in Department).

    - Finally, for the Persons, you might want to add other fields: realName, messangerNickname (for MSN messanger, maybe others too), and forumName come to mind. Perhaps a forumId too - then you might be able to send them private messages or list forum messages by person. For the tasks, you might want some sort of "status" object, and a "description" string.

  24. #99
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Matei, ole' buddy, thanks for following my request about posting in here.


    - First, why do you have the blank interfaces Iterator, List and Finder? Interfaces that contain no methods are generally not useful, because you don't guarantee that the object can do anything. For example, why would a method be declared as returning an Iterator, or as taking an Iterator as a parameter? How would this be any different than just taking or returning an object of unspecified type?
    Well, I just hooked up Enterprise architect and don't know yet how to add methods to interfaces with it. However, if I knew, I would add findNamed() and findById() since every object will have a name and an Id. Does that make sense?

    a) Just make the methods return object, of any type; then you can declare them in the Finder interface as well. I don't think PHP is strongly typed anyway.
    b) Use a language that supports generics or templates. This allows you to declare Finder as a generic interface Finder<T>, which contains methods T getByName(), T getById(), etc; then TaskFinder can implement Finder<Task>, DepartmentFinder can implement Finder<Department>, etc. I don't think PHP supports templates though.
    Thanks, good idea. Will build that in once I find out how to add methods to interfaces in EA. Andn o, php doesn't support templates although that would be the most elegant solution.

    I do think that it's good to have these interfaces around, since you can perhaps design some code that works with any kind of Finder.
    How?

    - Second, I don't see any methods that create or return Finders, although I may be missing something. It would be good if each department had a TaskFinder to find tasks within it for example, or if TaskFinder had a constructor where you could supply some constraints (for example, look for all tasks started in the last week). The latter can be done easily by passing some SQL directly to the constructor.
    Yeah, my primary goal was to first put in all classes I need, then make the associations and then build in the attributes/operations. Maybe I should change my iterative development of the diagram?

    - Third, some get methods are missing (for example, no getOwnedTasks in person, no getTasks in Department).
    Yup, thanks.

    - Finally, for the Persons, you might want to add other fields: realName, messangerNickname (for MSN messanger, maybe others too), and forumName come to mind. Perhaps a forumId too - then you might be able to send them private messages or list forum messages by person. For the tasks, you might want some sort of "status" object, and a "description" string.
    Yeah, correct, but I just wanted to have some basic attributes there. I will add the PM attributes, etc. once I have put in a PersonalMessage class (or similar) into the diagram.

    Thanks again, Matei.

  25. #100
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Canada
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE
    Well, I just hooked up Enterprise architect and don't know yet how to add methods to interfaces with it. However, if I knew, I would add findNamed() and findById() since every object will have a name and an Id. Does that make sense?
    Yes, that makes sense.

    How?
    I assume all your database access code is located within TaskFinder, DepartmentFinder, etc. I.e. TaskFinder looks something as follows:
    Code:
    class TaskFinder {
      object getById(id) {
        $row = mysql_exec("SELECT ... WHERE ID = $id");
        return new TaskList(new Task($row['name'], $row['id'], ...));
      }
    }
    Just change this class and you can use a different DB than MySQL (why you would do that is another question), or, more likely, change your table design (rename a column for example).


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
  •