Re: Know any good OOA/D book



johnzabroski@xxxxxxxxx wrote:
On Nov 23, 1:08�am, topmind <topm...@xxxxxxxxxxxxxxxx> wrote:
You may be interested in this: my table-oriented version of Robert
Martin's payroll example:

http://www.geocities.com/tablizer/payroll2.htm

Thanks,

However, you seem to misunderstand my motivation slightly. Perhaps as
a result, you are tailoring your message incorrectly.

Regardless of the approach I use, for large-scale software, I need to
stand on the shoulders of giants.

One trick is to *not* make large-scale software. Break it up into
pieces. RDBMS are very helpful for doing such. The RDBMS acts like the
Nile while the smaller apps are like villages on the Nile's edge.

I won't claim that all domains are subject to this, but most biz apps
I've seen are. Some tend to make big monolithic apps for political
reasons or habit, not out of sound thinking. App size generally does
not scale linearly as far as maintenance labor needed for it. Thus,
you usually save more by keeping the apps fairly small. Sharing
between the teams would be by mutual convention, not out of a forced
frameworks.


I need to be able to read large source code bases, derive their
strengths and weaknesses at an architectural level, and figure out how
to use existing code as "source code capital" to feed the investment
in my project.

Another desire of mine is to make sense of messes, as a consultant,
and clean it up -- quickly.

I've learned reading a lot of prose, such as yours or even Robert
Martin's, doesn't help me nearly as much as understanding
architecturally either what went wrong or why, despite a programmer
making every right decision every step of the way, I still can't use
his solution. A good example of this is the impedance mismatch
between batch compilers (which are optimized for throughput) and
interactive compilers (which are optimized for responsiveness to real-
time changes in the source code, such as a user typing inside an
IDE). A batch compiler provides no hooks for interactivity, because
doing so would be negligent design and compromise the quality of the
product, which is primarily based upon speed. As a self-professed
"procedural/relational" programmer, this should be eerily familiar
shortcoming to you: SQL stored procedures tend to do a poor job
reporting error messages, even on development SQL-based DBMS servers.
This is because the stack frame overhead for stored procedures is
significant enough that overhead for error reporting in generating the
stack frame would reduce throughput. A Pragmatic Programmer would
write an extension to SQLServer PowerShell that, on error, for a given
command where batch abort switch is specified, will automatically
launch Google's Search API to return the URIs and previews of the top
N results, fed into a bidirectional pager. As he/she diagnoses the
errors, he adds to a persistent hash table notes on how to debug
similar error messages in the future. It is not perfect, but it is
better than stumbling around in the dark.

As an aside, I enjoy reading or hearing Foxpro programmers talk about
"their way" of doing things. But I'd be remiss if I put it into
practice, because it is not nearly automated enough for me at the
architectural level. It's still too disciplined and relies too much
on programmer skill to organize complexity.

I doubt there is any way NOT to rely on skill and experience to get a
good system. It's a minimum requirement. Messes can and are made in
OOP all the time. What other profession do you get the best without
having the best at the helm? (other than cutting-edge breakthroughs
that require too much risk for the established to stomach.)

Paul Graham has suggested that the purpose of OOP is to keep mediocre
bored drooling programmers from screwing up too many things by herding
them with bureaucratic interfaces and scaffolding. Maybe OO is indeed
better at this. I wouldn't really know because I leave such
organizations when I get a chance.


I do use a data dictionary, but my systems are still object-oriented.
I consider a data dictionary to be orthogonal to object-orientation.
In fact, if you look at the "cutting edge" programming languages, then
you'll see they effectively use some form of a data dictionary, too.
For instance, Clojure's approach to managing identity and state and
therefore managing concurrency, uses values and change. http://clojure.org/state

A data dictionary allows me to model my objects in a very agile way,
and makes refactoring my object model much easier. However, AND THIS
IS VERY IMPORTANT, I define a set of architectural constraints that
allow me to specify conformance to OO. For me, OO is just a synonym
for "well-designed software following a specific set of architectural
constraints". I've developed these constraints over years of
developing software, reading about software, studying others' code,
and generally being interested in being far more productive than the
average programmer. I consider it the programming equivalent of a
Personal Efficiency Program -- not perfect, but guaranteed to get your
mind off the wrong things and focused on Getting Things Done Now and
in the Future.

Code example?


By the way, deprecate your notes on Control Tables -- they are a
throwback to Process Activation Tables in the 1960s. Jonathan
Edwards, a research fellow at MIT, presented a much better approach at
OOPSLA two years ago: Schematic Tables. http://subtextual.org/subtext2.html
Most architectures underwhelm me with their support for specifying
decisions and behavior substitution. Schematic Tables don't. Your
"Control Tables" is "not even wrong", but understandable given you
probably wrote it awhile ago and just haven't kept up with advances in
object technology. Keep it around for historical keepsake, but Mark
As Deprecated.

In practice I do not rely on direct control tables that much. They
have their place for certain apps, but one should not get carried
away.


Where most cutting edge techniques are underwhelming me, and where
most prior technology has underwhelmed me, is the ability to create
comments that match the specification. The only decent way I've found
to do this is through DSLs that are effectively data dictionaries, but
it is a costly process to develop them.

Perhaps if tools made creating such easier. If table-oriented
programming became popular, then more table-friendly tools would
exist. Look at all the effort and complexity put into the big bloated
Object-Relational mappers. Imagine if all that effort was re-focused.

-T-
.

Relevant Pages

  • Re: Know any good OOA/D book
    ... I need to be able to read large source code bases, ... architecturally either what went wrong or why, despite a programmer ... Most architectures underwhelm me with their support for specifying ... to do this is through DSLs that are effectively data dictionaries, ...
    (comp.object)
  • Re: For assembly, C# or VB or C++ ?
    ... it you are a VB programmer then it is not as easy. ... always be able to find a decent job. ... run the C's apps and most of the embedded programming is done in the first ... >> I chose C# because the source code for the .NET platform is in C#. Makes ...
    (microsoft.public.dotnet.general)
  • Re: rfc: evoting dead in 20 lines
    ... the first stage is writing the human language source code. ... from when a programmer begins writing the source code until that code ... For bugs and performance. ... the source code is analyzed by security programmers before the ...
    (misc.legal)
  • Re: rfc: evoting dead in 20 lines
    ... proprietary election software is created in two stages called ... the first stage is writing the human language source code. ... from when a programmer begins writing the source code until that code ... the source code is analyzed by security programmers before the ...
    (misc.legal)
  • Re: Luxasm news
    ... As the programmer works on their source code, ... This is excellent for learning the language in double-quick time... ... We are NOT re-compiling the source code entirely ever time, ... 1.3GHz)...yet, somehow, Luxasm can't process single source lines of, ooh, ...
    (alt.lang.asm)