This pattern language describes a set of related techniques to provide a mechanistic translation from an object-oriented design to an implementation in a procedural language using an "object-based" programming style. The master copy of the pattern language (version 0.2) is hosted in http://www.geocities.com/SiliconValley/Foothills/5962/index.htm. The copy here is evolving towards the next release. Please note: My employer MAS Technology Ltd. retains the copyright to this pattern language. (At least those patterns I wrote) -- StephenCheng ---- '''Introduction''' Modularity, maintainability, and reusability have long been a promise of the object-oriented technology. However a procedural language, such as C or Assembler, is still often the platform for existing and new projects. This situation is especially prevalent in the embedded software community, as speed constraints, size constraints, and cultural resistance often make it impractical and impossible to deploy a full-fledge object-oriented programming language such as C++, Java, or Eiffel. Analysis and design in the object-oriented paradigm would still be beneficial. A design generated using the object-oriented design methodologies is generally more modular, extensible and reusable than an equivalent design generated using structured design methodologies. The challenge becomes how to translate an object-oriented design into an implementation in a procedural language. Although procedural languages do not naturally support object-oriented constructs, most object-oriented designs can be implemented in these languages efficiently and effectively in an object-based programming style while retaining most benefits associated with the object-oriented technology. The set of patterns described in this document provide a catalogue of techniques to implement an object-oriented design in an object-based programming style, with special emphasis on embedded systems. This pattern language will continue to grow and evolve as we gain expertise. ---- '''The following patterns are now written (or partly written):''' ''InstanceData'' -- a foundation pattern These patterns describe techniques to realize the InstanceData patterm * FamilyFusion * FamilySplit * ClassInheritance ''(name change??)'' see ClassInheritanceDiscussion ''PolymorphicFunction'' -- a foundation pattern These patterns describe techniques to realize the PolymorphicFunction patterm * FunctionPointer * PolymorphicFunctionWithEmbeddedBehaviour ''Other patterns'' -- various auxiliary patterns to tie the thing together * OperationVapourware * ClassDescriptor * ClassTag Other topics in the pattern language * WhyObjectBasedProgramming * OverviewOfTheObpPatternLanguage ----- '''The following areas are scheduled for addition:''' ObjectInstantiation Object Termination Buffer Management Implementation Of Singleton Implementation Of Associations ObjectMerging MacroAbuse pattern - to make it easier to deal with function pointers, suggested by (JimCoplien) ---- To keep the discussion separate from the patterns themselves, I think we should have a page associated with each pattern for the discussion itself. E.g. The pattern description would be on InstanceData , but the discussion could be on InstanceDataDiscussion -- (KeithDerrick) ---- There may be some particpants in WikiWikiWeb that may be old enough to remember the days when C++ was 'evolving' from C and there used to be tools by the name of CFront produced by a number of companies, AT&T being one of them. CFront used to 'translate' C++ code into C code which was then compiled by an existing C compiler for you chose target hardware/system. From my point of view, I am following the ObjectBasedProgramming approach in an effort to revisit how the CFront tools work and how they implemented OO behaviour while using C. For embedded systems there is good support for ANSI C, from IAR, Green Hills, Cygnus and Hitech, but very few of them support any kind of OOPL on small 8bit controllers. The support for OOPL's seems to start with 32bit machines! If a definitive resource, book, URL or whatever exists that explains how CFront worked, please let us know. -- ScottWalsh ---- ''Scott, I disagree. CFront provides completely '''generalized''' mechanisms to support OO concepts like inheritance, polymorphism and abstraction. That's exactly what we don't want - generalized mechansims are typically slow and clunky - and that's not what most embedded software development can accept and afford. By going to object-based programming style, the implementer can choose between alternative techniques to implement these same concepts, in a way to match the problem domain. See WhyObjectBasedProgramming for more. -- StephenCheng'' Ahhh, this may well be a part of the thoughts that you have had which all of those reading WikiWikiWeb are missing. If the mechanisms used by CFront have been found to be not suitable, for ROM/RAM/speed reasons, you have taken the next step that was not apparent to us and made trade offs to suit those requirements better. If this is the case, can we make our starting point for our patterns to be from '''This is How CFront Works''', then work through why they may be non-ideal for an embedded system. Finally we will reach a pattern that allows us to modify our implementation strategy to best suit our embedded systems! -- ScottWalsh ---- Does anyone know how CFront dealt with exceptions? (CFront aside though, any ideas on how to code this in ANSI C?) --some guy Exception has its place in business programming, but it is voted as a best-to-avoid feature when applying C++ to embedded software development. -- StephenCheng ---- This is interesting stuff, don't get me wrong. But I'm wondering whether the pattern approach is best. First of all, does it meet the "three-uses" criterion? Second, I wonder whether a straightforward writeup of the implementation might not communicate better. Third, it'd be nice if it were easy to separate from other wiki topics somehow ... I regret having no useful suggestion for this.--RonJeffries Ron, I had the same feelings at first. In fact that's how an earlier draft started as. However from experience it is found that often there are two or more techniques solving the same general problem (for example, see FamilyFusion, FamilySplit and ClassInheritance). A straight write-up is not as effective as a pattern language in conveying the trade-offs and contexts. -- StephenCheng In terms of the ''Rule of Three'' criterion, it's pretty close. StephenCheng has come up with the proto patterns. ScottWalsh and I have independently developed most of them for our current project. I have used similar approaches in previous products for other clients. There is also a book ''Reusable Software Components'' which deals explicitly with doing OO in C for embedded systems. -- KeithDerrick