I am using JRuby.
In my Java code, I have a class called Texture, capable of doing some graphic manipulation stuff.
In my Ruby code, I will usually need to draw things, so though I should simply call Java‘s Texture class to do the drawing for me.
However, I ended up making a Ruby class called Texture, which wraps an instance of Java‘s Texture. Somehow like this (just an example, but rather accurate):
class Texture
def initialize
@reference = getMeAnInstanceOfAJavaTexture
end
def draw
@reference.draw
end
def rotate
@reference.rotate
end
def clear
@reference.clear
end
end
As you can see, all this Texture class does is… well, tell a Java Texture to do the job for it. Just that.
Subconsciously, I think I wanted to do it this way because it looks pretty (lol).
Now, getting a bit more technical, a possible advantage I see is that this way I don’t have to interact much with the Java-side of the project. Most of the work I will do will be in Ruby, and maintaining a constant interaction between Ruby and Java can be confusing. If I make a Ruby class that handles this stuff for me, I might feel more comfortable in the future when I have to make like a hundred textures, but instead of interacting a hundred times with Java, I do it with Ruby, my main environment.
Does my reasoning make sense or is it a lame excuse to do something that looks pretty? Or perhaps there is indeed a good reason to do what I just did?
2
Yes, this probably makes sense.
Without such a class, you will need to remember the details of calling out to the Java class at each place where you use this, and get those details right at each place — and even if this is a simple enough use of Java to make this not a burden, those lines of code will “feel” more in the Java idiom than the Ruby idiom, breaking the flow of your program when reading the code. As you find yourself repeating this usage in more places, the value in fixing this grows (i.e. one use of a Java class probably does not justify a wrapepr).
Bottom line: creating a class or method to wrap something you find yourself doing over and over again in a simple interface which feels right in the context of your program can make your code easier to read and maintain.
2