Re: Thoughts on Design

"Ingvar Nilsen" <no.spam@xxxxxxxxxxxxx> wrote:

Lars Fosdal wrote:

So let me rephrase myself: You shouldn't evolve an architecture.

I did not see you last night at "Scuba" in Oslo?
(I saw none of the Delphi guys)

The famous Tom Gilb talked about this:
http://www.gilb.com/community/tiki-page.php?pageName=Methods

And BTW, he might have a different opinion, but I am not absolutely
sure. I depends on what you define "architecture" and what you define
"implementation".

Whaaa? I missed a beer event again? Where was this one announced?

Software design according to Lars Fosdal :P
(Straight from my mind. Terms and conventions may not follow
litterature)

*Architecture* is - very simplified - deciding on what black boxes
that I need, and defining the boundary interaction (events/data
exchanges) between those boxes. At this point, I'm are still mostly
on the conceptual stage.

*Design* is when I try to squeeze all my requirements into the black
boxes, deciding on exactly how the interfaces need to look to carry
the contents and handle the events I need.

During these two processes, which are integrated and iterative in
nature - I try thinking ahead, trying to ask "What if" for each
method, process, piece of data or parameter.

F.x.
- Should I add a wrapper around the data to encapsulate their content?
- Should I add a version / size to my data structures to allow changes
in the future, or make the parameters a chain allowing piggybacking
more content?
- Can I make the interface or event stupid enough to not care what
content is being passed?
- Should I make this interface blocking or asynchronous? (These days I
tend to go for asynchronous)
- Will I need a "cookie" like mechanism to carry low level data that
are implementation specific across black box boundaries? (I try very
very hard not to)
- How do I represent or pass along error situations?
- How do I do error recovery?
- Will I need discovery mechanisms? Pooling? Session oriented vs
session less? Redundancy? Clustering?
- Do I need to think about timing? Order of sequence? Parallellism?
- The list goes on... I think you get the drift.

I then repeat that process of deciding the boxes within boxes and
their interfaces to the level of granularity that you require. APIs,
formats, protocols, objects, etc. Personally, I tend to try to make
my APIs as uniform as possible (usage recognition saves time).

*Implementation* end up being
1. Writing the glue that will make your interfaces behave as you
intended and writing eventual test harnesses that will enable you to
regression test your mechanisms on different levels
2. Implementing or integrating the bread and butter that your black
box attempt to conceal for the external boxes (typically biz.logic aka
processing, storage, transport or presentation)
3. Writing the safety net which ensure your interface don't crash and
burn but degrade or fail gracefully if it gets something that falls
outside the intended parameter use, or similarily, don't crash and
burn but degrade or fail gracefully if a subsystem presents an error
situation.

What more can I say? Except maybe: Please be gentle? ;)
.