Nature of Objects in Aspire - journal

Nature of Objects in Aspire - journal

1. This is running notes on object creation facilities in Aspire

2. Related classes

3. Related factories

4. Objects are very often initiated from configuration file

1. Given an interface, instantiate its implementation from config file

2. So created objects are by default singletons

3. Can be made multiinstance at compile time by extending an interface (ISingleThreaded)

1. POJO like objects that can be singleton or multi instance

2. Functions that can be singleton or multi instance

1. Functions can create other objects like a factory

2. Functions can return data from databases

3. Functions can return hierarchical objects

4. Functions can read files, databases, json, xml etc.

1. Aspire has a natural tendency to peel logic from configuration as most objects are driven by configuration

2. This enables declarative programming

3. This also provides significant out of the box backward compatibility


//consider a psuedo interface with methods
interface IFile {m1, m2, m3}

//Have a couple of implementations
SomeClass1 implements IFile {}
SomeClass2 implements IFile {}

//in a config file
request.file.classname=SomeClass1

//You can do this in code now
IFile file = AppObjects.getObject("file");
file.m1()

//AppObjects is a utility that  invokes the 
//underlying factory

//file is a singleton here.

You can  make it a multi instance

SomeClass1 implements IFile, ISingleThreaded {}

1. it is a static class

2. it is a utility class

3. Has static methods that spin the Application level services such as configuration, logging, and factory that controls object instantiation.

4. See the source code of this class to see how it works and what methods it has

0. No interface all. Pure POJO (Singleton)

1. IInitializable //init method is called

2. ISingleThreaded //tag that says multi instance

3. ICreate //This object is a function

4. A combination of these interfaces control the behavior of the class being instantiated.

1. Object: See first if you are an object that confirms to an interface with multiple methods. If so you don't want to be a function or you don't want to extend ICreate (there are some exceptions)

2. Function: See if your job is a single method that DOES something like reads or write, every time it is created or called. Then you want to extend ICreate

DBProcedure //function singleton

DBProcedureObject //function multi instance

DBJavaProcedure //function, like a stored proc i n java

DataObject //experimental object (not a function)

SimpleDataObject

DynamicDataObject

ServiceObject

IMultiInstanceObject //POJO object (not a function)

IFactoryPart //function. base class of pipelines

AFactoryPart //Mostly inherited

AFactoryPart1 //some specialized functioality


ILog //for logging
IConfig //for a hierarchical configuration files (basic, xml, json)
IFactory //a way to apply policies and instantiate objects
IApplication //a container for the above 3

This article primarily focuses on the factory interface

1. Currently I use Factory4

2. You can write your own if you like

3. See the source code of Factory4 to tease out minute details of the behavior of objects created

So look up the source code for Factory4

On github "a" version of this factory4 is here

A number of other previous versions of the factory are here: in the default pkg for an application