The Simons     Component Library

Introduction   Class Hierarchy   Class Listing   Index of Classes   Index of Methods   Header Files  

Design Rationale

The Simons Component Library was developed as a personal project to explore the power and simplicity of object-oriented design. The original motivation was to provide a small object-oriented kernel for C++ that was as powerful as the Java kernel, but possibly even easier to use. It became a quest for minimalist design, while not wanting to compromise on functionality. The kinds of issue prompting the project included the following:

• Usability : C++ is a fine programming language, but has grown increasingly complicated for new programmers to learn and use well. The templatizing of the standard C++ library has introduced more complexity than the average programmer can handle. Even simple programs generate incomprehensibly-nested compiler messages. Programming idioms are more difficult, for example, simple operations on collections require generic functions acting on three or four (unchecked) iterators. Why not iterate over all collections using a bounds-checked index?
• Compatibility : The design of the C++ standard library has steered the language away from object-oriented programming, in the direction of static generic functional programming. While there is nothing wrong with functional programming, the object-oriented notion of component compatibility and substitution has been lost. For example, the standard C++ collections are separately implemented and common abstractions, such as the notion of a sequence, are merely "conceptual". Collections should break down into sequences, unordered and sorted collections - so why isn't a String a first-class Sequence in languages like Java and C++?
• Substitutability : Supporting the development and exchange of substitutable components requires an agreed design style. For this, uniform reference semantics for objects is the only sensible solution, rather than C++'s usual mix of safe value-based objects and the limited use of dangerous dynamically allocated pointers, where reference semantics is intended. This requires automatic memory management for safety. Likewise, interfaces should be developed with generality and substitution in mind. This points to the more widespread use of virtual methods in C++, supporting dynamic object substitution.
• Persistence : Facilities for input and output are notoriously poor in most languages. Issues of formatting and streaming are unhelpfully mixed in C++. However, at least C++ has symmetric reading and writing, which Java does not. Why not integrate input and output with object serialization? Why not treat formatting along with standard data format translations, such as XML, CSV and HTML, rather than treat these as separate issues? And is it possible to provide a simple file locking protocol that is actually portable?
• Robustness : The standard C++ library does little to encourage self-checking for failure (the streams optionally throw exceptions rather than setting flags). Routines that can fail should be checked for failure and faults should be reported at the point of failure. Why not have a simple hierarchy of exceptions, integrated with the error-reporting mechanism, that can be intercepted and handled selectively by the program?

This documentation was created by Dr Anthony J H Simons, Department of Computer Science, University of Sheffield, Regent Court, 211 Portobello Street, Sheffield S1 4DP, United Kingdom.

Generated on Wed Jan 06 10:18:45 2006 for The Simons Component Library by 1.3