SitePoint Sponsor |
|
User Tag List
Results 1 to 25 of 25
-
Nov 8, 2006, 02:59 #1
- Join Date
- Jan 2004
- Location
- Manchester
- Posts
- 32
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
OO Question: No abstract classes or interfaces a good thing?
I'm looking at moving from PHP5 to Ruby, and I've recently had another look at the ruby-lang.org site. There's a section on how Ruby compares to PHP(5).
One of the differences is states is that "there’s no abstract classes or interfaces". I'm no OO guru, but wouldn't that be cause for concern? I've been using frameworks and developing in OO now for about 5 years and while I use abstract classes and interfaces sparringly, I've found them useful - especially when developing a custom Database abstraction layer.
To those of you who have come from another OO language to Ruby, and use Ruby outside of the RoR camp, I ask: do you miss not having abstract classes and interfaces? Is your life now easier without them? What are your thoughts on the matter?
-
Nov 8, 2006, 06:02 #2
Abstract classes aren't really a big deal when you can change the details of any class/method whenever you want. Let's say you wanted to rewrite how Ruby does uppercasing of strings:
Code:# ...some unrelated code up here... class String def upcase #do what you want here end end "Foo-Bar".upcase #will use your upcase method
-
Nov 8, 2006, 10:50 #3
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
You could use a normal class every time you use an abstract class?
-
Nov 8, 2006, 11:31 #4
- Join Date
- Jan 2004
- Location
- Manchester
- Posts
- 32
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
If you can manipulate an object/class at any point, doesn't that make it more important that you can set some rules using an interface or overwrite abstract methods/classes to ensure that you're extending your classes in the right way?
-
Nov 8, 2006, 13:12 #5
Originally Posted by neobuddah
-
Nov 8, 2006, 13:50 #6
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Unlike classes or objects, abstracts and interfaces are not something that exists in objective reality. They are only "scaffolding" needed to support c++/java static typing system. Since ruby doesn't have static types, there's no need of them.
-
Nov 8, 2006, 15:03 #7
- Join Date
- Jan 2004
- Location
- Manchester
- Posts
- 32
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stereofrog
For example, how would I ensure that any developer who creates an extension to my "SendMessage" class makes available the methods I outlined (addRecipient, setBody, sendMessage)? How could I ensure that I don't miss overwriting important methods (such as sendMessage) when extending my "SendMessage" class with "SendHTMLEMail" and "SendTextEMail"? How would I ensure that nobody modifies at run-time the common methods these child classes expect available in the parent (such as parent::getRecipients)?
-
Nov 8, 2006, 15:57 #8
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by neobuddah
How, in Ruby, would you ensure a set of objects to conform to a specific set of methods?
2. you unittest it
3. people who extend your class, document and unittest their changes.
The point is you cannot "ensure" anything about your program without running it.
This static vs dynamic (aka interfaces vs ducks, aka java vs ruby) debate has a long long history... I hope you excuse me for not trying to retell the whole story again.Let me just refer you to the Bruce Eckel's article that summarizes both points.
-
Nov 9, 2006, 14:18 #9
Originally Posted by neobuddah
-
Nov 10, 2006, 02:28 #10
- Join Date
- Jan 2004
- Location
- Manchester
- Posts
- 32
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I see... but what I'm concerned about is providing a "scaffold" which the other developers in my team must follow. Its all well and good testing whether the parent has a method which you want to use when you're coding the child class, but I'm developing the parent, and need to be able to create an abstract class and say "these are the methods you must overwrite, failure to do so will cause an error". Is this not possible in Ruby?
-
Nov 10, 2006, 10:35 #11
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
It's possible through stupid hacks, but you shouldn't use them. Let the users of your class take care of themselves. Your parent should provide utilities for the children. How (and if) they use them is their business.
-
Nov 10, 2006, 13:07 #12
Originally Posted by neobuddah
Violating your interface or your specs would mean that the end product does not work. That alone should keep conformance to standards high.
-
Nov 11, 2006, 07:33 #13
- Join Date
- Jun 2004
- Location
- Stockholm, Sweden
- Posts
- 148
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Ruby is a language for people who don't require the language/compiler/etc. to hold their hand for them.
Yes, your fellow developers might **** up the implementation of child classes. But then you have bigger problems than the fact that your language of choice doesn't prevent them from ****ing up.If there is a way to overcome the suffering, there is no need to worry; if there is no way to overcome the suffering, there is no point to worry.
- Shantideva
-
Nov 11, 2006, 09:58 #14
- Join Date
- Oct 2006
- Posts
- 85
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stereofrog
-
Nov 11, 2006, 13:48 #15
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Well, following this logic, there is also no mammals (because every mammal is a cat, or a dog, or a cow) and no humans (because they're Tom, or Bob, or Sally). "Animals" is what we call "parent class", not an "abstract" class.
-
Nov 12, 2006, 02:59 #16
- Join Date
- Oct 2006
- Posts
- 85
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
well it would be abstract, because it can't be a concrete object
no matter what you call it, it's still an abstract class.
-
Nov 14, 2006, 08:56 #17
- Join Date
- Jul 2004
- Location
- Oklahoma
- Posts
- 119
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by neobuddah
In Ruby lets say I have the following code:
Code:class A def some_method puts "hello world" end end b = A.new b.some_method
Code:b= A.new b.send(:some_method)
Ruby is a complex language, but you won't get the most out of it's abilities if you just try to re-implement Java/C++ in Ruby.
-
Nov 14, 2006, 16:30 #18
- Join Date
- Jan 2004
- Location
- Manchester
- Posts
- 32
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Sgarissta
I'm considering putting Ruby down for the minute; it seems as though I'm going to have to make a large investment in time before I can simply make apps with it, as I've been able to do with XQuery, XSL, PHP, and other languages.
-
Nov 14, 2006, 16:44 #19
- Join Date
- Jul 2004
- Location
- Oklahoma
- Posts
- 119
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by neobuddah
I'd actually argue that after a couple of weeks with Ruby, you'll feel that it's a much more natural approach OO. It's far from difficult, it's just different. I HIGHLY recommend the Pickaxe book from http://www.pragprog.com, it's pretty much THE reference for how to write Ruby.
I'm considering putting Ruby down for the minute; it seems as though I'm going to have to make a large investment in time before I can simply make apps with it, as I've been able to do with XQuery, XSL, PHP, and other languages.
Good luck, and please feel free to ask any other questions you get as they come up.
-
Nov 15, 2006, 02:45 #20
- Join Date
- Jan 2004
- Location
- Manchester
- Posts
- 32
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Sgarissta
Originally Posted by Sgarissta
Just what I need. I'm sick of walking into bookshops, going to the computer section, and seeing nothing but RoR books. I've got this on order now!
Originally Posted by Sgarissta
Originally Posted by Sgarissta
Thanks again for your response, you've been the best help yet.
-
Nov 15, 2006, 02:58 #21
- Join Date
- Mar 2004
- Location
- Grand Junction, CO
- Posts
- 292
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I had the same idea as you when I first started using Ruby after several years of doing all my work in Java.
What you're encountering is Ruby's duck-typing compared to Java/PHP's static typing.
For example, in Java you may have
Code:public void doSomething(Poppable p) { something = p.pop(); // Do some other stuff }
In Ruby, it'd look like
Code:def do_something(p) p.pop # Do some other stuff end
So the real reason you have interfaces is to catch errors at compile time. Abstract classes serve the same purpose, but of course can also provide some of the implementation, use inversion of control, etc.
I remember reading somewhere in these posts, "How do I make sure that people implement the right methods?"
Basically, you just tell them or let their code blow up. In Java when someone implements an interface but forgets the implement one of the methods, the compiler goes "Hey! You still have work to do!" In Ruby, it's the same thing, but it's the interpretter that does it at runtime instead. If you've written a library, and people pass their own objects into it, you just need to tell them what methods to implement. If they don't read it, they'll find out soon enough, just as if they had used an interface.
One last thing I want to point out is the importance of testing in Ruby. In fact, you'll quickly find that TDD in the Ruby community is HUGE. The reason for that is pretty obvious once you go back up to my "or let the code blow up" comment. If you're writing your tests before your production code, the tests are the ones that blow up. Most people agree it's bad to release untested code. In statically-typed languages the compiler will find simple errors like that, so they don't show up in production. But in dynamic languages it's INSANE to release untested code because you don't know about those errors until it's actually running. That's why you'll see so many Ruby hackers use TDD all the time.
Wow this got a lot longer than I anticipated. Hopefully I helped explain some stuff for you though. Finally, you asked if it makes things easier, and I can say 100% that it does for me. I much prefer duck-typing over interfaces. If some code calls a certain method, you just add it to your class. With interfaces, you'll have to implement all the methods, even if you're only using one method! In the end I think it all boils down to how you work. There are upsides and downsides to each of those approaches, and you have to consider them as only a portion of the upsides and downsides to the languages themselves.
-
Nov 15, 2006, 03:04 #22
- Join Date
- Mar 2004
- Location
- Grand Junction, CO
- Posts
- 292
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Also, one thing I found very illuminating in regards to the Ruby approach was reading Design Patterns, after I had a basic understanding of Ruby. As you read it, you'll find that at least 1/3 of the patterns aren't necessary in Ruby - the problems they solve simply don't exist in Ruby! That's not to say that Ruby is better than Java, but rather that the different approach makes it easy and obvious to write certain types of code, without having to work around the language.
For me, discovering that was a bit of an aha! moment. As I said though, it doesn't make Ruby better, it just illustrates some of the differences. I have no doubt that at some point in the future there will be a language that eliminates some workarounds in Ruby (though I don't know those are yet, only time will tell).
-
Nov 24, 2006, 12:39 #23
- Join Date
- Nov 2006
- Posts
- 7
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
However weird this may sound, I actually find it easier to understand Ruby after understanding the functional programming paradigm. Despite Ruby being totally OO, i didn't really appreciate/understand Ruby's power until i learn Lisp. Transacting from Javascript to Ruby is actually easier than moving from Java to Ruby due to Javascript's metaprogramming capabilities.
I agree with pergesu. Once you start doing Ruby, you realize that your prized patterns are not longer needed.
-
Nov 27, 2006, 08:43 #24
- Join Date
- Jul 2004
- Location
- Oklahoma
- Posts
- 119
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by skruby
I agree with pergesu. Once you start doing Ruby, you realize that your prized patterns are not longer needed.
-
Dec 7, 2006, 15:09 #25
- Join Date
- Jan 2005
- Posts
- 502
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Bookmarks