SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    eigo hanasemasu ka? Yes. =) ZuulJin's Avatar
    Join Date
    Dec 2001
    Location
    Japan
    Posts
    655
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Vincent: what do you think of design patterns?

    Everywhere I read, I see that "Design Patterns" is THE classic programmers book. Have you read it? If so, what do you think? Should I try to read it, as a PHP programmer who so badly wants to engineer apps/software the RIGHT way?

    If I have any typo, sorry... I'm writing this while in a chem suit and gas mask. =)

    Thanks in advance,

    [Z]
    U.S. DoD Member in Japan?
    Choose your base. Buy|Sell. Easy
    @ APO Ads.



  2. #2
    SitePoint Member
    Join Date
    Sep 2002
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes I'd really appreciate some shared experience too. Thanks in advance
    I Make No Apology For Linking My Thinking With Computer Technology - Maxi Jazz

    phpGG: Dutch PHP Community WIP

  3. #3
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    (I'm arrogantly assuming I'm the Vincent you're talking about... )

    The book 'Design Patterns' is a very good book (it's my personal bible ), but it's also one of many: there are more books that try to provide a catalog of patterns. Most of the time, the books offer more or less the same set of patterns, but call them slightly different. Some books offer patterns others don't. Anyway, it's all about the concept that's interesting: instead of having to solve some specific problem, you generalize it, after which you lookup a solution pattern that fits it best. You then implement that pattern specific for your problem. That works very well, because code becomes easier to write (less obscure solutions; the same set of patterns turn up all over the code) and code also becomes easier to read. If you write in a comment which specific pattern you used (e.g. "Factory Method"), others familiar with that pattern will immediately be able to grasp your code. All in all, it's very nice to have patterns.

    But...

    (There's always a but, isn't there?)

    Design patterns aren't for the faint of heart. Once you know them they are reasonably simple, but if you don't know anything about them at all, they're pretty hard to learn. You must learn a different way of approaching problems. Instead of solving one specific problem, you generalize it. That sounds easier than it is. It's a whole different way of thinking. Also, before you can begin with learning patterns, you must have a firm graps of object-oriented programming. Try Java for a while. Once you're familiar with abstract classes (or interfaces), all uses of inheritance, polymorphism and object composition (just to name a few basic OO concepts), then you're about ready to learn patterns. But not any sooner.

    PHP is just another imperative language, as there are so many out there. So you can certainly use Design Patterns in your programming experiences in PHP. Of course, every language is different, and you must take these differences into account. Nevertheless, Design Patterns can help you greatly to come up with nice and simple solutions for big and complex problems.

    Does that answer your question(s)?

    Vincent

  4. #4
    eigo hanasemasu ka? Yes. =) ZuulJin's Avatar
    Join Date
    Dec 2001
    Location
    Japan
    Posts
    655
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You answered my questions perfectly. Now I have another one. How do you think I should go about learning design patterns (assuming I have a firm grasp of OOP)? I took at peak at that book, and uh... yeah. I think I made it past the intro.

    On a side note, have you ever heard of the University of Advancing Technology? I was thinking about taking some distance software engineering classes (I'm in Japan).

    [Z]
    U.S. DoD Member in Japan?
    Choose your base. Buy|Sell. Easy
    @ APO Ads.



  5. #5
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How do you think I should go about learning design patterns (assuming I have a firm grasp of OOP)?
    Well, that depends, I guess...

    One the hand one, there's a lot of documentations. There are for example some books on Java that teach patterns at the same time. Bruce Eckel wrote a very good Java book 'Thinking in Java', which is a free download at http://www.mindview.net. He's also working on 'Thinking in Patterns', but he has been doing that for some time now, so I don't know if that book will ever be finished.

    Anyway, books are just one thing. Doing it yourself is another. So experiment, I'd say. Write some code, look at it with a critical mind from all sides and try to find its faults. Then write it again. And again... It's the theory combined with the practice that teaches you best; not just one of the two.

    Since you're in Japan. You might want to look at Ruby too. If I'm not mistaking, that OO scripting language originated in Japan and is very popular there. And rightfully so, since it's the only true OO scripting language, and it works very well too. (It beats Python by a wide margin, if you ask me...)

    Finally, there are forums like these with people that are willing to help you. After you write some code, post (parts of) it somewhere and start discussing it. Also look at code written by others and try to find the good things and the bad things in those.

    I'm probably disappointing you with this post. But there just is no single course you can take that transforms you into a good OO-designer. To become a carpenter, you mustn't only learns the tools of the trade; you must also work with them...

    Vincent

  6. #6
    eigo hanasemasu ka? Yes. =) ZuulJin's Avatar
    Join Date
    Dec 2001
    Location
    Japan
    Posts
    655
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Heh, I expected a reply exactly like that (minus the Ruby, never heard of that). I'm not Japanese, I just live here. I'm a mid-westerner (from Iowa).

    What kind of problems are best solved with design patterns? How would I go about solving a problem with a design? For example, say I wanted to create a class that would generate a HTML form. It needs to be generic, so is there a design pattern that fits a situation like that?

    I'm probably way off, shows how difficult the topic is for me to grasp.

    Edit
    Funny you mention that free download of "Thinking in Java". I've already downloaded and got stuck on the prologue.

    [Z]
    Last edited by ZuulJin; Oct 9, 2002 at 12:53.
    U.S. DoD Member in Japan?
    Choose your base. Buy|Sell. Easy
    @ APO Ads.



  7. #7
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You might be interested in this: http://www.zend.com/zend/trick/tricks-app-patt-php.php - Applying Patterns in PHP - discusses how you might use a couple of them.

  8. #8
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How would I go about solving a problem with a design? For example, say I wanted to create a class that would generate a HTML form. It needs to be generic, so is there a design pattern that fits a situation like that?
    No, it doesn't quite work like that. A design pattern describes a problem and gives its solution. Before you know which pattern you want to use, you have to identify the problem. In your case, the problem 'generating HTML forms' is a bit vague. There is no pattern that fits it. Once you've examined the problem more closely, you'll be able to identify the patterns that can be used to implement the solution. Note that I wrote 'patterns' and not 'pattern'; it is likely that this particular problem inhibits multiple patterns.

    A form has a set of elements. Each element can be different: there are text fields, selection lists, buttons, checkboxes, and so on. There are, however, some things that can be said for all elements at the same time: they have a name, they have a value, they are either optional or required, and (of course) they can be shown as HTML. These observations can result in a class FormElement. For each specific element type there is going to be a new class, implemented as a subclass of class FormElement. Class TextFormElement for example might offer additional methods to validate the contents against a set of rules: is the value too long or too short, does it match some regular expression, ....

    I think the idea of building an inheritance tree to capture the various form elements isn't too difficult. A problem that comes up, however, is USING this inheritance tree. At some point we're going to define a form that has a set of elements. Each of these elements has some type. How are we going to ensure that the right class is instantiated for these elements? This problem is a very general one, and is captured in the Factory Method pattern. For this case, it could work like this:

    PHP Code:
    class FormElementFactory
    {
        function &
    createFormElement($type)
        {
            switch (
    $type)
            {
                case 
    'text':
                    return new 
    TextFormElement;
                case 
    'list':
                    return new 
    ListFormElement;
                case 
    'checkbox':
                    return new 
    CheckboxFormElement;
                default:
                    exit(
    'Unknown form element type: <b>' $type '</b>');
            }
        }
    }

    $textElement =& FormElementFactory::createFormElement('text');
    // $textElement is now an object of type TextFormElement 
    The idea behind the Factory Method pattern is that it separates class instantiation from object use. Instead of creating some object directly, you let another part of the program do that for you, after which you use it. This has a number of nice consequences. See the book 'Design Patterns' for more information...

    In this case, the FormElementFactory is very simple. But what if it becomes a bit more complicated? Say, for example, that the various element types can be registered dynamically by placing them in some text file:

    PHP Code:
    type     | class
    text     TextFormElement
    list     | ListFormElement
    checkbox 
    CheckboxFormElement 
    When someone uses the factory (by calling 'createFormElement') the code must now open the file, parse its contents, select the right record, and return an object of the right type. That's a lot of work, so we don't want to do that too often. Currently, the factory is a class with a static method only. If we rewrite this to a normal class, we can achieve our goal:

    PHP Code:
    class FormElementFactory
    {
        var 
    $types;
        
        function 
    FormElementFactory()
        {
            
    // Read the file 'types.dat' ...
            // Parse its contents, ...
            // and store it in $this->types
        
    }
        
        function &
    createFormElement($type)
        {
            if (!isset(
    $this->types[$type]))
            {
                exit(
    'Unknown form element type: <b>' $type '</b>');
            }
            
    $class $this->types[$type];
            return new 
    $class;
        }
    }

    $factory     =& new FormElementFactory;
    $textElement =& $factory->createFormElement('text');
    // $textElement is now an object of type TextFormElement 
    This implementation of the Factory Method pattern is already better, as it reads and parses the text file with type information only once. However, all that work is still done for every instantiation of the FormElementFactory class: every time a factory object is created the file is read and parsed. However, the behavior for each factory will be exactly the same. Enter the Singleton design pattern. With this pattern you can instantiate some class only once, after which the rest of the code accesses the code in the class through the exact same object:

    PHP Code:
    class FormElementFactory
    {
        var 
    $types;
        
        
    // This is now a PRIVATE method
        
    function FormElementFactory()
        {
            
    // Read the file 'types.dat' ...
            // Parse its contents, ...
            // and store it in $this->types
        
    }
        
        function &
    createFormElement($type)
        {
            if (!isset(
    $this->types[$type]))
            {
                exit(
    'Unknown form element type: <b>' $type '</b>');
            }
            
    $class $this->types[$type];
            return new 
    $class;
        }
        
        function &
    getInstance()
        {
            if (!isset(
    $GLOBALS['FORM_ELEMENT_FACTORY_SINGLETON']))
            {
                
    $GLOBALS['FORM_ELEMENT_FACTORY_SINGLETON'] =& new FormElementFactory;
            }
            return 
    $GLOBALS['FORM_ELEMENT_FACTORY_SINGLETON'];
        }
    }

    $factory     =& FormElementFactory::getInstance();
    $textElement =& $factory->createFormElement('text');
    // $textElement is now an object of type TextFormElement 
    The singleton pattern can be used in different ways as done here; but this is the way I generally do this myself in PHP.

    Up til now, I have only examined one little piece of the HTML form generation problem: creating form elements. I've already used two design patterns - the Factory Method and the Singleton - while there's still a lot of work to do.

    Hopefully, you'll now see why patterns require a different way of thinking about problems. When I think about the specific problem of HTML form generation, one of the first things that comes to my mind is 'a class hierarchy for the elements on the form'. I know in advance this will be a requirement, without having to look at any other part of the problem yet (like how to show the form in different ways). When I use a class hierarchy (with a nice abstract class), I also need a factory, likely to be implemented as a singleton. This a much more abstract way of thinking about the problem. And to be honest, I have no idea where you can learn that. I think it's something that comes after years of stumbling on in the dark...

    Vincent

  9. #9
    SitePoint Zealot
    Join Date
    Dec 2001
    Location
    Ontario, Canada
    Posts
    141
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hey Vincent,
    I had to laugh when I saw you use a global, I know how you hate globals ( as much as I do ).

    one of my simple getInstance functions works like this:
    PHP Code:
    ....
        function &
    getInstance() {
            static 
    $instance;
            if( !isset( 
    $instance ) ) {
                
    $obj = &new FormElementFactory// I'll use your class ;-)
                
    $instance $obj// this is because of some issue about directly assigning a reference to a static variable
            
    }
            return( 
    $instance );
        }
    .... 
    no need to use the $GLOBALS array
    Last edited by AcidReign; Oct 10, 2002 at 13:49.
    Web Hound
    $x='010000010110001101101001011001000101001001100101011010010110011101101110';
    for($i=0;$i<strlen($x);$i+=8)print(chr(bindec(substr($x,$i,8))));

  10. #10
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I had to laugh when I saw you use a global, I know how you hate globals ( as much as I do )


    I thought there was no other way! I always believed static variables weren't possible in classes. But seeing as you do, I'm immediately going to rewrite all the code that uses them!

    So thanks for the tip!

    But, bye the way, doesn't this:

    PHP Code:
    $instance $obj
    ...still create a copy? For most factories this won't be a problem, I agree, but when the factory assigns a reference to a member variable in its (private) constructor, there still are problems, right?

    Vincent
    Last edited by voostind; Oct 10, 2002 at 14:32.

  11. #11
    SitePoint Zealot
    Join Date
    Dec 2001
    Location
    Ontario, Canada
    Posts
    141
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    no, it shouldn't be a problem, if you use static with out the reference (&) at all, then a copy is returned every time, but it seems that when you create the referecne then copy it to the static variable, the reference is copied, not a copy of the object ... atleast it seems to work this way.
    I'l refer you to:
    http://www.sitepointforums.com/showt...threadid=72370
    and:
    http://www.sitepointforums.com/showt...290#post516639

    when I had that problem and you pointed out the use of & to correct it, I used something along the same lines to test whether it was acting as it should, and it seemed to
    Web Hound
    $x='010000010110001101101001011001000101001001100101011010010110011101101110';
    for($i=0;$i<strlen($x);$i+=8)print(chr(bindec(substr($x,$i,8))));

  12. #12
    SitePoint Zealot
    Join Date
    Dec 2001
    Location
    Ontario, Canada
    Posts
    141
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    also, the way I figured this out ...
    I knew you could have 'static' variables in functions,
    and I knew that when you instaniate a 'class' the 'object' you get is only a collection a variables, and 'pointers' to functions, and '$this' is passed to the functions as a hidden parameter, the functions them selves exist on only one place in memeory ...
    so I figured that since there is only ever one 'copy' of the function, a 'static' variable will hold its data, not caring which 'instance' of the object called it.
    Web Hound
    $x='010000010110001101101001011001000101001001100101011010010110011101101110';
    for($i=0;$i<strlen($x);$i+=8)print(chr(bindec(substr($x,$i,8))));

  13. #13
    SitePoint Member
    Join Date
    Aug 2007
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Some really useful values, thanks.....
    Best Vacation On Best Resort

  14. #14
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Kolyan, you are aware of the fact that this was five years ago right? Although the posts of voostind are forever valid, php 5 has changed much of the way he did things.


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
  •