Re: How to return an empty aggregate

[george.priv@gmail.com]

On Apr 5, 5:14 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 5 Kwi, 18:04, george.p...@gmail.com wrote:
>
> > Can you provide non-academic example?

I don't really mean to be rude by throwing short answers but was on
the road whole week while conversation is very interesting. So if
provoke some of that apologize. By non-academic I mean you just rip it
from the project you did and past (just snippets) and explain what is
application.  My original remark was due to a fact that I started
looking at all the objects I had written so far and, although use
Factories, Adapters and Relays never found anything that is empty.  I
won't deny there are some out there and that what I would like to see,
given the condition above, otherwise this thread will be endless.

Just scrolling through my code found this little example

   --
   -- Generic Agent Interface
   type Agent_I is limited interface and Disposable_I;
   type Agent_Any is access all Agent_I'Class;

   -- Receive the new data item and determine the state
   procedure Receive (Me : in out Agent_I; Item : Entity_T) is
abstract;
   -- Signal the alarm conditions
   function Alarm (Me : Agent_I) return Alarm_T is abstract;

The agent monitors oncoming entities for conditions that call for
alarm.  System has list of Agents that can be added/removed on the
fly.  Alarms by each agent can be OR'ed or AND'ed to generate the
state of the system. Theoretically one can do Null_Agent_Type that
will do nothing but there is no point in that since empty agent list
will give the same effect.  Any agent implementation has some context
associated, since Entities may get flaky and provoke unnecessary knee
jerk reaction.  Now one can make that into a strategy solution you
mentioned by splitting the Entity stream context into separate item.
Then Agent becomes pure logic machine and that will be "proper" OO
way, but seems impractical for my case though. The reason for that is
that Agent and the way data is conditioned is very inter-related and
generalize that will cause a lot of unnecessary LOCs and spread of
code that should better be kept localized.

More fundamental question is there any payback in separating strategy
and history (context). Which will be then History and Logic I guess?




>
> For the empty record?
> I thought I did already. :-)
> This might be a challenge, because we have no judge that can say
> whether something is academic or not.
>
> Consider a logging system that is designed with OO in mind. There is a
> base interface with some operation(s) for logging and a bunch of
> concrete implementations for various log destinations - one for disk
> file, one for network output, one for database persistency, etc. The
> part of the program that does something useful takes Log'Class and
> feeds its log entries via given Log'Class parameter to whatever
> happens to be a concrete Log implementation - a classic strategy
> pattern.
>
> What would you do to... switch the logging off?

There is some sort of logging (usually more then one) involved in
every project I do, thus there is always a switch and (sometimes) this
switch is flipped at run-time. Sometimes there is also a
Null_Destination.

But developing this logging theme let's consider a real (my) life
example.  You receive the events for logging but you don't want
5,000,000 records of the same to go in when some device malfunctions.
You rather want first 10, and something stating that this is serious
condition, etc. Is there a way to use stateless adapter or you have to
have a context?

George

>
> I would create the derived (concrete) log that is *empty* and does
> nothing and pass it as Log'Class to wherever it is expected.
> It cannot be simpler than that.
>
> Is it academic? I would do it at the nearest opportunity.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com