Well,
I thought I wanted Client to be an class, with accessors for the attributes and then have several instances of them, one for each client.

The same for orders and items

Perhaps a class for konfiguration data instead of globals floating around

And then to avoid redundancy the TYPE could be "class"-ifyed

I known my post is muddy at best, but what I was trying to avoid is that the communication between objects would nessitate having to juggle several objects of different classes to perform the action.

As an example consider selecting what media a certain client wants his confirmation, which would be found in the client instance and pertinent data would also be found in the configuration instance.

And yeah I know, messed up design, but that was really the reason for my question

I am sorry but I don't understand the first statement. I know I am (much) less experienced then you but I thought people often encapsulate data in objects and use accessor methods to get at the data. The accessor methods provide verifcation of data structure over and above what the use of datatypes can provide.

With all due respect,

That would be "procedural programming with objects".

You can find much better approaches out there. (Yeah, it is in Java. Take good advice where you find it.)