Hi Joel

>Cohesion: What are the responsibilities of the component you are creating? Is one of those responsibilities providing the DWORD function to other parts of the system?

The component does not have that resposibility. IMO only the dword component should have that responsibility. If I add that as a method of even an application object, I force a requirement that this application object be included even for the simplest system.

>
>Coupling: As others have stated, the issue is tight coupling vs. loose coupling. IMO, having lots of objects with messages flying around is a good thing (albeit confusing a times). It shows you have created nice, cohesive, reusable units and you are making use of them. Reusability is the goal, isn't it? Now, if your DWORD function worked with only a single class, it would be tightly coupled to that class and wouldn't be very reusable. Sometimes this is a requirement, but should generally be avoided.

I agree. I doubt it's ever a requirement from the business, but it may be necessary based on the implementation of a system. It is no more confusing than having methods/functions embedded in arbitrary class/procedure libraries. Remembering where they are may be fine when you're familiar with your framework, but it hurts when others try to use your framework. Having modules that have clear names and clear meaning makes it easier to build complex systems. These modules become more stable and can be reused in other parts of a system or even in other systems.

Design pattern based classes can be reused in every application. They don't need changes. As more complex components are assembled with those classes, those complex components may change, but not as often if they are designed properly.

>
>In your example, I would probably leave DWORD as a separate function, or maybe put it in a class with other Win32 stuff.
>

Again if I put it in such a class or even a procedure library, that class/procedure becomes very "heavy".