• Advertisement
Sign in to follow this  

Object Library Design Pattern

This topic is 892 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


Libary Design Pattern
A novel aproach to encapsulate factory and object management

Charles Alan Martin - Software Programmer / President of Scrut Hut

Libraries are well known, but we usually think of static or dynamic linked libraries. This is a pattern and not related those stated and addresses certain design issues while encapsulating the abstract factory pattern, singleton, live and dead lists ( with garbage collection ), object retrieval and versioning.

When a library opens there are no books. A customer makes a request for a book ( object ). If one is not found in the live list then a request is passed to the library which orders the book ( allocates the object and passes back a pointer ). Alternately if a book is found on the library shelf ( in a dead list ) then it is then placed on the live list and a pointer is passed back. When a customer ( the object that made the original request equates the smart pointer to null ( and any other shared references ) then the reference count drops to zero and the object is placed on the dead list after releasing the object ( but does not de-allocate the object ). When the library closes it can determine what books are not returned by traversing the live lists and can act accordingly, which for example might be to gracefully release the object and place the object on the dead list. The garbage collector ( a surrogate object ) is then responsible for handling the de-allocation of objects which by sending a request to the original factory that created the object to de-allocate the object.

Pattern Name
Object Library Pattern

One needs a uniform way to retrieve objects; having objects with many different types makes live and dead lists sharing a parent interface less efficient. The system should have a simple way of handling the allocation and de-allocation of objects. The ability to extend the system at run-time makes matters more complicated. An organized design that decouples interdependencies between systems is vital.

Patterns Used
Object Pool ( Pooling Pattern )
Abstract Factory ( Design Patterns p. 99 )
Factory Method ( Design Patterns p. 121 )
Singleton ( Design Patterns p. 144 )
Iterator ( Design Patterns p. 289 )

First a interface for factories is designed. A singleton factory subclass is implemented as well as a simple factory for unique instances to be returned per request; These factories are subclasses and concrete implementations of the parent factory interface. The live and dead lists are encapsulated by a container per class using object pools. Then encapsulate any identification information with the live and dead lists plus the factory related to the class. A list of these containers are members of the library. Using an iterator one can traverse the list when requests come in; trees can be used to optimize the search time of these classes. The library in this way is not static, yet is built at run-time. The library can then be used for a modular design having multiple modules containing a single library each. One can organize the application into modules of libraries, meaning all object management is internal to the library, or is handled in conjunction by a smart pointer. When a request for the library to release the garbage is received then the reasonability to collapse the dead list is delegated to a surrogate object, the garbage collector. The garbage collector can act as a reaper object; traversing the live list at any time to guarantee all objects are live, and any objects with a reference count equal to zero then would be released and placed on the dead list. The garbage collector also collapses the live list when the library object is released, and then continues on with garbage collection.

When one only requires identification of an object and needs no credentials then one can access any object in the system leaving the objects vulnerable. There is a space to time trade off with live and lists per type; we can approach this with a tree for optimizations. Requesting objects is generally optimized especially with a larger number of objects with different types is held by the library.

Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John; "Design Patterns: Elements of Reusable Object-Oriented Software"
Kircher, Michael; Prashant Jain; "Pooling Pattern"?


Share this post

Link to post
Share on other sites

I have several of these in my code; I just called them "Retrievers" for lack of a better name.

Some of my retrievers depend on other retrievers - for example, my AnimationRetriever internally uses the TextureRetriever.


Why is this pattern dependent on singleton? None of my retrievers are singletons. Nothing about them inherently forces there to be only one of them.

Instead of linked lists and iteration, I internally just use a hash map (C++'s std::unordered_map).


Mandating that the Retriever can't actually deallocate any objects until exit isn't a good requirement: Your memory usage will grow and grow and grow until you run out.

I suppose you could just have a maxed size for your dead list, and deallocate the oldest dead when a new dead is released.


In my game project, when players exits one area, releasing (but not deallocating) all the textures, the new area then retrieves the textures it needs, often "reviving" the released-but-not-freed resources. Then, once the new area is loaded, I call retriever->FreeAllUnused(), and all the old area's textures that aren't being re-used by the new area are now deallocated.


I don't have a dead list either. I just keep resources with 0 reference count around until the next call to FreeAllUnused().

Share this post

Link to post
Share on other sites

A singleton factory subclass



Apart from singletons, it seems you are simply reinventing object pools. How would you concretely combine object pools and factories (or other object creation patterns)? What kind of factories do you have in mind? Is there a meaningful and useful way to consolidate "libraries" for different types instead of writing a template that works with a single type?

Share this post

Link to post
Share on other sites

It violates Wikipedia's guidelines of notability.


Wikipedia is not "everything in the universe". It's a curated selection of notable things in the universe.




The barometer of notability is whether people independent of the topic itself (or of its manufacturer, creator, author, inventor, or vendor) have actually considered the topic notable enough that they have written and published non-trivial works of their own that focus upon it—without incentive, promotion, or other influence by people connected to the topic matter. - Wikipedia: Notability in relation to self-promotion and publicity


And even when other people talk about it, it's not always sufficiently notable. For example, just because almost every indie videogame released gets a few reviews, that doesn't mean every indie game in existence should have a Wikipedia page (that'd be better suited to a website dedicated to archiving and listing every game in existence).

Share this post

Link to post
Share on other sites

Hodgman, out of curiousity, why would you consider it wrong to put your own stuff at wikipedia? Is it unethical?

It's against their rules. In addition to the above rule on notoriety, theres also a "no original research" rule. New research has to filter throughout the community amd have others write about it and derive new works from it, before it's possible to create a Wikipedia page for it (which at that point, would have a sufficient numbet of citations available).

Anything that has a single citation, by the original author only, with no other viewpoints, will certainly get flagged for deletion (as had already occurred to the OP by the time I googled for it!)

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement