Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  basic question on libraries  (Read 3628 times)
0 Members and 1 Guest are viewing this topic.
Offline Kommi

Junior Devvie

All opinions will be lined up and shot!

« Posted 2005-11-22 17:01:48 »

Can some one give me a 1000 foot definition of how you write code as libraries so as to make it modulized and reusable? Any high level examples are welcome.

Offline Jeff

JGO Coder

Got any cats?

« Reply #1 - Posted 2005-11-22 22:35:53 »

Its called a "data structure" Smiley  Understadn that and the rest is just details and learned esthetics and technique.

A Data structure is the encapsulation of a set of data, organized in some way, and the routines to access and modify that data.

Structured programmign 101.  Object oriented code doesnt chnage that, it just gvies you more refined ways of managing data structures.

In general, I'd recommend you read Josh Bloch's book "Effective Java" as it will give youa lot of guidance on how to do this well in Java.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!
Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Reply #2 - Posted 2005-11-23 01:02:15 »

Wow, what a great question!

Library programming is imho is more about defining the contract between user and and library than anything else. Be sure of what you're trying to provide/manage and be clear in your documentation.


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder

Exp: 12 years

Where's the Kaboom?

« Reply #3 - Posted 2005-11-23 04:22:46 »

Yep.  I've designed several APIs in the past and it is all about a clean definition of the interfaces involved.  Hiding implementation details where ever possible, but being sure to make them explicite when they really matter.  Always imagine at least two completely different ways the library could be used (i.e. put yourself in the shoes of two potential users, each with different goals) and use that as a basis for making the interface reasonably generic in the context of the library.

Offline cylab

JGO Kernel

Medals: 173

« Reply #4 - Posted 2005-11-23 08:43:47 »

If you want to make an expandable library you might condsider splitting up your library in three parts:

- Implementatation

The API (Application Prorgamming Interface) consists of the interfaces and basic data type classes you would like to provide. To create real instances of the implementing classes you should consider using the abstract factory pattern (meaning creating the instances by a "factory"-class with some createXXX()-Method instead of directly calling constructors).

The SPI (Service Provider Interface) contains all the neccesary bits for implementing modules in your library. It mainly consists of abstract base classes that implement one or more interfaces from the API and a set of helper utilities.

The Implementation is what it's named: the concrete (standard)-implementation of your API ;-)

An API of such a design would look like:
    // The Interface defined in your API
    public interface Foo
        public void methodA();
        public void methodB();
        // Added after Implementation of ConcreteFoo
        public void methodC();

    // The base class defined in your SPI
    public abstract class AbstractFoo implements Foo
        public abstract void methodA();
        public abstract void methodB();
        // Provide some default implementation to prevent a Rewrite of existing modules after methodC() was added
        public void methodC(){ /*some default behaviour*/ }
        protected Object getNonAPIDetail() { /*some functionality not intended for the API User*/ }

    // The concrete implementation
    public class ConctreteFoo extends AbstractFoo
        public void methodA(){/* do something useful */};
        public void methodB()
            // utilize the extra functionality provided by the SPI
            Object bar= getNonAPIDetail();
            /* do something useful with bar*/

        // this method was part of the SPI, but was removed later...
        public String getIdentity()
             return "Foo";

    // The Factory Singleton in your API
    public class Factory
        // The static instance for sharing
        private static Factory instance=null;

        // A protected constructor forbids direct instanciation by the API user
        protected Factory(){}

        public Factory getInstance()
                instance= new Factory();
            return instance;
        // The factory method to create a Foo based on system property configuration
        public Foo createFoo()
                Class myFoo= Class.forName(System.getProperty("your.api.package.Foo"));
                return (Foo) myFoo.newInstance();
            catch (Exception e)
                System.err.println("Could not instantiate Foo implementation: " + e.getMessage());
            return null;

    // To create an instance of your Foo class
    Foo aNewFoo= Factory.getInstance().createFoo();

As you can see, the separation of API and SPI enables the library author to add more interface methods over time without breaking the module developer contract, since they only depend on the AbstractFoo base class. A similar effect can be seen for the "getIdentity()"-method in ConcreteFoo, which was an abstract method of the SPI but was removed from the base class at some version to be replaced by another identification mechanism, that does not depend on this info from the concrete implementation anymore. Both modifications did not break the contract between the user and the library nor between the module vendor and the library, so long term binary compatibility can be archived.

Since the API-user should not need to know anything about the concrete implementation, the Factory just deliveres an instance of the API Interface. Which class is instanciated can be configured using a system property, so you can replace the API-Implementation by specifying a different concrete class in the property without touching the users code. Normally you would use a configuration file or something instead of a system property, but this is just an example Wink

Also keep in mind, that using a factory for every single type in your library is probably not the right way. There can be a lot of simple classes in your API, that don't need the abstraction and exchangability feature, as well. However, the factory pattern as described above is best suited for component/module instanciation.

Mathias - I Know What [you] Did Last Summer!
Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Reply #5 - Posted 2005-11-23 14:02:11 »

SPI strikes me as its approaching golden hammer status. Its useful in some cases where you want that level of flexibility, in most library cases its just massive overkill.


Offline cylab

JGO Kernel

Medals: 173

« Reply #6 - Posted 2005-11-23 14:05:44 »

You don't have to provide a SPI layer for everything, but having it for a limited set of module-/component-interfaces is a Good Thing (TM). For example it might be a good idea to use an SPI layer for something like a plugable scenegraph renderer, but it makes little sense to use one for new geometry-types to be added to a scenegraph, for which simply implementing a generic Geometry interface is sufficient (and probably much better).

Mathias - I Know What [you] Did Last Summer!
Offline Niwak
« Reply #7 - Posted 2005-11-23 15:47:28 »

From my point of view, SPI are usually a design error ; they promote implementation inheritance as a good design practice which, I think, is completely wrong.

The more simple design pattern with interface on one side and implementation on the other seems the good way to go for me.

Your client should never be in a situation were it has to read your implementation to use it. SPI will create such a situation.

For the API I design, I tend to try to apply this design rules ;
     . keep it simple and readable
     . keep classes and interfaces "short" (i.e. avoid interfaces with 30 methods, classes with hundreds of lines of code,...)
     . build a readable package architecture (avoid packages wih too many elements, avoid mixing definition package with interfaces and implementation packages with classes)
     . prohibit package cycles
     . restrict class cycles to the minimum
     . keep it flat (i.e. limit the number of levels of inheritance)
     . discourage implementation inheritance (in fact, implementation inheritance is only allowed for ultra-stable classes fo which I am completely sure that the contract willnot evolve, and even in this situation, it is only allowed in the internals of the library)
     . prefer composition to inheritance

One thing I would love to have in Java is "design by contract" (search for Bertrand Meyer book on the subject) wich gives a very good and safe way to design your library but it's still missing.


Edit :
the example of the pluggable scenegraph renderer is clearly a situation where I would not (and I do not in my 3d engine) use a SPI. If you want your scenegraph renderer to be pluggable, I think you should clearly define the contract of your extension point in extension point interfaces and provide an extension registering mechanism.

example :


public abstract class PluggableRenderer {

    protected void visitNode(INode node);



Result : everything is mixed, the resulting design willnot be reusable, your plugin won't be reusable for another renderer.

Composition with interfaces :

public interface INodeVisitor {

    public void visitNode(INode node);


public class PluggableRenderer {

    public PluggableRenderer(INodeVisitor visitor) {


Result : the design is readable, your plugin is reusable.

Note : I know this example is very simple but you can go further this way. For example, my renderer use plugins for visiting nodes based on their node Id. The overhead for this is near zero since the design use a simple array access to get the plugin for the appropriate node.
This lets my plugin be shared between the different scenegraph visitors.
Offline swpalmer

JGO Coder

Exp: 12 years

Where's the Kaboom?

« Reply #8 - Posted 2005-11-23 16:34:28 »

Your client should never be in a situation were it has to read your implementation to use it. SPI will create such a situation.

I don't see the connection.  Care to elaborate?

Offline Jeff

JGO Coder

Got any cats?

« Reply #9 - Posted 2005-11-24 00:06:21 »

Good library design is as  much an esthetic as anythign esle, and exaclty what consittutes "good" chnages depending on your audiance.

Game develoeprs want lean, mean and efficient.  If you cna make my job easier great but NEVER totally take away control from me or force me to use up CPU cycles where I don't want to.

Eneterprise develoerps want it as automated, idiot proof, and simple to use as possible and don't care much about control and only limitedly about performance, really.

A good general rule of thumb for any tool is this:
"Doing the simpelst 80% of the use-cases should be easy.  Doing the last, hard 20% shouldn't be any harder then doing it without your tool and ideally shoudl be easier."

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline darkprophet

Senior Devvie

Go Go Gadget Arms

« Reply #10 - Posted 2005-11-24 01:02:51 »

Treat your users as if they were 5 year olds?  Roll Eyes

Always worked for me...

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline cylab

JGO Kernel

Medals: 173

« Reply #11 - Posted 2005-11-24 09:02:32 »

+1 Jeff
+1 darkprophet

I have rarely seen a pair of comments, that expressed more, which kind of fight is going on in my head  Grin

Mathias - I Know What [you] Did Last Summer!
Pages: [1]
  ignore  |  Print  

Ecumene (110 views)
2017-09-30 02:57:34

theagentd (145 views)
2017-09-26 18:23:31

cybrmynd (245 views)
2017-08-02 12:28:51

cybrmynd (241 views)
2017-08-02 12:19:43

cybrmynd (240 views)
2017-08-02 12:18:09

Sralse (254 views)
2017-07-25 17:13:48

Archive (872 views)
2017-04-27 17:45:51

buddyBro (1016 views)
2017-04-05 03:38:00

CopyableCougar4 (1573 views)
2017-03-24 15:39:42

theagentd (1373 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!