Design Patterns in Ruby

[skinny monkey]

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.

[vgarcia]

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.

[Fenrir2]

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.

[skinny monkey]

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.

[vgarcia]

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?

[skinny monkey]

i want to be a better web developer.

So both.

[samsm]

Would I be incorrect in saying that what is referred to in PHP as design patterns is called "the Ruby Way" in Ruby?

[Luke Redpath]

Well, Ruby has singleton methods built right-in.

Rails also implements the Observer pattern in ActiveRecord.

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

[DougBTX]

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

class Example
    include Singleton
end

It looks stupidly simple, why would you want to write anything more?

Douglas

[samsm]

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.

[DougBTX]

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

[lastcraft]

Hi...

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

class Example
    include Singleton
end

But in PHP you can just do this...

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.

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

[DougBTX]

But in PHP you can just do this...

class Example extends Singleton { } 

You can, but I don't think we'll see it anywhere near the documentation.

I personally find the "Ruby way" pragmatic rather than beautiful.

There's probably some overlap there

Douglas

[lastcraft]

Hi...

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 .