SitePoint Sponsor

User Tag List

Results 1 to 14 of 14

Hybrid View

  1. #1
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    421
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Design Patterns in Ruby

    I was wondering about the implementation of design patterns in ruby rails code. For instance, apart from the framework following mvc seperation, are other design patterns such as singleton, observer, strategy, composite, visitor etc used in a typical ruby rails app?

    I'm a fairly competent php programmer, and am really starting to develop well using OO styes & design patterns. Naturally, i want to progress in my abilities, and ruby is an option on my horizon.

    Php takes a lot of flak for being so disorganised: the fact that you can implement ActiveRecord in rails in less than 10 lines of code indicates to me that the design patterns have already been made for you - all you need to do is use them. If thats the case, do ruby programmers need to "know" how to use design patterns- will programming an app in ruby rails make me a sloppy programmer, with a shallow understanding of OO design?

    Although php is a rough language, the fact that it is so un-object oriented has meant that i've had to learn OO principles, and become a better programmer as a result. I don't just know what ActiveRecord is; i know how to implement my own ActiveRecord solution if i need to.

    Much in the same a lot of .net coders use intrinsic controls without ever really knowing how they work, I was just wondering, from a personal development point of view, what language would further my understanding of design patterns and OO design.


  2. #2
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by skinny monkey
    Php takes a lot of flak for being so disorganised: the fact that you can implement ActiveRecord in rails in less than 10 lines of code indicates to me that the design patterns have already been made for you - all you need to do is use them. If thats the case, do ruby programmers need to "know" how to use design patterns- will programming an app in ruby rails make me a sloppy programmer, with a shallow understanding of OO design?
    Sure you can build something off of Active Record without knowing about the design pattern, but that doesn't mean you have to shield yourself from it.

    I don't think programming in Ruby will make you a sloppy OO programmer any more than programming in Java would. Keeping everything object oriented is mostly about discipline I think.

    I find that Rails's strength isn't in making you learn every little detail about OO and design patterns, but rather that it's all built for you and ready to go. When you have a solid base to work on you tend to respect that base and learn how it works to further your own programming. With Rails it's far easier to work within the system/style in which it was constructed since it's all very consistent. With baseline, no-framework PHP you don't have that as much.

  3. #3
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why would you want to use design patterns? You should not use design patterns just because of the design patterns. THE way to get good code is to write the application twice. Use a different approach every time, and choose the best version.

    My suggestion: learn Lisp.

  4. #4
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    421
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Its not so much that i would go out of my way to use them, but understanding what situations they can be used is a really important programming concept. Having an "off-the-shelf" design pattern, ready to use, would hold little personal development for me, much the same way as eating a microwave meal.

  5. #5
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by skinny monkey
    Having an "off-the-shelf" design pattern, ready to use, would hold little personal development for me, much the same way as eating a microwave meal.
    Do you want personal development or do you want to build websites?

  6. #6
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    421
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i want to be a better web developer.

    So both.

  7. #7
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Would I be incorrect in saying that what is referred to in PHP as design patterns is called "the Ruby Way" in Ruby?
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  8. #8
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samsm
    Would I be incorrect in saying that what is referred to in PHP as design patterns is called "the Ruby Way" in Ruby?
    Yes, it would be incorrect. I think "the Ruby Way" would be best summed up as "do everything in such a way that it looks so stupidly simple that you wouldn't want to do it any other way."

    I think Try Ruby is a good example of "The Ruby Way". Simple, looks good, works well.

    "Design patterns" in PHP means "Patterns are ways to describe best practices and good designs. They show a flexible solution to common programming problems." with code that looks like this:

    PHP Code:
    <?php
    class Example
    {
       
    // Hold an instance of the class
       
    private static $instance;
      
       
    // A private constructor; prevents direct creation of object
       
    private function __construct()
       {
           echo 
    'I am constructed';
       }

       
    // The singleton method
       
    public static function singleton()
       {
           if (!isset(
    self::$instance)) {
               
    $c __CLASS__;
               
    self::$instance = new $c;
           }

           return 
    self::$instance;
       }
      
       
    // Example method
       
    public function bark()
       {
           echo 
    'Woof!';
       }

       
    // Prevent users to clone the instance
       
    public function __clone()
       {
           
    trigger_error('Clone is not allowed.'E_USER_ERROR);
       }

    }

    ?>
    "The Ruby Way" says patterns shouldn't be put in the documentation to be copy-pasted all over the place. It says copy-pasting isn't fun, and it doesn't look simple: it just looks ugly. "The Ruby Way" says code should be beautiful.

    With the Ruby Way, you'd just have this:

    Code:
    class Example
        include Singleton
    end
    It looks stupidly simple, why would you want to write anything more?

    Douglas
    Hello World

  9. #9
    ********* 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 DougBTX
    With the Ruby Way, you'd just have this:

    Code:
    class Example
        include Singleton
    end
    But in PHP you can just do this...
    PHP Code:
    class Example extends Singleton { } 
    ...and write a little bit of library code. Singleton is only one example of object lifecycle as you can have cacheable, lazy, persistent, shared memory, etc. That Ruby supplies it doesn't really give you much.

    Quote Originally Posted by DougBTX
    It looks stupidly simple, why would you want to write anything more?
    I am going to go against the grain here and say that I think including Singleton in Ruby was a slight mistake. Dependency injection is a far more effective way of dealing with single instances at the application level, and low level code should never use them.

    The "Ruby way" is not minimalist though, so having a Singleton does fit Ruby. I personally find the "Ruby way" pragmatic rather than beautiful.

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

  10. #10
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    But in PHP you can just do this...
    PHP Code:
    class Example extends Singleton { } 
    You can, but I don't think we'll see it anywhere near the documentation.

    Quote Originally Posted by lastcraft
    I personally find the "Ruby way" pragmatic rather than beautiful.
    There's probably some overlap there

    Douglas
    Hello World

  11. #11
    ********* 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 DougBTX
    You can, but I don't think we'll see it anywhere near the documentation.
    No obviously . I mean that this does't give Ruby an advantage, I think it's the blocks replacing iterators and visitors that do that, and clean extensible containers. These remove a lot of code clutter.

    Regarding Rails, I still haven't had a chance to try it out . I've been reading up on it, and like any framework it's already made some design pattern decisions for you. In Rails' case: ActiveRecord (with ForeignKeyMapping), SingleTableInheritance, FrontControler/Actions, TemplateView, OptimisticLock.

    Almost all the examples I've seen have been a bit data centric, and I'd like to see someone do something a bit different with it. Otherwise you could just use the DB stored procedures to do most of the work and churn out a Ruby/PHP app. with: TableWidget/ServerPage, ResultSet, Decorator, TableDataGateway.

    yours, Marcus

    An aside: what features would you like to see added to Ruby/Rails and what removed? It can't be that perfect .
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  12. #12
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, Ruby has singleton methods built right-in.

    Rails also implements the Observer pattern in ActiveRecord.

    http://api.rubyonrails.com/classes/A.../Observer.html

  13. #13
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's kind of what I mean.

    Ruby was made to exemplify certain best practices, so when you use basic features in Ruby to make code beautiful, you are utilizing best practises that that most advanced php users have to wrestle into their code through design patterns.

    No?

    Well, maybe not. Beats me really, I was just tossing it out there, not something I've thought a lot about.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  14. #14
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samsm
    Ruby was made to exemplify certain best practices, so when you use basic features in Ruby to make code beautiful, you are utilizing best practises that that most advanced php users have to wrestle into their code through design patterns.

    No?
    Hmm, I hadn't thought about it like that. I think I can see some overlap, but... I'm tempted to think that it is something that you would only see in hindsight, rather than a design goal. Ruby wasn't designed to "exemplify best practices", it was to be a better Perl.

    Douglas
    Hello World


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
  •