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 | » ]

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 26, 2007 12:01 PM

Definitively reality. If you want.

I don't think lots of up-front planning is very helpful though. Unless you already know other projects that will use the same functionality or have a clearly defined - and existing - target audience, up-front planning probably will result in focussing on the wrong abstractions and over-generalizing.

Where reuse definitively works is with widget frameworks. Working with the Wicket framework is a big enabler for me, where I have access to more and more high-level widgets (in-house and public), like wizards, breadcrumb panels but also more business specific ones, like for instance a user selection component (with a search box, filtering, paging, sorting, etc).

Often discussions about reuse focus on reuse across projects. To me the real interesting thing is reuse in the same project. Not being able to create reusable widgets in projects was a major problem for projects I did in the past (we used Struts and other model 2 frameworks). It resulted in lots of code duplication, and due to the lack of options when it came to encapsulation, refactoring *anything* related to the user interface was pure hell and resulted in bug barrages.

What using a framework that supports reusable widgets did for me/ my projects is that the quality of the delivered applications increased dramatically, mostly due to being able to reuse widgets that already got lots of testing hours from other parts of the project and the fact that refactoring isn't a problem anymore (though less about reusability and more about encapsulation in general, I believe the subjects touch each other here).

Concerning reusable services... I've seen some pretty horrible examples in the past of pushing SOA too far, where a load of services were being developed because 'they probably would be needed someday', and seen some services that were so horribly over-designed that they were awkward to use and had efficiency problems. However, if you are smart enough about it, creating reusable services should definitively be doable. Think about all the public APIs that are starting to pop up around many 2.0 web sites.

Russell Lane

Posts: 4
Nickname: wrl
Registered: Jan, 2007

Re: Software Reusability: Myth Or Reality?

Posted: Jan 26, 2007 12:17 PM

Great post! My experience is similar to yours.

My observation is that reuse depends on a shared understanding of the domain. If you don't agree about what a component represents and what it does -- that is, what the component and the interfaces it exposes *mean* -- there won't be reuse, no matter what technology it is built with or how well it is written.

Building stuff so that it is not highly coupled, so that it is well documented, so that the interfaces it exposes are easy to understand and use, all *facilitate* reuse. They make things *easier* to reuse.

The thing that makes reuse possible or impossible, however, is how closely the *meaning* of the component and its interfaces matches what you need.

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".

That's also why simpler, more atomic things are easier to reuse -- components that embody more complex semantics have an inherently smaller range of possible application. The number of situations in which you WashDishes is, inherently, larger than the number of situations in which you SoakAndWashAndDry them.

The crucial issue in reuse is semantics, not technology.

Thanks!

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 26, 2007 3:48 PM

> 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.

> That's also why simpler, more atomic things are easier to
> reuse -- components that embody more complex semantics
> have an inherently smaller range of possible application.
> The number of situations in which you WashDishes is,
> , inherently, larger than the number of situations in
> which you SoakAndWashAndDry them.
>
> The crucial issue in reuse is semantics, not technology.
>
> Thanks!

I agree with this completely. Also, I think that functional requirements are actually different for a component that needs to be reusable than those for a component with the specific purpose, although both are built to solve the same problem. In the dishes example, the WashDishes component might be built with the assumption that the machine is always connected to a water pipe, while the more general approach might require that the machine checks if there is water and, if not, turn on a warning light, or something. Basically, the more general a component needs to be the fewer assumptions there are.

David Medlock

Posts: 11
Nickname: dmedlock
Registered: Jun, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 27, 2007 11:04 AM

I have yet to see the glaring benefit of inheritance. There are plenty of holes in the idea and I think using 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 )

The only moderately successful inheritance appears to be templating objects for libraries and frameworks.(not deep hierearchies but broad ones)

My view of extendability has long been data-driven design. Two great examples of this are HTML browsers and compilers. Once we agree on the data to be processed(as well as a common format) then extending the design occurs behind the scenes so to speak.

For instance a browser which does not have all the CSS2 features will (for the most part)run a CSS2 webpage. At the same time a browser with improved features(e.g. widget improvements) may be able to apply them to old pages as well.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 27, 2007 7:06 PM

I think all the advice to avoid coupling is slightly misleading. If your code is coupled to no business object, hardware, or file format that a subsequent programmer would use, why would they reuse your code?

So, you want to be coupled to a small set of gizmos that somebody else would want to use. This is very hard to anticipate and get right. In my experience, code to read a proprietary file format or communicate with custom hardware is most likely to be reused.

Tim LS

Posts: 37
Nickname: parchandri
Registered: Jul, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 28, 2007 9:31 PM

> > 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.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 3:48 AM

> 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
> )
>

Reusability is not a myth. We all use the O/S services, the language's SDKs, third party libraries, databases etc. From the 100% of the code participating in an application, only 10% is perhaps made by us...the rest comes from external vendors.

Regarding subtyping, one of the errors of OO is that it casts in stone the typing relationships. It would be much better if interfaces were constructed only when needed, at run-time, based on signature compatibility. This hardcoding of types into classes is what makes classes difficult to reuse.

For example, it would be much easier to express the byte stream concept if we could do the following:


class Socket {
    byte read() {
        //bla bla implementation
    }
}

class File {
    byte read() {
        //bla bla implementation
    }
}

class SerialPort {
    byte read() {
        //bla bla implementation
    }
}

interface ByteStream {
    byte read();
}

void print100Bytes(ByteStream s) {
    for(int i = 0; i < 100; ++i) {
        println(s.read());
    }
}

print100Bytes(new Socket("127.0.0.1", 1000));
print100Bytes(new File("test.txt"));
print100Bytes(new SerialPort("COM1", 36400));

In the above example, the classes 'Socket', 'File' and 'SerialPort' belong in unrelated domains, they can possibly come from different vendors with no universal coordinator between themselves. But it is easy to reuse them, because the concept of 'ByteStream' is not hardcoded in their definition.

Structural subtyping (that's what is called) can also help performance a bit. In Java, interface methods are discovered at run-time by iterating the array of methods and searching for the method with the interface's id. With structural subtyping, interfaces are tuples of object + vtable, and the vtable can be constructed from method pointers from types known at the point of declaration, so the need to iterate over arrays of methods is not needed.

Structural subtyping looks a lot like Haskell's type classes.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 6:07 AM

> I think all the advice to avoid coupling is
> slightly misleading. If your code is coupled to no
> business object, hardware, or file format that a
> subsequent programmer would use, why would they reuse your
> code?

That's exactly why you should avoid coupling in the first place. It makes the code non-reusable.

The point is that you don't want to couple two things that aren't inherently tied together. For example, let's say you wrote a gui from scratch. You don't want to couple the tree view to the file system. There are many other types of data that could be viewable in a tree view.

The other thing to mention is that you want to minimize coupling, not necessarily always avoid it. This makes it a lot easier to refactor the code later.

bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 7:59 AM

I read Martin Fowler's Analysis Patterns book. And it made me wonder if the book could not be transformed into a reusable library.

Sure, a lot of business rules vary from place to place, but some fundamental patterns are the same. Couldn't we have libraries for generally accepted accounting practices and stuff like that? Couldn't a lot of basic business code be the same?

I think the reason we haven't achieved reusability is that there aren't these libraries around to make our life easier. Someone would need to do it. But if it makes us more productive, we'll use it!

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 8:11 AM

> Sure, a lot of business rules vary from place to place,
> but some fundamental patterns are the same. Couldn't we
> have libraries for generally accepted accounting practices
> and stuff like that? Couldn't a lot of basic business code
> be the same?

Two problems with that.

1. Generally accepted accounting practices change over time.

2. If everyone uses the same business logic i.e. runs their business the way the libraries writers thought it should be run, it leaves little room for competitive advantage through innovate approaches.

The last one to me is the big thing I think that a lot of people miss. When you buy commercial software to run your business, you are often running your business the way the software dictates. You are basically removing your ability to flank your competitors. And if you get the vendor to (at invariably exorbitant prices) to customize the software to fit your new business model, they are generally going to turn around and sell it to your competitors.

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 8:13 AM

Arash, thanks for sharing your insights into what appears (to you and me at least) to be a widespread shortcoming in Java development organizations. Here are some thoughts on the very interesting questions you raised:

> 1. Is reusability something that one can train for? Is this something that can be taught in school.

Yes and yes, though I think this really gets to an even more fundamental question: Are Java developers sufficiently trained in OO Design? Without a proper grounding in design principles, developers tend to write code that's difficult or impossible to reuse. Worse, they generally fail to think in terms of layers, components, etc.. -- in fact, all too often, little thought seems to be given to anything beyond "How should I write this algorithm?"

As a result, much of the application code I've seen in real-world projects borders on the unmaintainable. Sadly, developers who are unable or unwilling to write maintainable (much less, flexible, extensible, etc.) code are in no danger of creating anything reusable, nor are they likely to even consider reuse.

2. Is reusability for key business objects and application modules a concept that has to be dictated as a requirement?
I don't think so. I think the issue here is really one of leadership. Developers who are capable of noticing opportunities for reuse and able to exploit them effectively will generally do so without any urging. Those who are incapable will only make a hash of things if they are forced to make the attempt due to requirements.

Also, I have to say that I'm astonished that so many Java developers seem to think that using an open source framework or other third party product somehow constitutes reuse. To my mind, usage of third-party projects is 'use,' not 'reuse.' (And for that reason the old mechanic may be unable to provide much insight, since scavenging parts isn't all that analagous to creating reusable components).

Kalyan Abbaraju

Posts: 1
Nickname: kvgopal
Registered: Jan, 2007

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 9:26 AM

I would rather say that software reuse is beyond a code re-use. Thinking about "code reuse only" limits the scope of modern software engineering. In my opinion software reuse is coming in various flavours: concept reuse, service or service component reuse, pure code reuse.
Concept Reuse: Primarily reuse of the architecture where in one copies the architecture from old architecture either entirely or partially. Ofcourse one may get new ideas while copying the architecture which can supply spicy taste to the old architecture. This is one of the ways one can derive a new architectural patterns.
Service or Service component Reuse: This is nothing but re-use of a service from an existing system. This requires careful planning of the services during initial architecture and design. But it might happen that service is not in a reusable shape. So, in this case one need to opt for refactoring the existing system. In this case continuous re-factoring priniciples suggested by XP programming are going to aid in creating re-usable pieces
Pure code Reuse: Here we can use lot of object oriented principles from any OOAD book. It requires more careful planning and believe me "it is an extremely difficult task" compared to the above two. This is especially true because we are not really sure to what direction our system is going evolve in the next 2 years. This is especially true in case of large projects where in the old system is a legacy system and we have to perform a technology shift. Also in most of the areas reuse is always followed by abstraction (either an abstract class or interface). Always we need to consider a fact that abstraction is one primary key factor which is going to dictate our code reusability in the future. And also inheritance and composition are second level key factors for better re-usable design. But due to this flexibility you may need to pay for rest of the non-functional requirements of the system. Also following are the two principles I believe in.
1. Walk through your design pattern catalogue before doing a design.
2. Code copy is not always a sin (ofcourse with the prior permission of original author). Some times during the copy and paste you may get new ideas for developing a better system.

Kalyan

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 10:44 AM

> The point is that you don't want to couple two things that
> aren't inherently tied together. For example, let's say
> you wrote a gui from scratch. You don't want to couple
> the tree view to the file system. There are many other
> types of data that could be viewable in a tree view.

Sure you want a generic Tree. But, you also want a file-specific tree like JFileChooser.

Coupling to something lots of people use, and which is fairly well defined and stable (like file systems) leads to reusability.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 11:24 AM

> > The point is that you don't want to couple two things
> that
> > aren't inherently tied together. For example, let's
> say
> > you wrote a gui from scratch. You don't want to couple
> > the tree view to the file system. There are many other
> > types of data that could be viewable in a tree view.
>
>
> Sure you want a generic Tree. But, you also want a
> file-specific tree like JFileChooser.

Yes but that's not really the point. JFileChooser reuses the tree view component. The tree view is not coupled to JFileChooser. In turn, JFileChooser is not coupled to any specific application.

> Coupling to something lots of people use, and which is
> fairly well defined and stable (like file systems) leads
> to reusability.

Again, you can't eliminate coupling. But you can minimize it. In the examples above, coupling is only in one direction. Often (but not always) bad coupling is in two directions. When both parts of the interaction depend on each other, it's often difficult, if not impossible to reuse them. Interfaces (or pure virtual classes) make it easier to decouple code from specific implementations. For example, a few of the Swing components are coupled to the Vector class. This is unnecessary coupling and should be avoided. These are effective reuse strategies that all involve minimizing coupling.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: Software Reusability: Myth Or Reality?

Posted: Jan 29, 2007 11:45 AM

> 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 it is more productive to use your brains rather than repeating the mantra of others and apply the approach you think works best for a given situation; inheritance is not evil per se.

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

Previous Topic

Next Topic