Re: Design principles

[Jonathan S. Shapiro]

On Mon, 2007-01-15 at 03:47 +0100, Pierre THIERRY wrote:
> > > EUR
> > > ===
> > > 
> > > means that requirements of the system should be kept as small as
> > > possible, to keep resources available to user applications and
> > > enable use in limited environents (e.g. great number of users, high
> > > workload or embedded hardware).
> > 
> > ... or the system should admit of multiple implementations, *some* of
> > which have this property.
> > 
> > Perhaps you mean to say "the *minimum* requirements"?
> 
> I'm not sure a different implementation should be needed for different
> use cases. It's just that every operation should be able to perform with
> a very low minimum of resources.

Let me give an example, and try to make my distinction more clear.

There are many cases where an operation can be optimized by caching
partial results. The operation can be performed successfully with no
cache at all, but the cache improves performance.

On a memory-limited device, one might choose to accept lower performance
in order to eliminate the cache.

More generally, there is a fundamental tradeoff between resources
consumed and performance in many operations and implementations.

So, I would say that there are two kinds of things to minimize here:

1. Architected resources. That is: the specification should involve the
least number of conceptual entities that is possible, given the
requirements of the system. This is an architectural variant of the
"Principle of Least Mechanism" (which is a good principle, IMO).

2. Implementation resources. That is: the implementation should realize
the architecture using a level of resource that is ``reasonable'' for
the implementation environment, and the architecture should admit
implementations that involve minimal implementation resources.

> > Principle of Authorized Communication
> > 
> > An entity A should only be able to send messages to an entity B if it
> > can demonstrate the authority to do so.
> > 
> > Explicit Designation of Authority
> > 
> > When an entity wields an authority, it must *explicitly* designate the
> > source of the authority.
> 
> Don't they naturally come from POLA already (though these particular
> facets are worth noting). I already mentioned the latter.

Explicit designation is definitely separate from POLA. POLA says I
should have as little authority as possible. Explicit Designation says
that I should explicitly state exactly what authority I am using when I
use it.

The Principle of Authorized Communication needs to be re-framed, and is
possibly implied by POLA+ExplicitDesignation. The problem with the
principle as I stated it is that it admits a trivial realization by
authorizing all communications.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100