The Artima Developer Community
Sponsored Link

Weblogs Forum
When Reuse Goes Bad

56 replies on 4 pages. Most recent reply: Jul 30, 2006 9:29 AM by Mike Tocci

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 56 replies on 4 pages [ « | 1 2 3 4 ]
Fireblaze .

Posts: 21
Nickname: fireblaze
Registered: Jul, 2006

Re: When Reuse Goes Bad Posted: Jul 6, 2006 4:58 PM
Reply to this message Reply
Advertisement
> Any code is going to have repetative parts to it. For
> exmple, how many for loops do you have in your code base
> (assuming it's not in a functional language.) You could
> write a for loop helper class that would make it so that
> you only have one for loop in your entire code base. But
> that's stupid. But if you dogmatically follow DRY, you
> might think that is a great idea.

I see your point; I use "No Duplicated Code" principle since it apply to the entrie code base of the project and all people involved.
The answer for repeted for-loop is foreach and Smalltalk blockconstruction.

I agree on the StringBuffer problem, those developer havent even bothered to read the StringBuffer API which states:

String buffers are used by the compiler to implement the binary string concatenation operator +. For example, the code: x = "a" + 4 + "c" is compiled to the equivalent of: x = new StringBuffer().append("a").append(4).append("c").toString()

And the fact that StringBuffer have been replace with StringBuilders in Java 1.5.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: When Reuse Goes Bad Posted: Jul 7, 2006 1:01 AM
Reply to this message Reply
> This is also the value of (good) frameworks. They do
> something really well and allow limited customization by
> providing hooks. The problem arises when people try to
> combine the goal of a library with a framework.
> Frameworks should be pretty focused. The complexity
> y grows exponentially as you add more features and
> customizations.

But isn't that the case for all frameworks? eventually all frameworks will be extended in the way you describe.

Personally I am against frameworks for the reason that they are not extensible.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: When Reuse Goes Bad Posted: Jul 7, 2006 6:05 AM
Reply to this message Reply
> But isn't that the case for all frameworks? eventually all
> frameworks will be extended in the way you describe.

Not necessarily. It depends on how well it is controlled. I'm not saying a framework can't grow and mature. It should jut not try to be al things to all people.

> Personally I am against frameworks for the reason that
> they are not extensible.

Maybe what I mean when I say framework is not clear. The 'problem' with a library is that it is very generic. It helps you but by itself doesn't do much of anything. You still need to write a lot of code to actually make something work. A framework is a lot of system logic that you can plug into.

I see something like the Apache webserver to be a framework. Yes, it's an application but it doesn't really do anything without the user adding to it. Maybe you are thinking of something else when you talk about frameworks?

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: When Reuse Goes Bad Posted: Jul 8, 2006 10:02 AM
Reply to this message Reply
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.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: When Reuse Goes Bad Posted: Jul 8, 2006 4:23 PM
Reply to this message Reply
> 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.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: When Reuse Goes Bad Posted: Jul 10, 2006 12:55 AM
Reply to this message Reply
> 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.


Another kind of reuse that is often bypassed but yields the greatest degree of reuse in programming is that of functional composition...unfortunately only functional languages have that.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: When Reuse Goes Bad Posted: Jul 10, 2006 9:31 AM
Reply to this message Reply
> Another kind of reuse that is often bypassed but yields
> the greatest degree of reuse in programming is that of
> functional composition...unfortunately only functional
> languages have that.

You can do it in C++; much of the STL was designed around the idea of functional composition. And it's even possible to do it in Java, as I show in the Generics chapter of Thinking in Java 4e. However, it's a bit awkward in C++, and quite a contortion in Java. The advantage of functional languages is that they make it easy and reasonable.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: When Reuse Goes Bad Posted: Jul 10, 2006 12:26 PM
Reply to this message Reply
> Another kind of reuse that is often bypassed but yields
> the greatest degree of reuse in programming is that of
> functional composition...unfortunately only functional
> languages have that.

I was looking on Wikipedia for a good explanation of functional composition (mainly because I'm not sure I understand the term adequately) and what is described there is pretty unimpressive to say the least.

Perhaps someone with a good understanding could update that page or direct me to something concise?

thanks.

Dino Octavian

Posts: 15
Nickname: dinoo33
Registered: Jul, 2006

Re: When Reuse Goes Bad Posted: Jul 10, 2006 5:05 PM
Reply to this message Reply
> 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.

Code reuse goes both ways: one client using implementations from multiple providers and one provider supplying an implementation to multiple clients. In general, reversing the direction of dependencies around a base class or an interface is code reuse.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: When Reuse Goes Bad Posted: Jul 11, 2006 2:22 AM
Reply to this message Reply
> > Another kind of reuse that is often bypassed but yields
> > the greatest degree of reuse in programming is that of
> > functional composition...unfortunately only functional
> > languages have that.
>
> I was looking on Wikipedia for a good explanation of
> functional composition (mainly because I'm not sure I
> understand the term adequately) and what is described
> there is pretty unimpressive to say the least.
>
> Perhaps someone with a good understanding could update
> that page or direct me to something concise?
>
> thanks.

Functional composition is when you compose functions out of other functions. For example, the add function is:


function add(x, y) = x + y


Now if I wanted to produce an increment function, I can do it in the classical manner (define a new function) or compose the new function out of add, like this:


function inc(x) = add(x, 1)


Thus we have functional composition. Functional programming languages yield a great deal of code reduction by using functional composition. For example, if you want to double the values of a list, you can either do this:


for it = begin(list1); it != end(list1); ++it) {
int v = *it;
list2.push_back(2 * v);
}


or with functional composition like this:


list1 = map(mul(2), list1);


mul(2) is a composed function which takes one argument and multiplies it by 2; this function is applied by function 'map' over all elements of 'list1' and produces 'list2'.

Functional composition is definitely doable in C++ as the library FC++ proves, but it is kind of hard without language support.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: When Reuse Goes Bad Posted: Jul 11, 2006 7:29 AM
Reply to this message Reply
> Functional composition is when you compose functions out
> of other functions. For example, the add function is:
>
> > function add(x, y) = x + y
>
> Now if I wanted to produce an increment function, I can do
> it in the classical manner (define a new function) or
> compose the new function out of add, like this:
>
> function inc(x) = add(x, 1)
>
> Thus we have functional composition. Functional
> programming languages yield a great deal of code reduction
> by using functional composition. For example, if you want
> to double the values of a list, you can either do this:
>
> for it = begin(list1); it != end(list1); ++it) {
> int v = *it;
> list2.push_back(2 * v);
> }
>
> or with functional composition like this:
>
> list1 = map(mul(2), list1);
>
> mul(2) is a composed function which takes one argument and
> multiplies it by 2; this function is applied by function
> 'map' over all elements of 'list1' and produces 'list2'.

OK, this is what I understood it to be. You can do these things in Java too, it's just (as Bruce wrote) extremely unweidly because you have to define interfaces and implement them in order to get this effect.

The only feature required to make this easy is a function pointer which isn't imcompatible with OO. You just need to treat functions as Objects (which I think Smalltalk does, maybe.)

Mike Tocci

Posts: 2
Nickname: miketocci
Registered: Aug, 2004

Re: When Reuse Goes Bad Posted: Jul 30, 2006 9:29 AM
Reply to this message Reply
I agree that you should code for the specific problem and let the reuse arise when you recognize an emerging pattern. Usually the worst code arises from trying to anticipate every possible future use and force everyone to code to your ulitimate solution.

Flat View: This topic has 56 replies on 4 pages [ « | 1  2  3  4 ]
Topic: When Reuse Goes Bad Previous Topic   Next Topic Topic: The Problem of Overspecification

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use