Common Classes vs. Domain Specific Classes

Right now, I have had an interesting phone call with a potential customer. Quite important to mention - my conversational partner has lots of experience using code generators.

After a 10 minute talk, it came to my mind, that we are talking about different things. My conversational partner has the idea, that generators are transforming Common Classes from a graphical representation to a textual code representation.

Common Classes mean classes as we now them from object-oriented languages or UML. In a nutshell, such classes do have a class name, a base class, members variables and member functions.

If we have to represent a Domain-Object, let's say a Service-Object, all the properties of this Service have to be expressed by member variables and member functions. When working with Common Classes, it makes no difference whether we implement some service calls or functions to set up the service environment.

class MyUserService implements IService
{
// Service Calls
public boolean registerUser(int id, String name) {...}
public boolean deregisterUser(int id) {...}
public User getUser(int id) {...}

// Service Environment
public boolean setUserRegistry(UserRegistry userRegistry);
public boolean resetUserRegistry();
}

Using Domain Specific Classes on the other hand side, we can distinguish between functions concerning Service Call and Service Environment.

Since we are not working with Common Classes, we first have to design our Domain Specific Classes. Means, we have to specify the Attributes (i.e. class name) and the relation between these classes. In actifsource, we do this task in a diagram editor using an UML-like syntax.



Since we do have an exact Specification of our Domain Specific Classes, the Domain Objects are no longer of type Class, but type of the domain-specific class Service.

As shown above, we can now create dozens of specific services of type Service. As you know from your experience, every specific service has a similar implementation.

By example, we write a class for every service. Furthermore, we write a function for every service call. Subsequent, we do have do write a typed parameter for every service call argument.

Today, this tedious and error prone work is done for every service over and over again. But how would it be, if we could state our intension just by writing template code? Template code which doesn't depend on Common Classes - but which refers to Domain Specific Classes!



The idea behind actifsource is writing templates, bases on Domain Specific Classes, rather than Common Classes! Doing so gives you the possibility to write templates as easy as you write code.

Working with Domain Specific Classes allows you to access all the attributes of your domain in the templates which is rather easier than coping with Common Classes!