The rules of object ownership

Last week's installment, which introduced HREF="http://www.itworld.com/App/554/ITW814/">the four
rules of software modeling, ended with a spot-the-bug problem concerning a
financial ledger.

The bug occurred when the user deleted a transaction, then pressed F5 to refresh the
view. Since Item::OnDelete deleted the transaction
directly, the ledger did not know to remove it from its list. Hence, when size=+0>ListViewControl::Refresh iterates the transactions in the ledger,
it tries to create an item based on a deleted Transaction.

The rule of ownership defined

At the root of this bug is a violation of one of the rules of software modeling: the
rule of ownership. The way to fix this bug is to have size=+0>Item::OnDelete call size=+0>Ledger::DeleteTransaction, passing in the pointer to the
transaction to be deleted. Since the Ledger is the owner of all Transactions, it is
responsible for deleting them.

The rule of ownership, which defines the lifetime, control, and placement of objects,
stipulates the following three conditions:

• The owner of an object is responsible for its creation and destruction
• Every object has exactly one owner
• Ownership is not transferable

A closer look

Let's study these parts individually. First, the owner of an object is responsible for
that object's creation and destruction. That is not to say that the owner necessarily
creates the object itself -- it may use a factory. We'll revisit factories toward the
end of this installment.

No one but the owner may destroy an object. As the financial ledger example shows, if
an object destroys another that it does not own, problems can occur. An object may
request that another be deleted, but it must always defer to the victim's owner.

Second, every object has exactly one owner. Since every object in existence was created
by something, each one has an owner. Furthermore, two objects cannot share the
responsibility of ownership, because an object can only be created or destroyed once.
Hence each has one and only one owner.

Because of this, the path of ownership defines a tree within the software system. As we
all know, a tree has one root. The root of a software system represents the system
itself (application, applet, module, etc.). The root and singleton objects are created
and destroyed intrinsically. They exist from the start of the system to its
termination, and therefore their owner is outside the developer's control.

The third part of the rule of ownership is that ownership is not transferable. Once an
object owns another, it cannot pass that responsibility off. The use of a factory
appears to be in violation of ownership, but semantically speaking it is not. The
factory creates the object on behalf of the owner. The owner is still responsible for
the object's creation; it simply uses the factory. Since the factory immediately
returns the object and does not retain any information about it, it is never actually
the owner.

In the next installment, we will study some of the ways to implement ownership using
different technologies.

» posted by abennett

ITworld.com

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine