Thread: Thoughts on a design anyone?

Hi all,

There is a project i have been working on - in another language - darn obsolete vba and i have been trying to push for the time to write in c++ as a much better solution - which scales to the problem properly - I am not sure it will be adopted, but i would like to hear any thoughts on methodology you might use to acheive the goal.

It is quite specialised financials data as input.

The basic framework wants to accomodate the fact that whilst the clients have very similar data they each potentially have subtle differences - stuff will be common to all, other stuff will not.

At a high level the client could also be subclassed into typeA and typeB

There are a set of tests to be run against the data - the tests have been grouped into categories, these categories will be common to all - the tests within the categories will be where main differences are found

there are quite a lot of clients!

Is it naiive to think i could somehow create a virtual client superclass that can 'know' how to construct itself from the get go and what category spin on the test functions it needs? - I mean by way of avoiding literally writing a new class for every client. - basically i am trying to avoid too much code replication - most things will be very similar, but there are enough potential differences to make just using arg values in functions say a bit of a pain.

Is it naiive to think that is a hard thing??

Maybe im not being too clear - and maybe if i cant picture it then apart from lacking the knowledge then could it also be its a bad design idea anyway and maybe its just a case of lots of constructors and overloaded functions or whatever? - Is there anything in templating that might be employed?

At present within the VBA i basically have no inheritance or nowt - the best i have come up with is a clientSpecificClass module - which can contain a category class object - which i can instansiate as one of the 7 other categoryClasses i have declared in other modules - my tests are types - sort of structs but the stupid vba does not allow me to have them as class members - so i had to resort to a global one, blah blah - whole thing is a pain to write in and very restrictive

Cheers for reading - welcome any comment.

I wouldn't do this with a class hierarchy, unless you want to rewrite code every time you add a new client (that might keep you happy, if you are paid by the hour, but whoever is paying you would probably be less than ecstatic).

Presumably every client has a set of attributes ... properties that have some value. Attributes can be anything from simple booleans (eg vip_client) through to characteristics like a business name, a street address, a phone number, and things like that.

What you need to do is identify a set of attributes that all clients have. Then simply have (say) a "Client" class (a description of common attributes of all clients) is able to save the values of its attributes to persistent storage (eg a database) and retrieve those attributes. You will probably want the Client class to support some common operations (a default constructor that creates an instance of Client with all attributes at chosen "default" values), a copy constructor (that can create a second instance of Client representing the same actual client), various means of setting and retrieving attributes, some means of comparing two objects of type Client (eg to see they actually represent the same actual client). Then all you need to do is work out a way to contain a set of multiple clients (which, if you've done your Client class right, can be achieved by using a standard container from the C++ library).

The real need - before you start cutting code - is doing a thorough enough analysis in order top identify the attributes that all clients have. The key is remembering that the data structures in your program (which are how the programmer thinks about things) do not have to map directly to a users workflow. A user-selection of "VIP client" could, for example, map to toggling a boolean attribute of a Client, rather than creating an object of a different type. The user, in fact, should not be exposed to implementation details in the backend of the program they use.

Incidentally, this type of approach could have been used in VBA as well. There is nothing inherent in VBA that forces you to write distinct code for different types of client.

Thats some good advice thanks - The generic 'client' i had identified yes, - together with its default constructor - Inheritance seemed to be in the mix somewhere too - but i see your idea of a container as more appropriate yes- that hadnt occured to me and is worth looking at defo - And the VBA is working out ok really as you say - I was just concerned about how it would exand as the other client requirements come in, but i have tried to build support for that code-wise. Regarding databases, i see now i may as well just store client attributes in a worksheet - There would not be a huge amount of data - Problem regarding identifying all the attributes is i am still in the dark about that - i am being asked to start it for one client - get it done - oh and by the way make sure it can accomodate other clients too - when the employer doesnt even know yet the particulars! Its not ideal like, They basically want to sell report pack to one (which was commissioned anyaway) then go to others, but hey haha. Cheers.

the data structures in your program (which are how the programmer thinks about things) do not have to map directly to a users workflow.

Can you elaborate on what you were saying here? It seems to remind me of realisations i have regarding this problem, had but i cant put my finger on it

A user-selection of "VIP client" could, for example, map to toggling a boolean attribute of a Client, rather than creating an object of a different type.

I see that but my concern there was that the effect of the flag(s) have to be carried through into the processes then and checked all over the place - If i was trying to use common work functions?

Originally Posted by rogster001

Problem regarding identifying all the attributes is i am still in the dark about that - i am being asked to start it for one client - get it done - oh and by the way make sure it can accomodate other clients too - when the employer doesnt even know yet the particulars! Its not ideal like, They basically want to sell report pack to one (which was commissioned anyaway) then go to others, but hey haha.

In that case, build it for one client only. When looking at what works for that client, consider whether the attributes (as opposed to values of those attributes) are unique to a client. Don't go overboard with that though. Common sense applies. For example, it will probably make sense that a client has a postal address. It might not make sense (depending on your application) to expect that all clients ride motor cycles, or even need related attributes.

The only way you can ever work out if your design works for a second client, or can be extended to a second client, is when you have information about that second client. Then revisit your design, identify whether the attributes are common to both old and new clients, etc.

Tell the client (tactfully) s/he's been unrealistic if he expects you to create a reusable design based on information about only one client. The process of creating reusable designs usually starts with an effort to reuse something, and tease out common properties of the old and new use cases. You certainly can't create a reusable design based on only a single example (if you do, it's luck, not skill).

Originally Posted by rogster001

Can you elaborate on what you were saying here? It seems to remind me of realisations i have regarding this problem, had but i cant put my finger on it

The user doesn't need to be exposed to the internal workings of your code. For example, the user might want a facility to list all clients in a city, but the user interface doesn't need to expose the user to details of implementing that search by traversing a linked list. Similarly, the user might have separate screens for managing VIP clients or bad-debt clients. That does not mean that VIP clients need to be managed using different back-end code than bad-debt clients. It means that the user requests (say through the user interface) need to be translated into values of attributes that make sense in the bowels of your program.

That separation of concerns allows the back end of your program to be maintained separately from the front end. So, if you want to provide a "management interface" and a "salesman interface", you can - without changing how the program works internally.

Ok thanks for the advice,

You certainly can't create a reusable design based on only a single example (if you do, it's luck, not skill).

Well said! I hope i can get that over to them - at least to cover my own back haha

Originally Posted by rogster001

I see that but my concern there was that the effect of the flag(s) have to be carried through into the processes then and checked all over the place - If i was trying to use common work functions?

That is a trade-off. It comes down to whether there is a lot of places where that attribute results in substantially different codes. Checking a flag in two places might be more efficient than replicating a class with 20 operations, and tweaking the implementation of two of those operations. Checking a flag in 100 places might tip the balance the other way.

The thing is, you can't always predict which is best up front. If you create a second class by doing copy/paste of a lot of code, and only make minor changes to the copy, then the second class is probably a bad call. Conversely, if you are sprinkling 100 "if (vip_client) ..." around in your code, you might be better off creating a polymorphic base class and two derived classes (each representing a different "type").

The key is being willing to revisit your design as you get experience with maintaining it (eg adapting it to new use cases).

Your responses have proved a good sounding board, thanks.

If you create a second class by doing copy/paste of a lot of code, and only make minor changes to the copy, then the second class is probably a bad call.

Thats a very good point, and i think that is about where my design is , at the moment - Plus the potential for typos / overlooked minor changes after lumping code into classes is quite high - I think i am best writing a secondary version alongside this one with advice discussed in mind, The process will be a lot faster anyhow having already implemented the actual testing once, so i think can wangle that in- I am ok to submit the single client version for now.