views:

378

answers:

3

I have a very general design question, but I'll frame it in concrete terms with an example.

Suppose you're working on embedded software for a digital printer. The machine has 4 print heads (for each of the C, M, Y, K colors). Each print head performs the same task: fetching toner and putting it on the page.

At runtime, we could organize our API in two distinct ways. Either we follow a logical (aka "functional" or "process") design, so that client software can control the printing process across all print heads (e.g. change the brightness of all colors at once). Or we follow a physical design, so that client software can control each print head individually (e.g. change the brightness of only the magenta color).

This is a classic dilemma in software design: We either organize by activity or by architecture. By function or by form. My question is: are there any solid criteria for choosing one over the other? Different projects will choose differently and can both be right depending on their own situation; so I'm not asking which is best, only how to choose. E.g. I would be interested in your ideas about loose coupling, maintainability, layering, role-oriented design, architectural design patterns, etc.

+4  A: 

Write an interface that follows the physical design. On top of that you can layer a logical interface that will use the physical one. So don't choose when you can have both.

eljenso
A: 

I guess it depends on what your clients wants - the requirements of the system fro the clients point of view.

Personally I would favour decomposing the problem into two smaller parts / questions :

The low level code to access and control the physical components - the physical API. (This will always need to be done in any design scenario that you choose so it can be focussed on and done).

Using the API above provide a more function/process structured API (if necessary)

HTH Len

LenW
A: 

Do the most simple thing that meets the project requirements.

Coding both the logical and physical designs may introduce unnecessary development effort (and hence cost) if the logical design meets the requirements of the project.

JustABitOfCode