Weblogs Forum - Software Reusability: Myth Or Reality?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Software Reusability: Myth Or Reality?

46 replies on 4 pages. Most recent reply: Apr 14, 2010 6:20 AM by Irina Kleingon

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 46 replies on 4 pages [ « | 1 2 3 4 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 12:02 PM

Reply

Advertisement

> > I have yet to see the glaring benefit of inheritance.
> > There are plenty of holes in the idea and I think using
> > g it as a centerpiece of design almost invariably leads
> to
> > a hardened(difficult to change/extend) architecture.
> > ( see:
> http://okmij.org/ftp/Computation/Subtyping/#Problem
> > )
>
> Designing with inheritance in mind can give you an API
> that is easier/ more obvious to use and navigate and in
> which you can have strong guarantees about the contract.
> At the cost of flexibility, yes, though that flexibility
> may be just as well YAGNI.

I think the quote above was in reference to the comments I was making about reuse via inheritance vs. reuse via composition. Just to be clear, that's really only about inheritance of implementation. Inheritance of specification (ala interfaces) is pretty wee accepted as being beneficial. It sounds like that is what you are talking about here.

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 12:57 PM

Reply

I am very wary of the term re-use. I think it is often abused in this context.

Possible meanings:
* Library code: we use a library, not re-use it.
* Code re-use: copy & paste? Arghh...
* Recycling: use again after processing. Does normally apply only to materials that wear out or get consumed. Software does not wear out.
* To use something again in its original form for the same or different purpose: Dangerous. Many of the original design constraints/compromises/assumptions no longer apply. See Ariane accident.

I prefer to get my code to work properly for its intended purpose, but don't worry too much about generalising it (yet) for potential other purposes (what would they be?).
Essentially, KISS and YAGNI. Promoting the code to the level of library code is actually a lot of effort, and may not pay off.

My conclusion: Avoid the term re-use as it is rather meaningless in a software context and speak more concisely of what you actually want to do.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 1:17 PM

Reply

> Wrong! Shortest route is easy because it's well-defined.

While "well-defined" may be a necessary condition for a problem being easy it certainly isn't sufficient. For example, try finding the longest route between two points in a graph without repeating any arc. Just as well defined a problem as the shortest route (the problem only differs in one word), but it is much harder to solve.

Jukka Tamminen

Posts: 1
Nickname: jukka
Registered: Jan, 2007

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 1:48 PM

Reply

Reuse prohibited
We have used the concept of ”reuse” for a very long time within IT. Ti has annoyed me really for long time. When objects where booming in early 90’s it was very popular today one comes across this term quite rarely. This was such a casino.

The following is quoted from Kevlin Henney analysis of the term (his presentation at JAOO conference most probably 2003). Some of the conclusions are mine.

But first the story (well this is actually mine)

Let us start from the word “use”. When I have bought myself a jacket and I put it on as I am leaving home and going to my office. I say that I use my jacket. When I do the same thing on next morning I repeat saying I use the jacket – and I don’t call this reuse! If I like my clothes I then to use them very long (years). But one day it is outworn and starts to look awfully ridiculous on me and my wife says: You are definitely not going to use that jacket any more!

So the usage of this jacket has come to its end now! It just happens that at the same time we have going on an extension work of our house. I have heard all stuff of ecology and global warming and as we need a door mat for the workmen at the new entrance door I decide to reuse my jacket! First I cut the sleeves off and here I have a new door mat.

Well this solution has its drawback the jacket has a silk lining which makes my mat slippery. It is not quite even on the floor, but is is better than nothing!

The analysis: The term use we use as long as we use the thing for something that it was designed and produced for. When we start to use it for something else, that it was not designed an produced we start to talk of reuse!

Conclusion: reuse is by definition undersigned unplanned use! So it is actually a logical contradiction to use a concept of designing reuse. There simply can not be such thing at all!

The real aim behind this all is clearly valuable but it has been expressed extremely poorly.
This of course is: implement once use everywhere ( as the analysis clearly shows).

To do this however has proved to be a tuff thing to archive. The only way that I have seen people to succeed in this is to use OO-approach. Here one has to isolate an abstract domain model which is free from all aspect of application. This way one can derive to application wise invariant domain behaviour. One needs to implement this just ones – as it is invariant intersection of domain behaviour over all application within an organisation!

This boils down to what Grady Booch says in his book: Object-Oriented Design (1990) on the page 16 about functional decomposition and collaboration of agents.

So the final conclusion is: Prohibit reuse, because it is always an indication of total lack of professional skills and talent!

The most prominent form of reuse in coding is ‘cut and paste’ and it is OK if is use as speeded up hand writing.

Jukka Tamminen
www.kolumbus.fi/tamminen.jukka

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 1:49 PM

Reply

> I prefer to get my code to work properly for its intended
> purpose, but don't worry too much about generalising it
> (yet) for potential other purposes (what would they be?).
> Essentially, KISS and YAGNI. Promoting the code to the
> level of library code is actually a lot of effort, and may
> not pay off.

I agree with this but I think we need to be careful with how it is stated. Writing code so that it can be easily generalized later is, IMO, very much worth the effort (which is low.) A perfect example of the kind of thing I am talking about is avoiding hard-coding literals. While this has benefits in other areas, it's really crucial in refitting code to be more general.

I think a lot of people see YAGNI and think that means they can write monolithic code.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 1:54 PM

Reply

> > Wrong! Shortest route is easy because it's
> well-defined.
>
> While "well-defined" may be a necessary condition for a
> problem being easy it certainly isn't sufficient. For
> example, try finding the longest route between two points
> in a graph without repeating any arc. Just as well defined
> a problem as the shortest route (the problem only differs
> in one word), but it is much harder to solve.

Hard as in computationally complex or hard as in hard to code a "correct" solution (albeit one that will crash on all but trivial graphs or will run until the end of time)?

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 1:54 PM

Reply

>For example, a few of the Swing components are coupled to the Vector class. This is unnecessary coupling

Maybe it's a coding style thing, but I disagree here. Coupling to the Java Collections isn't bad, where it makes sense. (Well, I hate that they are coupled to ancient Vector, but I'd like to see them couple to List.)

Instead of

int[] getSelectedItems() I'd prefer
Object[] getSelectedValues() (which some Swing things offer)
but I'd most prefer
Collection<T> getSelectedThings() (which none offer)

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 3:45 PM

Reply

> >For example, a few of the Swing components are coupled to
> the Vector class. This is unnecessary coupling
>
> Maybe it's a coding style thing, but I disagree here.
> Coupling to the Java Collections isn't bad, where it
> t makes sense. (Well, I hate that they are coupled to
> ancient Vector, but I'd like to see them couple to List.)
>
> Instead of
>
> int[] getSelectedItems() I'd prefer
> Object[] getSelectedValues() (which some Swing things
> offer)
> but I'd most prefer
> Collection<T> getSelectedThings() (which none offer)

+1

I would argue that coupling to an interface from the collections classes is far more loosely coupled than using arrays.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 4:45 PM

Reply

> >For example, a few of the Swing components are coupled to
> the Vector class. This is unnecessary coupling
>
> Maybe it's a coding style thing, but I disagree here.
> Coupling to the Java Collections isn't bad, where it
> t makes sense. (Well, I hate that they are coupled to
> ancient Vector, but I'd like to see them couple to List.)

My point was that they should be coupled to the List interface and not the Vector class. I shouldn't have assumed you'd know what I meant.

I can't seem to find anything that gives me and info on the time-lines of when Swing and the Collections interfaces were added to the JDK but in any event this is an annoying (but not a terribly serious) problem. Maybe it's not a great example but it's the best I could come up with without a lengthy explanation.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 7:23 PM

Reply

> > > That's why infrastructure stuff is easier to reuse,
> and
> > > business stuff is harder. The meaning of "find the
> > > shortest route from machine A to machine B" is much
> > easier
> > > to define crisply than "find the best vendor for
> > shipping
> > > services".
> >
> > In this case the shortest route is easier to define
> > because there are well-known algorithms for it, while
> > there might not be such algorithms for shipping
> services.
> > Nevertheless, you can precisely define _any_ algorithm,
> > given enough time and sufficient understanding of the
> > problem.
>
> Wrong! Shortest route is easy because it's well-defined.
>
> 'Best vendor for shipping services' is hard, because it's
> not well-defined. The problem is the word 'Best', for
> which the business logic can change, and even vary with
> what you want to ship. 'Best' = 'Cheapest'? 'Most
> reliable'? 'Is insured'? 'Fastest'?
>
> Depends on whether you're shipping eggs, televisions, demo
> CDs, etc, and vendor's changing prices...
>
> I think this is the basic problem with re-using business
> logic. Business logic is just not naturally re-usable,
> because its always changing. Algorithms and abstractions
> are reusable - when they are phrased in the right terms.

A problem is not well-defined by itself! It is well-defined because someone has defined it and possibly solved it already (in the case of shortest paths the graph theory had been used to define the problem). This might be very simple or very difficult for a problem, but once you defined it correctly all that's left to do is to solve it (if it's solvable). Just because the shipping services problem might not have been well-defined yet it does not mean that it's impossible to do so.

Russell Lane

Posts: 4
Nickname: wrl
Registered: Jan, 2007

Re: Software Reusability: Myth Or Reality?

Posted: Jan 30, 2007 9:57 AM

Reply

"Just because the shipping services problem might not have been well-defined yet it does not mean that it's impossible to do so."

That's true. It is, however, hard to define the shipping services problem in a way that is equally meaningful and useful to all of the people who need to use shipping services.

So, a solution based on one definition of the problem will not be reusable by an organization that has a different definition of the problem. Not because of the technology, but because of the meaning.

That brings me back to my original point, and my purpose in giving the examples I gave.

Reuse can be enabled by technology, but technology does not make it possible or impossible. What makes reuse possible is a shared understanding of what the problem is that you're trying to solve. It requires a common model of the domain you are working in.

No shared understanding of the domain, no reuse.

Thanks -

Tim LS

Posts: 37
Nickname: parchandri
Registered: Jul, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 30, 2007 6:01 PM

Reply

> > Wrong! Shortest route is easy because it's
> well-defined.
>
> While "well-defined" may be a necessary condition for a
> problem being easy it certainly isn't sufficient. For
> example, try finding the longest route between two points
> in a graph without repeating any arc. Just as well defined
> a problem as the shortest route (the problem only differs
> in one word), but it is much harder to solve.

Sorry, you're right that it isn't really easier to solve.
But it looks equally easy to re-use.

Kevlin Henney

Posts: 22
Nickname: kevlin
Registered: Apr, 2003

Re: Software Reusability: Myth Or Reality?

Posted: Feb 3, 2007 8:08 AM

Reply

Yes, much of what is held to be true of software reuse is a myth, and it starts with the misuse of the term. To quote an article I wrote five years ago on this topic, "Reuse has proven to be a false idol to worship. It is at best an ill-defined term, and at worst an incorrect one."

(http://www.two-sdg.demon.co.uk/curbralan/papers/minimalism/TheImperialClothingCrisis.html)

Rajiv Narula

Posts: 167
Nickname: rajivn
Registered: Feb, 2007

Re: Software Reusability: Myth Or Reality?

Posted: Feb 6, 2007 7:53 PM

Reply

Hey Arash
I think you have come across the dead elephant in the room. The one everyone knows is there but no one wants to talk about it

I am however still a firm believer on the power of reusability

My top two reeasons why most of the software components are not reusable

1) Bulky Components :Take small bites. Easier to chew and better for digestion. If the component does a lot - it becomes difficult to reuse it just to get a part of functionality that it does.

2) Chain reaction : If a component is to be reused- it shouldnt have to come with its own army of components which have to be reused along with it even if they are not needed

To answer your two questions

1) Yes it should be possible to train to reuse components and in turn write reusable components and to keep aside the programmers-ego which often prompts us to write from scratch rather than reuse something

2) Yes reusability has to be part of the intent. It doesnt come easily. You have to keep a wiggle room in the component
I wouldnt expect a component to be reusable across applications without changing a single line of code
That IMO is not a practical demand. If i can reuse a component by changing some code so that i am able to reuse 80% of teh code- i will be satisfied

allen john

Posts: 1
Nickname: auser
Registered: Nov, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Feb 9, 2007 5:42 PM

Reply

You do reuse alot, just don't feel that.

Flat View: This topic has 46 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic

Sponsored Links

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