|
Re: When Reuse Goes Bad
|
Posted: Jul 8, 2006 4:23 PM
|
|
> Here's an interesting question: we talk about code reuse > in terms of libraries and frameworks, but I wonder if > that's all there is. Why shouldn't there be other kinds of > code reuse? I suppose one could argue that patterns are a > kind of design and/or architecture reuse, but why not code > reuse from some different perspective? For example, is > dependency injection just a different kind of framework, > or is it a different way to reuse code? And maybe agents, > which seem very decoupled, could be an effective way to > reuse certain types of code. Or Jini-style systems where > services are dynamically offered and used.
Don't forget the oldest reuse of all, copy and paste! :-)
In python I tend to reuse code by encapsulating functionality into different modules. They aren't big enough to be libraries, but common sets of functions or objects often fit neatly into modules and reusing them is very easy. Just use an import statement. This lets me decide which features a certain program should have on a very granular level. Most of my python projects to this point have been pretty small so I haven't been overwhelmed by lots of import statements or having so many levels of nesting with modules that this has become unwieldy.
I think frameworks and libraries are good grounds for discussion because everybody can relate to them. I've never used Jini at all and as far as I know, Jini is realy the only Jini-style system that is widely available, so I certainly don't have anything to say there.
I vaguely remember agents from my AI class. I think they definitely qualify, but I'll assume that their use is limited. Sadly, probably the most widespread use of agents would be those used by blackhat crackers. http://ebiquity.umbc.edu/blogger/2006/02/19/botnets-are-getting-larger-and-smarter/ Judging from how widespread they are I would say that agents are demonstrably a very effective way to reuse code.
I think mixins would qualify as a way to reuse code as well, since we are exploring different alternatives. This would appear to be a favorite of the Ruby community based on the reading I've done.
|
|