Re: operation can be dispatching in only one type

[Serge Robyns <serge.robyns@gmail.com>]

On Wednesday, 25 November 2015 09:25:07 UTC+1, Dmitry A. Kazakov  wrote:
> On Tue, 24 Nov 2015 14:48:24 -0700, Jeffrey R. Carter wrote:
> 
> In fact it does not hide the implementation of values. That is one of its
> design flaws. The implementation of protected components is mixed with the
> interface. It should have had public components with read access acting as
> a protected function and write access doing as a protected procedure. The
> private components should have been declared in the package's private
> section or the package body.

I fully agree with you.  This is what I really wanted to have.  However, not all types need to be fully ADT's.  Like in my example an account has a set of properties which may be revealed in the public part.  Why hide them?  Following your logic, we could have "business" objects with well know properties, then inherit from it to create implementation variants for persistent access with getters/setters.  This is how I could use the "Bridge" Design Pattern or "Adapter".  Now, I've used the following construct instead (which is very close to the Bridge pattern.

package Accounts: type T_Account => defines the basic properties and operations.
package Accounts.DAO: type Factory is limited interface => Defines an interface to read/write clients from a "data store" as a child package of accounts.
package Data_Store : type T_Abstract_Date_Store is limited interface Accounts.DAO and Client.DAO and ....; => Assembles all the interfaces in a single interface type.
package Data_Store.In_Memory: type T_Data_Store is limited new T_Abstract_Data_Store with private; => implements an in memory data_store
package Data_Store.SQL: type T_Data_Store is limited new T_Abstract_Data_Store with private; => implements a GNATCOLL.SQL data_store.  I could create a Gnoga version too.  Which I'm seriously considering. This is the beauty of OO.

Now all business functions have to use the DOA functions (getters/setters) to retrieve and update objects.  Initially I was hoping to hide the DAO behind the business object.  Now I've to do the two actions in the business logic: first update T_Account object and then call T_Account.DAO operations to "retrieve" or "store".  After giving it some thought I've accept this as this enable me to have "control" on the moment for the updates, commits and roll-bacls to the "store".