On 9/21/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > I would like to hear what a component is. Definitions can differ. JSF > hides the strict definition of component quite well, here is one, done > indirectly (JSF 1.1 spec, chapter 1.2.2): > > === cut here === > Component writers are responsible for creating libraries of reusable > user interface objects. Such components support the following > functionality: > * Convert the internal representation of the component's properties > and attributes into the appropriate markup language for pages being > rendered (encoding). > * Convert the properties of an incoming request—parameters, headers, > and cookies—into the corresponding properties and attributes of the > component (decoding) > * Utilize request-time events to initiate visual changes in one or > more components, followed by redisplay of the current page. > * Support validation checks on the syntax and semantics of the > representation of this component on an incoming request, as well as > conversion into the internal form that is appropriate for this > component. > * Saving and restoring component state across requests > === cut here ===
This definition, of course, is specific to *JavaServer Faces* based *user interface* components. Generalizing your question a bit is more interesting as the inevitable tensions between advocates of "component oriented development" and "object oriented development" surface. In the comments below, I'll quote a couple of references that might be the beginnings of research for your own investigations of the subject -- but this list should by *no* means be assumed to be an exhaustive analysis of the available information. Here, as everywhere else, Google is your friend :-). (1) http://research.microsoft.com/~cszypers/events/WCOP2005/ This document was the description of a "tenth" annual Workshop on Component-Oriented Programming, and has a definition that I quite like: A component is a unit of composition with contractually specified interfaces and explicit context dependencies only. Components can be deployed independently and are subject to composition by third parties. Compared to general OOP principles, then, one can distinguish COP by a more narrow focus on one particular style for creating complex behavior out of simple objects ... composition, versus subclassing or "black box" delegation. It is not surprising that a large number of developers in the world who can grasp this concept more quickly than they can general OOP principles -- less to understand, and therefore easier. In addition, there is more emphasis on composition being performed by *third parties* rather than the developer who is creating the object hierarchy in the first place. Thus, you'll tend to see more uses of concrete implementation classes, rather than behavior-defining interfaces, in programs that work with components. (2) http://www.hitachi.com/rev/1998/revdec98/r6_105.pdf When describing the development process around component-oriented development, this paper describes it as follows: The component-oriented development method is a system development method to support the interchange of design information among end-users, systems analysts, and systems engineers. In this method, we adopt a concept of compoennts that encapsulate independent business functions in addition to a concept of classes that show each process and data. Here we see the same sort of emphasis on component-based design being done my multiple independent parties. In addition, we start to see a notion that components are often more coarse grained (and/or "self contained") than a pure object oriented model that accomplishes the same goals. In JSF terms, this is why a UIComponent is responsible for both *input* and *output* related functions (although it can, and normally does, delegate these responsibilities to a Renderer, that is invisible to the application developer who is creating an application using these components). (3) http://web-services.gov/Component%20Oriented%20Development.pdf This presentation focuses on the Microsoft component oriented architecture (and its evolution), but the key points apply to pretty much anything one could call COP. A key takeaway, again, is the focus on *generic* coarse grained designs, which are both more understandable to app developers and easier to maintain, plus an emphasis on programming by composition rather than by inheritance. Note that this doesn't mean throwing out *all* aspects of OOP -- it's perfectly reasonable to use standard OOP techniques in the *implementation* of components. The visible difference is at the edges, the parts of the API that an application developer has to interact with. (4) http://java.sus-con.com/read/48536.htm?CFID=112960&CFTOKEN=65734272-136F-8559-5083C0CD494489F8 An interesting analysis of creating component-oriented web interfaces, including some discussion of places where tag-only solutions tend to fail. A key quote: Tag libraries work really well in many cases, but become less usable in more complicated cases, particularly when JSPs need to implement the non-trivial presentation logic often required by compartments. That's why publications promoting tag libraries never go beyond the simplest examples. Sun's implementation of Pet Store illustrates this point perfectly. Pet Store serves as a blueprint for building applications using J2EE technologies like JSTL tags, but the most complex table is limited to static columns and doesn't have any presentation logic. Can I build a tag library that acts more like a "component" than like a "tag that renders HTML"? Sure ... tags like Struts Layout have the sorts of functionality one might expect from something called a "user interface component". But can I compose Struts Layout with a bunch of other "components", or use my own "components" inside the columns? Hmm ... not so easy. (5) http://portal.acm.org/citation.cfm?id=131005 Again, we see the most common theme that distinguishes COP from pure OOP: Object-oriented programming techniques promote a new approach to software engineering. By revising "frameworks" of plug-compatible software compoennts, reliable, open applications can largely be constructed, rather than programmed. (---------------------------) There is *lots* more information available to the casual web searcher ... but the key factors that distinguish a component oriented approach should be pretty clear. Note that this is not a binary world (you do *either* COP or OOP), nor is one or the other the perfect answer for every problem. But my experience recently has been that it is much easier to teach someone the basics of "program by assembling components" versus "program by creating object hierarchies" ... and the difference is dramatic enough that the potential target market for a component oriented technology (simply measured in the number of users who can grok how to use it well) is substantially larger than the number of people who will understand a technology that is built around elegant employment of object oriented design. Does that mean COP is "better" than OOP? Don't be ridiculous ... the question is totally meaningless unless you say better *for what*. Craig
