Design - cyclic dependencies

Design - cyclic dependencies

[Maciej Sobczak]

Consider:

--  a.ads:
package A is
   type T is new Integer;
   procedure P;
end A;

--  a.adb:
with B;
package body A is
   procedure P is
      X : T;
   begin
      B.P (X);
   end P;
end A;

--  b.ads:
with A;
package B is
   procedure P (X : A.T);
end B;

--  b.adb:
package body B is
   procedure P (X : A.T) is
   begin
      null;
   end P;
end B;

There are two logical modules A and B, implemented as packages.
There is no cyclic dependency between the specifications of these
packages and the code is legal.
Still, there is a design-level cyclic dependency between the whole
modules in the sense that A depends on B (A calls some operation of B)
and that B depends on A (B uses some type from A).

Being legal does not imply being good and therefore I ask: do you
consider this kind of design-level cyclic dependency to be acceptable?
If not, what measures would you recommend to correct it?
Extracting T to another package is probably the only reasonable
option, but then there are variants of it (child or sibling package,
etc.).

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Design - cyclic dependencies

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> Being legal does not imply being good and therefore I ask: do you
> consider this kind of design-level cyclic dependency to be acceptable?

There are certainly cases where such cycles are the best design.
But don't do it unless you have to, because cycles make the
packages involves more tightly coupled.  And try to keep the
cycles short.

There are even cases where spec-to-spec cycles are best,
which is why the "limited with" feature was added to Ada.

- Bob

Re: Design - cyclic dependencies

[anon]

Ada mostly uses a Modular Design Structure. 

The cyclic package structures are legal but a should not be used unless 
the algorithm requires it. Plus, they can cause "Bounded (Run-Time) Errors" 
[ RM E ( 10 ) ] which can result in deadlock for the elaboration or they 
can raise a Program_Error during run-time.

A common way around the cyclic design structure in using external 
packages is to use the "pragma Export/Import" statements. 

Now there are some algorithms that use cyclic design. These should 
limit all the cyclic routines to a single package. Such as in a 
procedure / sub-procedures design that follows:


  package Test is
      procedure A ;
  end Test ;

  package body Test s

      procedure A is

          procedure B is

              procedure C is

                  begin -- C
                    A ;
                  end C ;

          begin -- B
            C ;
          end ;

      begin -- A
        B ;
      end A ;

  end Test ;


But the best way is to re-write the cyclic algorithms to use the 
modular design structure.  In your example the type T should be in 
another package called may be C. In this design, the modular 
structure could be is maintain. 

package A 
  with B, C ; 

package B 
  with C ; 


--
--  c.ads:
--
package C is
   type T is new Integer ;
end C ;



In <1193401560.389194.282030@o3g2000hsb.googlegroups.com>,  Maciej Sobczak <see.my.homepage@gmail.com> writes:
>Consider:
>
>--  a.ads:
>package A is
>   type T is new Integer;
>   procedure P;
>end A;
>
>--  a.adb:
>with B;
>package body A is
>   procedure P is
>      X : T;
>   begin
>      B.P (X);
>   end P;
>end A;
>
>--  b.ads:
>with A;
>package B is
>   procedure P (X : A.T);
>end B;
>
>--  b.adb:
>package body B is
>   procedure P (X : A.T) is
>   begin
>      null;
>   end P;
>end B;
>
>There are two logical modules A and B, implemented as packages.
>There is no cyclic dependency between the specifications of these
>packages and the code is legal.
>Still, there is a design-level cyclic dependency between the whole
>modules in the sense that A depends on B (A calls some operation of B)
>and that B depends on A (B uses some type from A).
>
>Being legal does not imply being good and therefore I ask: do you
>consider this kind of design-level cyclic dependency to be acceptable?
>If not, what measures would you recommend to correct it?
>Extracting T to another package is probably the only reasonable
>option, but then there are variants of it (child or sibling package,
>etc.).
>
>--
>Maciej Sobczak * www.msobczak.com * www.inspirel.com
>

Re: Design - cyclic dependencies

[kevin cline]

On Oct 26, 7:26 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> Consider:
>
> --  a.ads:
> package A is
>    type T is new Integer;
>    procedure P;
> end A;
>
> --  a.adb:
> with B;
> package body A is
>    procedure P is
>       X : T;
>    begin
>       B.P (X);
>    end P;
> end A;
>
> --  b.ads:
> with A;
> package B is
>    procedure P (X : A.T);
> end B;
>
> --  b.adb:
> package body B is
>    procedure P (X : A.T) is
>    begin
>       null;
>    end P;
> end B;
>
> There are two logical modules A and B, implemented as packages.
> There is no cyclic dependency between the specifications of these
> packages and the code is legal.
> Still, there is a design-level cyclic dependency between the whole
> modules in the sense that A depends on B (A calls some operation of B)
> and that B depends on A (B uses some type from A).
>
> Being legal does not imply being good and therefore I ask: do you
> consider this kind of design-level cyclic dependency to be acceptable?

I have no idea what you mean by 'logical module' or 'design-level
cyclic dependency'.  But circular package dependencies are never
acceptable to me.  I would either combine A and B into a single
package, or else break the circularity by moving T into B.