Weblogs Forum - When Reuse Goes Bad

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

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

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

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

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: When Reuse Goes Bad

Posted: Jul 4, 2006 8:19 AM

I think this a great topic.

It seems to me that there is a trend these days toward making ordinary projects into mini-frameworks. OOD has become as much about modeling the future is it is about modeling the immediate problem you're trying to solve.

If your company is profitable and has a reliable income, incorporating flexibility can save money if you do it right. If your company is a start-up however, making an extensible design may be a luxury you can't afford.

We've been discussing the front-end of the bad resue issue, but there's the back-end as well: overuse of otherwise good frameworks. With so many open source frameworks available, there is a tendency now to incorporate too many of them into a project.

Developers want to incorporate some functionality into their application and find an open source project that is a superset of that functionality and just incorporate the whole thing.

The result is explosive growth in the amount of code such applications have to support and a larger percentage of nearly dead code.

Dino Octavian

Posts: 15
Nickname: dinoo33
Registered: Jul, 2006

Re: When Reuse Goes Bad

Posted: Jul 4, 2006 12:18 PM

> I think this is exactly what is the advantage of Domain
> Specific languages.

Why not build a Domain Specific framework?

If executed properly it can work as a simpler substitute of a language (which needs a lot of supporting artifacts: compilers, debugers, productivity tools, etc).

Back to the framework-itis, in the java and/or .net development contexts there is so much framework code readily available that it makes little sense to build frameworks for anything but Domain Specific. However, a lot of programmers suffer of the "not-written-by-me" syndrome. Therefore instead of focusing on results, they'd rather carve yet another framework, taking pleasure in re-inventing the wheel for over and over again.

Reuse derives from efficiency in development. IMHO, efficiency in development is what should drive code reuse and never the other way around.

David Medlock

Posts: 11
Nickname: dmedlock
Registered: Jun, 2006

Re: When Reuse Goes Bad

Posted: Jul 4, 2006 6:51 PM

> > I think this is exactly what is the advantage of Domain
> > Specific languages.
>
> Why not build a Domain Specific framework?
>
> If executed properly it can work as a simpler substitute
> of a language (which needs a lot of supporting artifacts:
> compilers, debugers, productivity tools, etc).
>

I think we differ on that term. I do not mean something even remotely that complex.

How about a document(oftimes JSON or XML) which describes the steps necessary to the task and the relevant details.

Then write a program to read the document and execute the steps.

At this point you can embellish the parameters available in the document.

The most famous DSL is surely REGEX expressions.

http://en.wikipedia.org/wiki/Domain-specific_programming_language

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: When Reuse Goes Bad

Posted: Jul 4, 2006 11:25 PM

> Another way to approach the problem is to write small
> frameworks that are highly decoupled.
If these frameworks are actually used independently, this may be a good idea.

However, if you just anticipate that these frameworks may be used independently, it is better to write one framework.
You can still refactor it when there is a need to use just a part of it.

I have done this mistake myself. I wrote a XUL interpreter (a XML GUI language) with CSS support using Swing.
I wrote the following independent layers:
1) A generic CSS engine
2) A mechanism that applies CSS to Swing
3) A XUL engine using CSS
The separate parts seemed to be a good architecture at first - even though nobody used 1 or 2 independendly. The code is was well structured.

With additional requirements, however, I had to change 2 and 3 in a way that 2 could no longer be feasably used without 3 - in other words they are now tighly coupled.
It might have never been practical to use any of the parts by itself, because nobody has tried it yet.

So now, I have the worst of both:
1) Some requirements make me change more than one part, sometimes even the interfaces between the parts.
2) The parts cannot be used alone, because they are hightly coupled.

Jörg Gottschling

Posts: 4
Nickname: jogix
Registered: Sep, 2005

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 12:34 AM

Hm,... another occurrence of framework-itis is: Everybody in the team builds a framework for himself, but for the same problem. I am faced with that at the moment, organizing a meeting tomorrow to fix this. Another problem is, that these fraeworks are build to use a commercial application-framework. I should say: To build around it. I build one myself, showing it to the others, publishing it for the whole team, provindig examples, etc.

No I have to look, why they do not use it, but building their own, solving the same problems, sometimes the same way.

I don't like to use it my own, most the time, because I want to use the original framework directly:

Like every good framework, it had several possibilities to reuse code in different positions. So you can implement reusable components for the GUI/View or the controller (MVC). I walked around the team last weak an looked how everybody solves the common problems. There are some which build such an component for everything, but most the time they can not be reused without modifications, because they are so specialised. Others build super generic componets, which are hard to configure. (Like mentioned above by others.) There are also some colleagues which do not want to build an use potential resuable components at all.

Wierd? I think it's mainly because the main application framework, was never really documented. You cann do some nice things with a grafical designer, but everything beyond that is "guess, try and error". Yes, it is a framework, but it is hard to reuse. I think EJB are simplier to use, or may be, you can just get more documentation, tuturials, etc. about them.

I'll try starting to fix some of the (meta) problems tommorrow. I think this will be lift off towards a philosophic discussion ...

Russ Freeman

Posts: 7
Nickname: freemanr
Registered: Jul, 2006

Not invented here

Posted: Jul 5, 2006 1:03 AM

Sounds like the "not invented here" syndrome, where a developer feels to need to reinvent something because they didn't create it in the first place. Indeed, I've done it myself, but since learnt to be more respective and open to other developer's efforts and being more focused on delivering something as a team rather than as a heroic single developer.

Jörg Gottschling

Posts: 4
Nickname: jogix
Registered: Sep, 2005

Re: Not invented here

Posted: Jul 5, 2006 1:11 AM

> Sounds like the "not invented here" syndrome, ...

Yes, I think this is also part of it.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 1:33 AM

> > Another way to approach the problem is to write small
> > frameworks that are highly decoupled.
>
> The danger here is in overly decoupling the design. When
> do you know you have "decoupled" enough? It's easy to
> create a totally decoupled framework that is hard to use
> in context. This is why I think frameworks realistically
> fall out of existing code rather than created afresh.

Components/modules are highly decoupled when they do not refer to each other...of course there should be an easy way to combine them. In other words, components of a framework should only be conceptually related, not algorithmically (if it is possible).

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 7:07 AM

> Components/modules are highly decoupled when they do not
> refer to each other...of course there should be an easy
> way to combine them. In other words, components of a
> framework should only be conceptually related, not
> algorithmically (if it is possible).

The problem with that, which I'll guess is the case Bruce talked about in the original post, is that this is really hard to do in practice. I've never successfully built a framework. I've put together plenty of libraries and a couple of DSL's, but I hope to never build my own framework. I have two reasons for saying that.

1: There are a lot of good frameworks out there already. I'm more than happy to make use of other's work. One can see farther standing on the shoulders of giants.

2: I've yet to solve a problem that lends itself to a generic enough model that a framework would be at all useful.

I know there are plenty of people out there solving big problems that may require a framework. I'm just not one of them.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 8:15 AM

> I hope to never build my own framework.

It occurs to me that one might learn a lot about the ideas behind frameworks and the design issues by building one or two. Before the C++ STL, I learned a great deal about collection classes by building them. However I was happy to give them up once the STL appeared.

Perhaps it's a good idea to build a framework or two, but to be very conservative about inflicting your first attempts on other people.

Fireblaze .

Posts: 21
Nickname: fireblaze
Registered: Jul, 2006

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 9:49 AM

"Duplicated code is the bane of software development." - Refactoring: Improving the Design of Existing Code 2006 by Martin Fowler

No duplicated code and always develop with use in mind, (that is that every class should another programmer be able to use) and separate domain-code from your own extentions of a existing framework.

Which is "reuse" in the code below?
1)

new JFrame()

new TransparentJFrame()

My answer: Neither, both are just use.

Reuse? To me its just normal use, if I download the latest JDBC driver from MySQL Im using it not reusing it. Similary if I use code in another jar file on the same project its still use not reuse.

Challange: post a code example with demonstrate "reuse"!

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 10:00 AM

OK, my definition of reuse is:

A) If you did not have to write the code yourself, and it exists without any pre-existing knowledge of your needs (that is, another member of your team did not write it because you asked them to), then you are reusing it.

B) If you write some code that someone else is able to reuse (again, without them specifically asking you to write it), then you have written reusable code.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 10:11 AM

> Perhaps it's a good idea to build a framework or two, but
> to be very conservative about inflicting your first
> attempts on other people.

It really is that "inflicting on other people" that scares the bejeezus out of me. I've taken a small crack at a couple of things that I think can be done better, the big one being a nice small OLAP database engine (Analysis Services has scaling issues and Essbase is anything but small) but it quickly spiraled into something I was trying to avoid. It may be worth another crack as I tossed it aside a couple of years ago and now have some more experience under my belt with OLAP datastores.

Also, I'm curious about the gray area in the matter discussed on this thread. Like the notion of a domain specific framework. Where is the line between that and a DSL? Would Rails be the current poster child for a Domain Specific Framework? I'm sure one or two of the things I've written fall into this nebulous gray area.

I'm not sure I entirely buy the "application with holes" argument, either. I've heard it many times and I've thought about frameworks like this from time to time but overall I think it is more than that. At least a good framework is more than that. The problem I have with it is that, to me, this is too high a level of abstraction to be of any real use. .NET, for example, seems to be a lot more than just an application with holes. What is "the application" in the .NET framework? Is it the runtime interpreter? If that's the application what about all the other stuff around it like security policy? The development environment? Is C# just a good DSL for writing windows applications? I think that's a gross oversimplification. Or maybe I'm just misinterpreting the statement.

Have we gotten off the topic of bad reuse yet? It feels like we have...

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 10:33 AM

Yes, I was actually hoping for war stories rather than opinions.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: When Reuse Goes Bad

Posted: Jul 5, 2006 10:44 AM

Mine is the above, then. I tried building a framework for OLAP datastores and it quickly spiraled out of control. I couldn't even use it easily so I can't imagine what others would have thought of it. It got very big very quickly.

I have much better luck with libraries, API's and DSL's. I've designed a couple of good libraries/API's for our products that can be called from Excel. I'm continually amazed at what people do with these things. They are very small, focused and flexible. They've been used in ways I never would have imagined.

As you postulated, the good designs I've done have been from use happening before reuse. I can't say anything much about the designs of done where the reuse cart went before the horse because I've thrown them out every time. I used to think I was just bad at designing stuff. But over the past couple of years I've seen lots of instances where people design stuff without knowing how it's going to be used for real and once it gets out in the real world there are problems. Maybe I'm still bad at designing stuff, but I've found that I'm certainly not the only one!

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

Previous Topic

Next Topic