ACCU Home page ACCU Conference Page ACCU 2017 Conference Registration Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

pinData Attribute Notation - Part 3

Overload Journal #30 - Feb 1999 + Programming Topics   Author: Reginald B. Charney

This is the third in the series on Data Attribute Notation (DAN). DAN is an object-oriented coding style that emphasizes data abstraction. It is meant to closely relate abstract concepts as defined in both the analysis and design stages of a project to the project's actual implementation. The intent is to minimize the differences amongst these three stages. This part of the series discusses the equivalence between DAN and designs centered around procedural classes like Michael Schelkin's Abstract Data Interchange classes[Schelkin].

Many systems are centered more around actions that need to be taken (action-centric) rather than around the data that needs to be manipulated (data-centric). For example, a messaging system is an action-centric application that invokes a call-back routine when a given event occurs. While the event is a piece of data, the main concern is the message handling. Another example is a dispatching system. Its main concern is effectively using its personnel and inventory resources. Of secondary interest is any single call, individual service person or spare part.

This article tries to unify the treatment of data-centric and action-centric systems.

Action-Centric Systems

An action-centric system uses objects as "wrappers" for procedure code. There is little if any data associated with an object of an Action class. Listing #1 shows an Action class as Michael Schelkin would define it.

class Action
  virtual int run() = 0;

static int si;

class Reset : public Action
  virtual int run() { si = 0; }
class EndIt : public Action
  virtual int run() { si = -1; }

void doIt(Action *ap)
  Reset *rp = new Reset;
  EndIt *ep = new EndIt;
  doIt(rp);  // Reset::run()
  doIt(ep);  // EndIt::run()

Listing #1: Action classes

In Part 2 of this series [Charney], I discussed programs being composed of fragments that could be combined in various ways. Listing #2 shows a sample using iterators and strings representing parts of programs.

class Reset { };
class Init { /* ... */ };
class Body { /* ... */ };
class Term { /* ... */ };

Init i1("
  Reset r;
  AllPetOwners apo;
  APOiter apoI(apo);
Init i2("apoI << r;");
Body b2("
    cout << apoI << endl;
Term t1("return 0;");
Fragment f1(i2,b2,Term(""));
Fragment prog(i1,f1,t1);

Listing #2: Fragments Using Strings

As Michael Schelkin pointed out, these strings could be instances of Action classes or their derivatives. Also, initialization and termination code can be implemented using constructors and destructors. So Listing #2 could be rewritten using Action classes as shown in Listing #3.

AllPetOwners *apop;
APOIter *apoIp;
Reset r;

void init1()
  apop = new AllPetOwners;
  apoIp = new APOiter(*apop);

void term1()
  delete apop;
  delete apoIp;

void init2() { *apoIp << r; }
void body2()
    cout << *apoIp << endl;

class Action
  virtual int run() = 0;

void doIt(Action& a)

class Fragment : public Action 
  typedef void (*AF)();
  AF i;  // initialization code
  AF b;  // body code
  AF t;  // termination code
  Fragment(AF ii, AF bb, AF tt):
  i(ii), b(bb), t(tt) 
  { if (i) i(); }
  ~Fragment() { if (t) t(); }
  virtual void run()
  { if (b) b(); }

// initialize f1 using init2
Fragment f1(init2,body2,Term(0));

// initialize prog using init1
Fragment prog(init1,f1,term1);

doIt(f1);  // run body2
doIt(prog);  // run f1 (ie. body2)

// destroy prog after term1 run
// destroy f1 with no term code

Listing #3: Fragments Using Action Classes

The function doIt() is a simple form of an applicator function. An applicator function takes one or more arguments, one of which is another function that is applied to the remaining applicator arguments. In Listing #3, doIt() invokes the function that is a member of doIt's argument. There are no other arguments. In Listing #4, the doIt() function is defined to handle Action classes that take arguments.

class X { /* some class */ };
class Y { /* another class */ };

class Act2
{ // 2 arg action
  virtual int run(X& x, Y& y)=0;

void doIt(Act2& a2,X& x, Y& y)
{,y); }

class MyAct2 : public Act2
  virtual int run(X& x, Y& y)
  { /* some action */ }

MyAct2 a;
X x;
Y y;

doIt(a,x,y);  //,y)

Listing #4: doIt() with 2 or 3 Arguments

The advantage of doIt() is any class derived from an Action class invokes the appropriate run() member function because of the virtual function mechanism.

Combining the essense of DAN and action-centric code, we come to the following conclusions:

  • objects are known by their attributes

  • an instance of an attribute can be applied to any object having that attribute

  • an instance of an action class can be applied to an object having that action class an an attribute.

  • if an action is a class then the action class must be an attribute of the object for the action to apply to the object.

  • an action performed on an object affects the state of the object and therefore the value of one or more of its attributes


Does a pointer to instance of an attribute class fit in with DAN?

If a message handler is an action class, can we say:

  MsgHdlr mh;
  Msg m;
  mh << m;

Can we create a MsgHdlr instance based on type of message that it is meant to handle by defining the instance using constructors with the message as an argument?

  Msg1 m1;
  Msg2 m2;
  MsgHdlr hd1(m1);
  MsgHdlr hd2(m2);

In the examples of feeding a dog meat and walking a dog 5 miles, the first is better handled by a member function while the second can be handled using DAN.

  Meat m;
  Dog d;

  d << Walk(5);


For example, consider feeding an animal. You can feed meat to a dog and you can feed oats to a horse. Normally, you would define a feed() virtual member function for Dog and one for Horse, each derived from Animal. You would then accept as Food the derived types Meat for Dogs and Oats for Horses. Thus, you could write the code in Listing #4.

Dog d;  // derived from Animal
Horse h;  // derived from Animal
Meat m;  // derived from Food
Oats o;  // derived from Food

d.feed(m);  // feed meat to dog
h.feed(o);  // feed oats to horse 

Listing #4: feed as member function

However, if we treat actions as if they were classes, then the concept of feed could be represented by the action class Feed. The fragment in Listing #4 could then be written as shown in Listing #5.

Dog d;  // derived from Animal
Horse h;  // derived from Animal
Meat m;  // derived from Food
Oats o;  // derived from Food

d << Feed(m);  // feed dog meat
h << Feed(o);  // feed horse oats

Listing #5: Feed as action class

While the code in Listing #4 is more usual, it requires that the member function feed() for each animal be overloaded for each food type that the animal eats. An alternative would have feed() accept a generic food type like Food, thereby losing the context sensitivity originally sought. That is, we can no longer protect against feeding meat to horses or oats to dogs.


[Schelkin] The Object or The Action by Michael V. Schelkin, CVu - The Journal for the C Users Group (UK) Volume 5 Issue 1, November 1992.

[Charney] Data Attribute Notation - Part 2 by Reginald B. Charney - The C++ Journal, Vol 2. No. 2 1992

Overload Journal #30 - Feb 1999 + Programming Topics