Friday, June 21, 2002 08:13 AM
"Pattern" usually refers to some things (collaboration abstractions etc. see design patterns FAQ's/books/sites, and UML reference guide, for good discussions) that you can detect/use in different places, on different levels, throughout your code. UML models a "design pattern" using a "collaboration", with "slots" indicating roles, that can be played, in different instantiations, by different actual classes, objects, components, systems/subsystems etc.
"Framework" usually refers to some supplied code/components to help you build your application, by taking care of some ugly/plumbing/architecture details for you, letting you concentrate on your specific application/business domain. Write your event handler and stick it in the framework, and let the framework take care of everything else, making sure your event handler gets called at the right times. (e.g. if the framework provides/implements/facilitates an "event-driven" model or pattern)
A framework can be (ought to be?) designed using a certain design pattern or family of patterns, so if you do things the way the framework facilitates, and take advantage of it, you will be using that pattern. You could be only using part of the framework, and not using it in its "intended" fashion, and thereby be missing the "pattern", say if you build an application out of humongous JSP's composed entirely of convoluted scriptlets that do everything including low-level database stuff etc..
"Architecture", you can find definitions in lots of books & Web sites, kind of refers hopefully to a vantage point outside of any specific sub-system or model layer/view, where someone can give guidance and shape and direction to the "whole thing" overall, and to how the different subsystems and models ought to interact and relate to each other.
The architecture of a system may be designed to utilize certain frameworks, and expressed in terms of certain patterns.
A good architect, in a good/complete architecture, would address the issues and trade-offs entailed in choosing to use specific frameworks and patterns (and even the programming languages and libraries to be used), and would also consider the lifecycle implications, of how well the frameworks etc. are currently supported and are likely to be supported in the future. They should provide the foundation to help decision-makers consider alternatives even in the future, like if some tool/framework/library/language/processor etc. becomes obsolete, how the system could be adapted and revised to use something else instead, etc.
(great stuff on this kind of duty of the architect, e.g. in Hofmeister & Nord & Soni's Software Architecture book)
So I would "nest" the concepts that way -- architecture makes use of frameworks and patterns, frameworks can/ought to facilitate certain patterns, and then patterns help to design the actual implementation code in specific situations/areas/subsystems/scenarios/packages etc.
A programming language is a kind of general framework, considering the functionality (and patterns) it provides explicitly, or makes easy vs. hard to implement, the libraries that come with it or can be easily obtained, etc.
How's that? do I get full credit on the exam?