Max Lybbert
Posts: 314
Nickname: mlybbert
Registered: Apr, 2005
|
|
Re: Have Generics Killed Java?
|
Posted: Jul 24, 2010 10:25 AM
|
|
> > Many dynamic languages let you dynamically add methods > > to an object. Really nice for quickly hacking > > existing code, but a maintenance nightmare, because now > > functional contracts are also gone, forcing a developer > > to understand the full codebase to know which part of an > > object's functionality is available at runtime. > > Yeah. It's a dual edge sword, especially if it's done > willy-nilly, anywhere in the code. But best practices > suggest doing such things as close to "up front" as is > practical. > > With modules, such things are nicely encapsulated, too. So > if one module needs an extension to String, and another > module needs a different extension, each is free to add > the extension it needs. > > I understand the potential danger. But there is really no > substitute. When I'm knee deep in code and find that I > really *need* some feature the designers left out of the > original class, it's just not practical to subclass > String, rewrite every method to use the Subclass, and > modify every API to recast incoming and outgoing Strings. > > (I know. I can hear you shuddering. But I love open > classes. But then, I have become a big fan of writing > readable, runnable tests before writing code.)
I'm not sure I understand the issue here. I take it the "subclass String and add your extension" is meant as a strawman. Every programmer I know would write a StringHelper class with a static method that takes a String and provides the functionality.
However, Ruby monkey patching, C# extension methods, C++'s nonfriend free functions, Java static methods in different classes that take the object (eg., the StringHelper class), and similar mechanisms really are syntactic sugar for the same thing: a method that takes an object and does stuff with it. I have a hard time seeing any mechanism as inherently better than the others so long as the code organization doesn't get squirrelly.
|
|