Have you ever had a class so choke full of interrelated data and function members that had trouble avoiding name clashes between the two. Of course it's a rare problem when you're in full control of the members, but when you're designing extensible classes, it become a major issue and you have to resort to some less-than-lovely work around.
Let me give you a simple scenario.
class Package # Release date # attr :release
# Release the package. # def release puts "Telling the world on #{@release}..." # ... end end
The issue here is clear. On one hand, we want to use release as a noun to represent the date of release. On the other, we want to use it as a verb for releasing the package to the world. Of course, under completely isolated circumstances we could just change one of the names and deal. But when we are working on the basis of extensibility, where these and additional data or functional members may be added readily, say via a plug-in system, then a solution is not as simple.
So what can we do? The bottom line is that in some way or another the two member types must be distinguished from one another.
One could transform one set of the members with a slightly different via a uniform naming convention. For instance, all data memebers could start with "my_", so release-as-date could be my_release. Ruby actually makes this it a bit nicer b/c we can use '?' or '!' prepended to method names. So one fair solution would be using release?.
class Package
def release? @release end
def release puts "Telling the world on #{release?}..." #... end
end
It's not a perfect solution however, especially as matter of convention. It goes against the grian. '?' typically indicates a true/false query, '!' an in place or ricky action. Consider how others will "smell" your code when they see a question mark for every reference to a data member.
The other more traditional solution is to use delegation. In this case we make a subclass for either or both of the member types. For instance:
class Package
attr :data
def initialize @data = Data.new end
class Data attr :release end
def release puts "Telling to the world on #{data.release}..." #... end
end
Albeit a bit longer. It works very well. Delegation is a powerful design pattern. One could even emulate the former solution via method_missing, trapping method calls that end in '?' and rerouting them to @data. Another advantage is that we can readily pass around the data independently of the functional members. On the flip side however, we are regulated to this special data.member interface. and likewise any reverse access by the data members to the functional members, if ever needed, would require us to also pass a reference to the Package instance into the Data instance.
In considering all this of course, it becomes apparent that Ruby already has a means of distinguishing data members from functional members via instance variables. Clearly @release references the date. But Ruby does not give us the power to treat "instance members" publicly or programaticlly. We can't, for instance, use project.@release to access the release date. Nor can we wrap data members in order to massage their data, say like:
def @release super || Time.now end public :@release
I'm sure to many this seems like a terrible notion. But I think careful consideration at least warrants the fair question. "Is a distinct separation between data and functional members useful?" The mere existence of instance variables indicates that the distinction is in fact useful. In contrast data members could have been made indistinguishable from functional members, or local variable persistence could be used in their stay. So if the distinction is useful, why hide public access to data members behind functional members acting as mini-delegates?
How would our solution pane out if data members were in fact accessible? Interestingly it could look exactly just like the original example. Public access to the release date however would simply come via project.@release or preferably even project@release. And there would be no need for any name (mis)conventions or special-interface delegation.
Of course let's be honest here. '@' itself is the Special Delegate of State to the Ruby Church's social functions. Separation of Church and State be damned! ;)
Previous Topic
