From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.135.21 with SMTP id j21mr34308856iod.2.1448450577679; Wed, 25 Nov 2015 03:22:57 -0800 (PST) X-Received: by 10.182.125.3 with SMTP id mm3mr307828obb.13.1448450577660; Wed, 25 Nov 2015 03:22:57 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!mv3no2167609igc.0!news-out.google.com!l1ni8391igd.0!nntp.google.com!mv3no2167602igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 25 Nov 2015 03:22:57 -0800 (PST) In-Reply-To: <1ephv5ugr5mib$.9ehadf3dddct$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=94.107.233.114; posting-account=6m7axgkAAADBKh082FfZLdYsJ24CXYi5 NNTP-Posting-Host: 94.107.233.114 References: <04eb6626-644b-4b16-a329-c35659a9fbe2@googlegroups.com> <1ephv5ugr5mib$.9ehadf3dddct$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: operation can be dispatching in only one type From: Serge Robyns Injection-Date: Wed, 25 Nov 2015 11:22:57 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:28536 Date: 2015-11-25T03:22:57-08:00 List-Id: 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: >=20 > 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 th= e > interface. It should have had public components with read access acting a= s > 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, no= t all types need to be fully ADT's. Like in my example an account has a se= t of properties which may be revealed in the public part. Why hide them? = Following your logic, we could have "business" objects with well know prope= rties, then inherit from it to create implementation variants for persisten= t access with getters/setters. This is how I could use the "Bridge" Design= Pattern or "Adapter". Now, I've used the following construct instead (whi= ch is very close to the Bridge pattern. package Accounts: type T_Account =3D> defines the basic properties and oper= ations. package Accounts.DAO: type Factory is limited interface =3D> Defines an int= erface to read/write clients from a "data store" as a child package of acco= unts. package Data_Store : type T_Abstract_Date_Store is limited interface Accoun= ts.DAO and Client.DAO and ....; =3D> Assembles all the interfaces in a sing= le interface type. package Data_Store.In_Memory: type T_Data_Store is limited new T_Abstract_D= ata_Store with private; =3D> implements an in memory data_store package Data_Store.SQL: type T_Data_Store is limited new T_Abstract_Data_St= ore with private; =3D> implements a GNATCOLL.SQL data_store. I could creat= e 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 beh= ind the business object. Now I've to do the two actions in the business lo= gic: first update T_Account object and then call T_Account.DAO operations t= o "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".