Comments on: Monolithic vs. Modular Software Reuse Libraries (Part II)

By: Jim Kring

Jim Kring — Wed, 11 Jun 2008 16:27:40 +0000

Manoj: crelf is right. OOP facilitates reusing code — similar to how VI’s facilitate reusing code. In fact, OOP opens up reusing high-level components, such as user interfaces, coordinators, etc., which is not possible with VI’s alone. Doing configuration management of classes (and instances of classes) is a slightly different and more complex problem, which is typically solved by using a dependency injection framework that can dynamically resolve and bind run-time dependencies together to create systems of objects. This is very interesting stuff and something I’ll probably blog about in the future.

By: crelf

crelf — Wed, 11 Jun 2008 13:28:48 +0000

Manoj C wrote: “Is not OOP designed for code reuse. Why not use LVOOP?”

OOP is a programming pattern that indeed facilitates better reuse in your applications, but it’s not a method of actively managing reuse.

By: crelf

crelf — Wed, 11 Jun 2008 13:27:28 +0000

Jim Kring wrote: “I agree with you about the issues associated with treating individual VIs as atomic components. However, as the cost of revising, distributing, and testing a package goes to zero, I think that the decision factors about how to group VIs into packages are based on VI (inter)dependencies.”

I couldn’t agree more. I don’t expect the cost of all those things to go to zero anytime soon, but the management of interdependancies is absolutely key in managing a medium to large sized reuse library, or any library that has more than just a couple of users.

By: Manoj C

Manoj C — Wed, 11 Jun 2008 11:23:29 +0000

Is not OOP designed for code reuse. Why not use LVOOP?

By: Jim Kring

Jim Kring — Wed, 11 Jun 2008 03:24:15 +0000

crelf,

Thanks for the feedback and for adding your own perspective on some of the article’s points. I agree with you about the issues associated with treating individual VIs as atomic components. However, as the cost of revising, distributing, and testing a package goes to zero, I think that the decision factors about how to group VIs into packages are based on VI (inter)dependencies. But, that’s a topic for another article

PS - I’m excited that you’re psyched. Code reuse is an area of software that I really enjoy. I’ll try to keep the articles and tools coming.

By: crelf

crelf — Wed, 11 Jun 2008 02:34:10 +0000

Another great post Jim (especially the Stone Henge reference

I think you hit the issue on the head with two points in particular:

Users fork the reuse library - not only do they make a copy of the library locally in their project and modify it, that often becomes their own personal reuse library in parallel with the main group monolithic library, and the individual beings to make improvements that aren’t rolled back into the shared library - this is damaging for two reasons: the component isn’t widely distributed so it’s not of benefit for the whole team, and the individual’s version doesn’t have the benefit of other’s experience for improvement.

User stop upgrading to newer versions of the reuse library - like the previous issue, not only does the individual miss out on the love, he/she also checks out of the reuse world and the team can’t benefit from their experience.

That’s why monolithic libraries simply don’t work. Packaging individual as their own components can have exactly the same issues - releasing every little component every time it’s updated can also lead to forking and users ignoring upgrades - that’s why packages of components that share common functionality or apply to a common programming paradigm are the way to go.

Another benefit of grouping common components is to better manage the release process, as well as being able to disseminate ownership of different packages through your team.

As you can tell, reuse is something I’m pretty psyched about

cheers,
crelf