Re: Simples Rules make creating Big Balls of Mud impossible.
- From: AndyW <foo_@xxxxxxxxxxxxxxxx>
- Date: Thu, 11 Jan 2007 19:22:33 +1300
On 10 Jan 2007 15:41:37 -0800, "topmind" <topmind@xxxxxxxxxxxxxxxx>
wrote:
AndyW wrote:
On 10 Jan 2007 11:22:48 -0800, "topmind" <topmind@xxxxxxxxxxxxxxxx>
wrote:
John Carter wrote:
It has always amazed me.
Why do Client Service architectures work so well?
1) It's an internally self-consistent/closed system approach. You can you can
build/decompose client/server systems out of/into client/server chunks. ie. No
matter how large/small you grow/shrink, you can maintain this structure.
All the way from single functions to million SLOC monsters.
2) If you stick to these rules, you _never_ get a Big Ball of Mud.
3) Finding _any_ upward references immediately tells you that your have a
tangle forming, so don't do that.
3) You can build them up in layers, and unit test at every interface without
pulling in the whole Big Ball of Mud.
4) Design by Contract asserts and invariant checks form an
excellent bracing internal test framework.
5) You can create controlled mock services that allow you to "test from
inside".
This is more or less the beauty of procedural/relational programming.
You *don't* create one big fat application, but lots of small and
medium apps that talk to the database and communicate between each
other almost entirely thru the database. Each small app is like a small
town that uses the Nile (database) to communicate and trade with other
villages (apps). Sharable libraries of routines are available, but not
forced. They are "voluntary frameworks" or utilities and kept small and
simple so that they can be reworked for specific needs. Generic
one-size-fits-all marriage-or-death frameworks are a lost cause. The
"Big EXE" syndrome/thinking of OOP creates big balls of mud. OO biz
modeling is Pork City.
(It is important to design the schemas reasonably well. Good or at
least reasonable schemas are one of the few "musts" for this to work.)
From my experience many inhouse systems are built this way. Little
programs that do simple things revolving around a large database that
contains everything.
I suspect the DBAs job is full time just figuring out what the
database actually does half the time :)
Many of the so called OO people often need to realise that not
everything needs to be objectified. Procedural is good enough in most
cases (and can be quite easily mixed with OO programs).
I am not sure what you are implying by "good enough". Many OO'ers say
that OO's benefits only or mostly come about under "large complex
applications". This may indeed be true. But if one can get a better net
result by splitting big applications into more small and medium ones,
then the need to manage one big app is simply just gone. OO is overkill
for smaller apps.
It is roughly like saying that nukes are better at killing 20,000
buffalo than guns. However, if you avoid the need to kill 20,000
buffalo, then you can stick with the simpler guns and not have
radioactive rivers etc.
Thus, technically the OO'ers may be right with regard to size. But, OO
may be the right tool for the wrong problem.
-T-
Good enough = fit for purpose (ie. it does the job ok)
With my radical purism approach to OO I have a set of rules that
define what an object is and what it isnt. Everything that fits in
the not-an-object basket gets done using procdural code (C or C++
which I call C with classes when used this way).
Not-an-object code is generally things like services, mixins,
handlers, coms routines and non-object frameworks.
Stuff that goes in the 'an-object' basket must satisfy the contraints
of identity, state, action and tangibility all of the time. But...
the internals of an object may leverage the stuff in other layers
(usually the framework and service code)
This allows for the objects to focus on doing objecty stuff without
having to sweat the detail of how they do it.
I tend to use the OSI 7 layer approach to application design, with the
non-OO stuff being in the lower levels. Often, when creating an
application one doesnt need the upper levels of code (for example back
end server code as an example that is just processing sets of raw
data), so one ends up with a small non-OO programlet so to speak.
At the end of the day, its the type of program that determines if it
becomes OO or not (rather than the approach [OO or procedural] one
takes to developing the program which is the normal method).
Andy
.
- Follow-Ups:
- References:
- Simples Rules make creating Big Balls of Mud impossible.
- From: John Carter
- Re: Simples Rules make creating Big Balls of Mud impossible.
- From: topmind
- Re: Simples Rules make creating Big Balls of Mud impossible.
- From: AndyW
- Re: Simples Rules make creating Big Balls of Mud impossible.
- From: topmind
- Simples Rules make creating Big Balls of Mud impossible.
- Prev by Date: Re: Simples Rules make creating Big Balls of Mud impossible.
- Next by Date: Re: Delta
- Previous by thread: Re: Simples Rules make creating Big Balls of Mud impossible.
- Next by thread: Re: Simples Rules make creating Big Balls of Mud impossible.
- Index(es):
Relevant Pages
|
