4 ms·

I couldn't agree more. For most projects today, Java is severe overkill where a more high level language is better suited. While I'm not a fan of the Java langu

I couldn't agree more. For most projects today, Java is severe overkill where a more high level language is better suited. While I'm not a fan of the Java language, the Java platform is rock solid and we can all agree it's not going away anytime soon. I'd recommend taking a look at JRuby. It works nicely with Java libraries and loading Java classes. You don't have to deal with dependency injection. Variables aren't typed, values are. Class and instance methods are managed in the same class declaration. Classes can be easily extended. Classes are loaded into constants at runtime - instance objects are created (and constructor called) by calling the "new" method on a class constant (hence no dependency injection required). Class methods can't be called by an instance objects and vice versa. While JRuby would be new to you, it's on a familiar platform. http://jruby.org/ http://jruby.org/

geebee 15y ago
I've been thinking about DI in Ruby, and I've been trying to think of how I'd deal with the absence of DI in Rails. Here's a scenario... Suppose you have two different ways of gaining information about a logged in user. Let's say one goes to LDAP, and the other goes to an RDBMS. You'll be using one or the other depending on where the software is installed. So in Java, you create an interface that defines the methods you'd need to identify and retrieve a User, and you write an LDAP and an RDBMS implementation. The code deals only with the interface, never the implementation directly. So if you want to switch them, you just create a setter (assuming we're using setter injection) and notify your DI container of which implementation should be injected. I definitely get it that in a language with duck typing, there's no need for the interface/implementation gymnastics. You can just pass whatever class you want, and as long as it responds to those method calls, you're golden. So in that sense, DI isn't really an issue. But what about the nice decoupling you get - is there any easy way to swap out a particular implementation in Rails? I'm trying not to think too much in Java here, it's more of a general problem, definitely doesn't mean I'd necessarily want to force DI onto a language that takes a completely different approach to things... Sorry to get so technical here, just seems like you might have some insights into this.
- dutchrapley 15y ago
  Your question is more in regards to Ruby itself, and not Rails. You don't have to swap out implementations in Ruby. Implementations aside, when you do DI in Java, it serves two purposes: 1) instantiates an object and 2) wires it into another object. Remember that in Java, each class is in it's own file. In ruby, you can break classes into several files, but you don't have to. Ruby simply reads class declarations at runtime and instantiates those classes into constants. This means that your classes are always available. If you've defined a class method, you can call SomeClass.some_class_method. If you want to work with an instance of that class, you would call SomeClass.new - to which you can pass args to a constructor. In your instance, you could have three classes - User, UserLdap, and UserDb. You might call User.find( person ), and in the find method you would test your conditional on whether to use UserLdap or UserDb. If you had common methods you wanted to share between the two, you could place those in User and extend that class for use with an instance object. Another option for sharing methods cold be to place them in a module, which you can then include in your class. It's hard for me the make a recommendation for your specific problem at hand. My best advice is to read up and Ruby a little and begin to put what you learn into practice. Here's a couple of recommendations: http://www.humblelittlerubybook.com/ http://www.humblelittlerubybook.com/ http://mislav.uniqpath.com/poignant-guide/ http://mislav.uniqpath.com/poignant-guide/ My light bulb moments were realizing that all class declarations are loaded as constants at runtime and class & instance methods are also managed in the same class declaration. HTH.
  - geebee 15y ago
    Thanks for your reply... I'm kind of following you - unfortunately, I don't know ruby well enough to understand what you mean when you say class declarations are loaded as constants at run time, but I'll definitely look into it. I think there's a third purpose to DI that you didn't mention. The container does instantiate an object and inject it ("wire it") into another object, but the real benefit is that you can externally configure which object to swap in. That last part might matter less in a language that doesn't have to be compiled but it can still be valuable if you have a lot of different implementations that need to be swapped in/out in different deployments. The method you described for person - testing a conditional - do you mean you'd create a method with a conditional, and choose which implementation to use based on that conditional? I've done this, and it certainly works, but it isn't really a placement for DI (this sounds more like a factory method, though again I don't think that those really exist to the same extent in ruby since duck typing is much more flexible than static typing). My problem with this approach (if I understand it right, which I'm not sure I do) is that this would lead to a very long series of conditionals to load the right class. In rails, I'd probably be looking to pull them out into a yaml file (something like the applicationContext file in Spring).

geebee 15y ago

I've been thinking about DI in Ruby, and I've been trying to think of how I'd deal with the absence of DI in Rails. Here's a scenario... Suppose you have two different ways of gaining information about a logged in user. Let's say one goes to LDAP, and the other goes to an RDBMS. You'll be using one or the other depending on where the software is installed. So in Java, you create an interface that defines the methods you'd need to identify and retrieve a User, and you write an LDAP and an RDBMS implementation. The code deals only with the interface, never the implementation directly. So if you want to switch them, you just create a setter (assuming we're using setter injection) and notify your DI container of which implementation should be injected. I definitely get it that in a language with duck typing, there's no need for the interface/implementation gymnastics. You can just pass whatever class you want, and as long as it responds to those method calls, you're golden. So in that sense, DI isn't really an issue. But what about the nice decoupling you get - is there any easy way to swap out a particular implementation in Rails? I'm trying not to think too much in Java here, it's more of a general problem, definitely doesn't mean I'd necessarily want to force DI onto a language that takes a completely different approach to things... Sorry to get so technical here, just seems like you might have some insights into this.

dutchrapley 15y ago
Your question is more in regards to Ruby itself, and not Rails. You don't have to swap out implementations in Ruby. Implementations aside, when you do DI in Java, it serves two purposes: 1) instantiates an object and 2) wires it into another object. Remember that in Java, each class is in it's own file. In ruby, you can break classes into several files, but you don't have to. Ruby simply reads class declarations at runtime and instantiates those classes into constants. This means that your classes are always available. If you've defined a class method, you can call SomeClass.some_class_method. If you want to work with an instance of that class, you would call SomeClass.new - to which you can pass args to a constructor. In your instance, you could have three classes - User, UserLdap, and UserDb. You might call User.find( person ), and in the find method you would test your conditional on whether to use UserLdap or UserDb. If you had common methods you wanted to share between the two, you could place those in User and extend that class for use with an instance object. Another option for sharing methods cold be to place them in a module, which you can then include in your class. It's hard for me the make a recommendation for your specific problem at hand. My best advice is to read up and Ruby a little and begin to put what you learn into practice. Here's a couple of recommendations: http://www.humblelittlerubybook.com/ http://www.humblelittlerubybook.com/ http://mislav.uniqpath.com/poignant-guide/ http://mislav.uniqpath.com/poignant-guide/ My light bulb moments were realizing that all class declarations are loaded as constants at runtime and class & instance methods are also managed in the same class declaration. HTH.
- geebee 15y ago
  Thanks for your reply... I'm kind of following you - unfortunately, I don't know ruby well enough to understand what you mean when you say class declarations are loaded as constants at run time, but I'll definitely look into it. I think there's a third purpose to DI that you didn't mention. The container does instantiate an object and inject it ("wire it") into another object, but the real benefit is that you can externally configure which object to swap in. That last part might matter less in a language that doesn't have to be compiled but it can still be valuable if you have a lot of different implementations that need to be swapped in/out in different deployments. The method you described for person - testing a conditional - do you mean you'd create a method with a conditional, and choose which implementation to use based on that conditional? I've done this, and it certainly works, but it isn't really a placement for DI (this sounds more like a factory method, though again I don't think that those really exist to the same extent in ruby since duck typing is much more flexible than static typing). My problem with this approach (if I understand it right, which I'm not sure I do) is that this would lead to a very long series of conditionals to load the right class. In rails, I'd probably be looking to pull them out into a yaml file (something like the applicationContext file in Spring).