Component Design Patterns Introduction

[ComponentDesignPatterns | ComponentDesignPatternsContext]

This currently serves as the workshop table where we can slice and dice patterns, propose ProtoPatterns, comment on the flow and relationship between them, etc.

---

At the top level, one must make some very high level decisions when embarking on a project involving ComponentBasedDevelopment.

• DistributionOfComponents
• LayeredFrameworks
• TransparentDistribution
• ProcessBoundary
• GoingThroughCustoms

Once you've determined what components are required and what communication mechanisms they will use, you must either acquire or build them. These patterns help you whether you buy or build.

• CautiousBuyOverBuild
• SoftwareProcessThatFits?
• CookbookApproach

Another issue that has to be addressed is the size or scale of the components that have to be built. Especially when distribution is thrown into the mix, this becomes an interesting problem. It is addressed in the following pattern:

• FacadesAsDistributedComponents

Once you've acquired existing components and determined which new components you need to build, coupling and cohesion become important issues. For example, sometimes you need to decouple yourself from an component or framework to mitigate risk. These patterns focus on independence and dicsovery.

ContextIndependence

• AbstractInteractions
• ContainerIndependence
• ThirdPartyBinding
• InterfaceDiscovery

These are more at the design level and are starting to take form as interrelated MiniPatternLanguage? s that will cover collaboration, communication, and coordination amongst components.

CommandPatterns

• InterruptibleCommand
• AcidCommand
• ConcurrentCommands

ConnectionPatterns

• ConnectionSingleton
• ConnectionFlyweight
• ConnectionObserver?
• ThirdPartyBinding

Okay, so we know that components tend to execute different types of commands. Sometimes they use connections; other times, not. Patterns exist in both areas. Obviously there's more to it than that. Sometimes this data is sliced and diced; other times, not. Here are some patterns that focus on data coming in, going out, coming in and going out, coming in and going out while being played with, etc.

DataPatterns

• ContainerManagedPersistence
• ComponentManagedPersistence

Other miscellaneous junk ProtoPatterns that currently have no home:

• SplitDesignTimeAndRunTime
• SortingAndFiltering?
• SpreadTheNews?
• HugeDataMode?
• ChooseYourContracts?

Here are some patterns that were discovered during the course of the ComponentDesignPatterns (CDP) project, but rejected. Not because it wasn't a pattern or was deficient in any way, but because it turned out that CDP patterns might use them or be related to them, but it does not sit solidly within the context of CDP and in fact may transcend it.

• ProtocolTunneling

Here are some patterns that have been identified as being related to the patterns being written up in CDP. They may have been published already, might just be written on a WikiWikiWeb page, or exist somewhere else. Regardless, we don't have the author's permission to include them in CDP but are interested in their relationship to it.

• HalfObjectPlusProtocol