Sequential coupling

Hello.

I'm trying to find information regarding "Sequential coupling" anti
Pattern
(more than what wikipedia gives me),
"How to avoid", "solutions" and such.

Any links\ Ideas?


Thanks

ManicQin <ManicQin@gmail.com> writes:
> I'm trying to find information regarding "Sequential coupling" anti
> Pattern (more than what wikipedia gives me), "How to avoid",
> "solutions" and such.
>
> Any links\ Ideas?

Um, don't do that?

Anti-patterns, like patterns, are concepts rather than
implementations. You don't link in libraries for Factory, Strategy,
Bridge, etc. any more than you link in one for Sequential Coupling or
God Class. The solution will be specific to your problem.

That being said, there are some patterns and idioms that may be
useful across a range of such problem domains. Off the top of my
head, the State pattern and finite state machines in general seem
likely candidates.

Where are you seeing this anti-pattern?

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

On Sep 23, 2:43 pm, Patrick May <p...@spe.com> wrote:

> Um, don't do that?
>
> Anti-patterns, like patterns, are concepts rather than
> implementations. You don't link in libraries for Factory, Strategy,
> Bridge, etc. any more than you link in one for Sequential Coupling or
> God Class. The solution will be specific to your problem.
>
> That being said, there are some patterns and idioms that may be
> useful across a range of such problem domains. Off the top of my
> head, the State pattern and finite state machines in general seem
> likely candidates.
>
> Where are you seeing this anti-pattern?
>
> Regards,
>
> Patrick

"Dont do that"? otiosity is the best policy
It was more of an astral thinking than a specific problem...
I was just curious if there's an article on the subject.

On Sep 23, 3:17*pm, ManicQin <Manic...@gmail.com> wrote:

> "Dont do that"? otiosity is the best policy
> It was more of an astral thinking than a specific problem...
> I was just curious if there's an article on the subject.

I googled it before I post the thread

Responding to ManicQin...

> I'm trying to find information regarding "Sequential coupling" anti
> Pattern
> (more than what wikipedia gives me),
> "How to avoid", "solutions" and such.

There's not much more to it. There are two basic ideas. The first is
about correct problem space abstraction. If two of an object's behavior
responsibilities are always invoked consecutively (e.g., one invokes the
other or the client always invokes them together), then the object has
been abstracted at the wrong level of abstraction. That is, from the
perspective of the client, there is only one responsibility. (For
example, when the client enforces the sequencing rule by invoking them
consecutively, one is hard-wiring the sequencing rule in the client
implementation when it can be better handled in the receiver because the
client usually shouldn't know about such receiver issues since it has
its own problems to resolve.)

[A basic OOA/D principle is flexible logical indivisibility. There are
really only three levels of OO detail: subsystem, object, and
responsibility. This greatly "flattens" the traditional functional
decomposition tree because there are only three levels. However, that
only works if: (a) subsystem and object subject matters are narrowly
defined; (b) subsystems, objects, and behaviors are cohesive; and (c)
responsibilities are defined as logically indivisible nodes when
connecting the dots of overall flow of control. IOW, the level of
abstraction of a behavior depends on the needs of collaboration in
resolving overall solution sequencing.]

The second is to avoid encoding sequencing decisions in executable code.
That increases code size and creates opportunities for inserting
defects. So to avoid that, one tries to encode invariant sequencing
constraints in static structure. As May points out, that is the main
reason for using object state machines; the transitions encode the
sequencing constraints as transitions. Then all you need to provide is
proper handshaking (message ordering) when objects collaborate so that
the receiver will always be in the right state.

Note that sequencing rules and policies among behaviors always exist
because they are essential to the overall solution, which is essentially
just Turing sequencing of operations. The fact that the operations are
in the same object is serendipity. The rules and policies that are
defined in the problem space are the ones that need to be captured in
state machine transitions because they represent problem space structure
that you want to capture statically. So the second point addresses these.

The rules and policies that are driven by the solution design usually
can't be captured statically because they are an artifact of the flow of
control, which the developer needs to provide. That's where issues like
cohesion, self-containment, and logical indivisibility come into play.
The first point addresses these.

[BTW, object state machines are difficult to get working initially in
collaborations but they have several advantages. Once they are working,
they tend to be very robust. They are also very unforgiving because an
exception is always generated when one has not got the handshaking
right, so debugging is facilitated. Also, all such sequencing errors are
handled exactly the same way and in the same place (i.e., the event
queue manager), which reduces error-checking code. The infrastructure
(e.g., the event queue manager) is reusable. Most important of all,
state machines enforce basic OO ideas like encapsulation, separation of
message and method, logical indivisibility, and self-contained methods.
If one were tasked to create a syntactic artifact in the OOPL code that
actually enforced OOA/D discipline, it would look very much like a state
machine.]



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

"ManicQin" <ManicQin@gmail.com> wrote in message
news:6612d19e-4bed-462b-a43d-de17f8f042aa@a70g2000hsh.googlegroups.com...

> I'm trying to find information regarding "Sequential coupling" anti
> Pattern
> (more than what wikipedia gives me)

The source is (yet) another classic example of trying to re-invent an
already
long-known concept in programming. The concept : sequential *cohesion* .


> "How to avoid", "solutions" and such.

The basic solution is well-known : hide the sequence.
If a component C has properties p1, p2, ... pN that must be accessed in
sequential order, then define a sequence-hiding property :

C:verall(...)
{
p1(...) ;
p2(...) ;
// ...
pN(...) ;
}

The general solution requires a bit more effort.
The classic form of sequential cohesion has the outputs of pX becoming
the inputs of pX+1. Sometimes the overall sequence requires the user
to act on some of those outputs at some point, before allowing the
sequence to continue (this is a form of Control coupling) .

For example :

p1(...) ;
// ...
R = pX(...) ;
// Do something to and/or based on R
pX+1(R, ...) ;
// ...
pN(...) ;

When this is the case, the following approaches are possible :

1. Apply the sequence-hiding process to construct the minimum number
of sequential properties :

The-First-Part-Of-The-Sequence(...) : Result1
{
p1(...) ;
// ...
pX(...) ;
return R ;
}

The-Final-Part-Of-The-Sequence(Result1, ...)
{
pX+1(Result1, ...) ;
// ...
pN(...) ;
}


2. If you can, apply the classic Control coupling solution and put the
'R logic' inside the sequence-hiding property. Any necessary
context can either be passed as parameters +/- assigned as object
state.

#1 is still sequential cohesion, but nowhere near as bad as the original
form. #2 depends on factors such as how much of the context for each
property (the parameters for pX etc) is controlled by the component
user.


Regards,
Steven Perryman

Thanks Lahman & Perryman!

Patrick May wrote:
> ManicQin <ManicQin@gmail.com> writes:
>> I'm trying to find information regarding "Sequential coupling" anti
>> Pattern (more than what wikipedia gives me), "How to avoid",
>> "solutions" and such.
>>
>> Any links\ Ideas?
>
> Um, don't do that?
>
> Anti-patterns, like patterns, are concepts rather than
> implementations. You don't link in libraries for Factory, Strategy,
> Bridge, etc. any more than you link in one for Sequential Coupling or
> God Class. The solution will be specific to your problem.
I think you misinterpreted ManicQin's use of "links". Or I
misinterpreted you :-)

I think the request was for a reference to a website, not a link to a
library :-)

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts <newsgroup.spamfilter@virtualinfinity.net> writes:
> Patrick May wrote:
>> ManicQin <ManicQin@gmail.com> writes:
>>> I'm trying to find information regarding "Sequential coupling" anti
>>> Pattern (more than what wikipedia gives me), "How to avoid",
>>> "solutions" and such.
>>>
>>> Any links\ Ideas?
>>
>> Um, don't do that?
>>
>> Anti-patterns, like patterns, are concepts rather than
>> implementations. You don't link in libraries for Factory, Strategy,
>> Bridge, etc. any more than you link in one for Sequential Coupling or
>> God Class. The solution will be specific to your problem.
> I think you misinterpreted ManicQin's use of "links". Or I
> misinterpreted you :-)
>
> I think the request was for a reference to a website, not a link to a
> library :-)

I understood that. My point is that the way to avoid the
antipattern will depend on how it manifests itself.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)