Chapter 6. More goodies coming with OOSTD
What is more
As already stated in the introduction, OOSTD is an architecture consisting of many design patterns, helping designers and developers to create solidly architected products. The previous chapters described in more detail some of the key components, but there is still a lot more waiting to be revealed. Unfortunately, there is no room and time to describe all of it in more detail.
This chapter provides the least possible, it shows the class diagram of some of the missing OOSTD components and it provides the minimal information about them. Fortunately, this work is not the end of evolution of OOSTD. The author plans on maintaining this document up to date, as new ideas come along. See to references for on-line version of this document.
What is more:
Multiton
Repository, RemoteRepository
ComponentInitializer
objects: Component, Association, Block, Ref, NamedRef, RemoteComponentRef
utils: Debug, Logger
interfaces: Identifiable, Initializable, Enumerable, Contextualizable, Context, Visible, Startable, Suspendable, Finalizable, Printable
CacheMgr, Cachetable, Cache
Daemon, Timer, ThreadMgr
What is still coming:
UserSvc, AccessSvc, SessionCX, Producer, TemplateMgr
Multiton
Multiton is the opposite of singleton. It is a class of objects where all instances of the class are accessible trough class operation "getInstance(id)". Each instance is denoted by its name (id).
This design pattern is mainly used for "manager" kind of components. "Manager"s are objects providing services to other objects. There is often need to use more then one instance of certain managers and all of the instances must be easily accessible to other components. An example of manager is "URIMgr" which maintains URI references map. Each instance of "URIMgr" is dedicated for distinct application domain.
Figure 6.1: Class Diagram: Multiton design pattern
Repository
Repository holds set of components. There is always a need to access certain generically useful components, such as instances of "DataClass", etc. Repository is just the right place to put the components into. The Repository is usually initialized at application startup and then various objects are obtaining references to the components held by the Repository. Since the Repository is a multiton instance, there is number of Repository instances, each for distinct application domain.
There is also a notion of a RemoteRepository. A Repository can have so called "default repository" which is being looked up in case that a component was not found in the main repository. It the default repository is an instance of RemoteRepository, then a component can be shared across computers, seamlessly to the developer.
Figure 6.2: Class Diagram: Repository
ComponentInitializer
ComponentInitializer encapsulates the code responsible for creation and initialization of objects which live through the entire life of the application. All these objects are stored in Repository, where they can be later retrieved from.
One future improvement of ComponentInitializer is usage of a scripting language describing what objects should be instantiated and how should they be initialized. The candidate for such a language is BML, see [27].
The rest
Unfortunately, there is no room and time to go in more detail with the rest of the components. Hopefully, all of them succeeded in the main idea of OOSTD which is: intuitive design. If one have a look at name of a component and its operations, it should be straightforward, what is the usage of the component. See the on-line version of this document for future informations.
Figure 6.3: Class Diagram: edu.oostd.object package
Figure 6.4: Class Diagram: edu.oostd.util package