Question on "Generality" strategy in decomposition ?

[Kumar Raja]

Hi All,

While I'm going through the study guide by Mark Cade and Humphrey Sheil, I read the below point on Generality and not sure, why they do not recommend to design a component with future possible reusability in mind. Would not that be a good approach to keep future reusability in mind, when designing or architecting the systems.

Generality
Generality decomposition is determining whether you have a reusable
component that can be used across many systems. Some parts of a system
are only usable within the existing system, whereas other parts can
be used by many systems. Be careful not to make assumptions that a
component may be used by another system in the future and build a
reusable component for a requirement that does not exist yet..

What do they really mean by this ?

Thanks

[Elton Kuzniewski]

My guess, he's trying to warn you about KISS concept... Keep It Simply Stupid.

Why should you concern about a requirement not specified in your exam.
Doing that you're giving unnecessary things to be measured, and so more chance to do a mistake...

[Kumar Raja]

"Why should you concern about a requirement not specified in your exam"

I didn't get this. Is the architectural strategies not a part of the exam. I thought it is, as it is mentioned in the study guide. Please let me know, if I'm deviating from the required topics of the exam.

[Durgesh Vaishnav]

Reusable components are well suited to scientific programs, but business applications are each so unique that it's impossible to capture much meaningful commonality for reuse.

[Murali Ranga]

Does it make sense?

"Be careful not to make assumptions that a
component may be used by another system in the future and build a
reusable component for a requirement that does not exist yet.. "

Initial version of Ejb technology was with only remote interfaces,
The applications were using remote interfaces considering future assumption that Components can be reused across the network/ other Java virtual machines. Which is performance overhead


Now Ejb come with Local and remote interfaces.Same way the spring Pojs and can be available as remotely by changing the some configuration.

No need to add extra burden on the Component considering the assumptions or future requirements.Components must be flexible and extensible.


It may not work all the time. Based on the requirements you need to take correct decision what is the right implementation for the component to make reusable

[Kumar Raja]

Durgesh Vaishnav wrote:Reusable components are well suited to scientific programs, but business applications are each so unique that it's impossible to capture much meaningful commonality for reuse.

I may not agree with you. Reusability is a feature/concept that could be applied to any domain or area. What are your reasons or examples that would justify that business applications would not have reusable components. Ofcourse, business rules may vary, but that would not completely rule out reusability in business applications. Also, what specifically you mean by business applications.

[Paul Balm]

Yes, of course. Business applications also have reusable components: Think of all the libraries that they use, and this includes the J2EE platform with EJBs.

The way I have read that statement from Cade and Sheil is that you should not solve problems that you're not asked to solve. That's all there is to it. Don't assume that they might want to reuse components that are implemented for your application, when there is no hint in the assignment that they might.