Some classic (GoF) design patterns are no longer needed in C++

[Mr Flibble]

Some classic (GoF) design patterns are no longer needed in C++.

Lambdas wrapped by std::function, for example, can be used instead of
the "command" pattern.

It can be argued that these new techniques are still implementing the
idea of the old patterns just not their substance, so knowledge of the
old patterns is still useful information to have.

In the case of std::function beware of possible performance penalties
that may arise as the cost of gaining type erasure, penalties that may
be more significant than those present in the classic pattern
implementations.


/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[Chris Vine]

On Fri, 12 Jan 2018 19:42:24 +0000
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> Some classic (GoF) design patterns are no longer needed in C++.
>
> Lambdas wrapped by std::function, for example, can be used instead of
> the "command" pattern.

You were arguing against this some years ago when I suggested
something similar (although I was slightly more nuanced - see below).
You were in pretty much full-on OO/inheritance mode then as I recall.

> It can be argued that these new techniques are still implementing the
> idea of the old patterns just not their substance, so knowledge of
> the old patterns is still useful information to have.

That is the correct view in my opinion. std::function avoids the need
to implement virtual dispatch using hand written virtual functions and
inheritance. It implements type erasure for you by itself employing
virtual dispatch with one layer of inheritance: the heart of
std::function is a virtual function call which is invoked by operator().

std::function simplifies not only the command pattern, but also the
observer, strategy and visitor patterns.

> In the case of std::function beware of possible performance penalties
> that may arise as the cost of gaining type erasure, penalties that
> may be more significant than those present in the classic pattern
> implementations.

Penalties? Type erasure using std::function requires an allocation and
a virtual function call. The command pattern implemented using abstract
classes and inheritance for the same case requires an allocation and a
virtual function call.

Chris

[Mr Flibble]

On 12/01/2018 21:54, Chris Vine wrote:
> On Fri, 12 Jan 2018 19:42:24 +0000
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> Some classic (GoF) design patterns are no longer needed in C++.
>>
>> Lambdas wrapped by std::function, for example, can be used instead of
>> the "command" pattern.
>
> You were arguing against this some years ago when I suggested
> something similar (although I was slightly more nuanced - see below).
> You were in pretty much full-on OO/inheritance mode then as I recall.

I do not recall this at all. Maybe you are confusing me with someone else?

>
>> It can be argued that these new techniques are still implementing the
>> idea of the old patterns just not their substance, so knowledge of
>> the old patterns is still useful information to have.
>
> That is the correct view in my opinion. std::function avoids the need
> to implement virtual dispatch using hand written virtual functions and
> inheritance. It implements type erasure for you by itself employing
> virtual dispatch with one layer of inheritance: the heart of
> std::function is a virtual function call which is invoked by operator().

Yes I am well aware of how std::function works internally however others
might not so it's good that you briefly explain it.

>
> std::function simplifies not only the command pattern, but also the
> observer, strategy and visitor patterns.

Agree although sometimes I prefer an abstract interface when employing
observer or similar (especially if there are multiple operations that
can be logically grouped together).

>
>> In the case of std::function beware of possible performance penalties
>> that may arise as the cost of gaining type erasure, penalties that
>> may be more significant than those present in the classic pattern
>> implementations.
>
> Penalties? Type erasure using std::function requires an allocation and
> a virtual function call. The command pattern implemented using abstract
> classes and inheritance for the same case requires an allocation and a
> virtual function call.

Yes, penalties. I don't know for certain if this is still a problem
with modern implementations but in the past I have seen that not all
cases optimize to a single virtual function call; however, the biggest
penalty is the allocation although often an SSO-esque technique will be
employed to mitigate that for most cases. With the classic "command"
pattern implementation it is possible to have direct control over
allocation but since C++17 it has not been possible to customize
std::function allocation (which was a mistake IMO).

[Chris Vine]

On Fri, 12 Jan 2018 22:45:36 +0000

Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> On 12/01/2018 21:54, Chris Vine wrote:
> > On Fri, 12 Jan 2018 19:42:24 +0000
> > Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> >> Some classic (GoF) design patterns are no longer needed in C++.
> >>
> >> Lambdas wrapped by std::function, for example, can be used instead
> >> of the "command" pattern.
> >
> > You were arguing against this some years ago when I suggested
> > something similar (although I was slightly more nuanced - see
> > below). You were in pretty much full-on OO/inheritance mode then as
> > I recall.
>
> I do not recall this at all. Maybe you are confusing me with someone
> else?

I don't think so. You were not impressed by the idea of replacing the
polymorphic behaviour of virtual functions with inheritance by
std::function in order to implement GoF abstractions, and described your
OO credentials by reference to your role in bringing to market one of
the first mobile phones, for Siemens if I recall it correctly. I think
I described you as a 1990s OO dinosaur, or something like that.

If you weren't involved in Siemens mobile phones then I have got the
wrong person.

You may be right but I remain to be convinced The essence of virtual
dispatch in OO-style is that you do it through a pointer to a base
class (usually abstract), which of necessity requires allocation on free
store of the concrete object implementing the abstract interface.

If your point is that you can use a fancy allocator for this (say, a
specially designed small object allocator) when using the abstract
class/inheritance approach but not when using std::function, then you
may have a point. Dunno.

Chris

[Mr Flibble]

On 12/01/2018 23:12, Chris Vine wrote:
> On Fri, 12 Jan 2018 22:45:36 +0000
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> On 12/01/2018 21:54, Chris Vine wrote:
>>> On Fri, 12 Jan 2018 19:42:24 +0000
>>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>>>> Some classic (GoF) design patterns are no longer needed in C++.
>>>>
>>>> Lambdas wrapped by std::function, for example, can be used instead
>>>> of the "command" pattern.
>>>
>>> You were arguing against this some years ago when I suggested
>>> something similar (although I was slightly more nuanced - see
>>> below). You were in pretty much full-on OO/inheritance mode then as
>>> I recall.
>>
>> I do not recall this at all. Maybe you are confusing me with someone
>> else?
>
> I don't think so. You were not impressed by the idea of replacing the
> polymorphic behaviour of virtual functions with inheritance by
> std::function in order to implement GoF abstractions, and described your
> OO credentials by reference to your role in bringing to market one of
> the first mobile phones, for Siemens if I recall it correctly. I think
> I described you as a 1990s OO dinosaur, or something like that.

I was on the team that made the first smartphone but it wasn't Siemens
and I would never "describe my OO credentials" in relation to that role
as OO is but one tool in the toolbox so I still think you are confusing
me with somebody else.

It is certainly the case that I wouldn't have used std::function when
working on that project as Boost wasn't available to us at the time for
various reasons so we couldn't have used Boost.bind however that was a
long time ago and I have been using "modern" C++ techniques for a
considerable time since and I have been using std::function since TR1
support was added to the stdlib implementations I use.

>
> If you weren't involved in Siemens mobile phones then I have got the
> wrong person.

Maybe you are confusing two different people as one person.

"OO-style" (that terminology is awful btw) inheritance does NOT require
allocation on the free store; all it requires is storage into which an
allocation can be made and that can be on the free store, the stack or
from a static storage duration memory pool.

>
> If your point is that you can use a fancy allocator for this (say, a
> specially designed small object allocator) when using the abstract
> class/inheritance approach but not when using std::function, then you
> may have a point. Dunno.

What you call a "fancy allocator" I just call a (custom) allocator;
nothing "fancy" about it.

[Chris Vine]

On Fri, 12 Jan 2018 23:47:23 +0000
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> On 12/01/2018 23:12, Chris Vine wrote:
> > You may be right but I remain to be convinced The essence of
> > virtual dispatch in OO-style is that you do it through a pointer to
> > a base class (usually abstract), which of necessity requires
> > allocation on free store of the concrete object implementing the
> > abstract interface.
>
> "OO-style" (that terminology is awful btw) inheritance does NOT
> require allocation on the free store; all it requires is storage into
> which an allocation can be made and that can be on the free store,
> the stack or from a static storage duration memory pool.

You are quibbling. I hope it is obvious that by free store I meant
some allocation by a heap-like allocator - that is, not on the stack.

> > If your point is that you can use a fancy allocator for this (say, a
> > specially designed small object allocator) when using the abstract
> > class/inheritance approach but not when using std::function, then
> > you may have a point. Dunno.
>
> What you call a "fancy allocator" I just call a (custom) allocator;
> nothing "fancy" about it.

Quibbling. Your main point seems to have come down to "you cannot have
custom allocators for std::function". That surprises me but you may be
right about that. You could partially get around that by passing
to std::function custom function objects instead of lambda expressions,
and giving those a custom allocator. But I suspect std::function has
its own strategies.

[Mr Flibble]

On 12/01/2018 23:54, Chris Vine wrote:
> On Fri, 12 Jan 2018 23:47:23 +0000
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> On 12/01/2018 23:12, Chris Vine wrote:
>>> You may be right but I remain to be convinced The essence of
>>> virtual dispatch in OO-style is that you do it through a pointer to
>>> a base class (usually abstract), which of necessity requires
>>> allocation on free store of the concrete object implementing the
>>> abstract interface.
>>
>> "OO-style" (that terminology is awful btw) inheritance does NOT
>> require allocation on the free store; all it requires is storage into
>> which an allocation can be made and that can be on the free store,
>> the stack or from a static storage duration memory pool.
>
> You are quibbling. I hope it is obvious that by free store I meant
> some allocation by a heap-like allocator - that is, not on the stack.

No I am not quibbling. You are wrong: it is quite possible to allocate
these objects on the stack in fact it is as easy as:

typedef std::shared_ptr<ICommand> command_ptr; // abstract command base
typedef std::vector<command_ptr> macro; // chained commands

int main()
{
RedoCommand cmd1;
UndoCommand cmd2;

macro m;
m.push_back(command_ptr{command_ptr{}, &cmd1});
m.push_back(command_ptr{command_ptr{}, &cmd2});
use(m);

// obviously lifetime of cmd1 and cmd1 must exceed lifetime of m
// or anything that uses m as is the case here.
}

slightly more advanced:

int main()
{
alignas(128) char storage[ARENA_SIZE];

stack_allocator sa{storage, sizeof(storage)};

macro m;
m.push_back(std::allocate_shared<RedoCommand>(sa));
m.push_back(std::allocate_shared<UndoCommand>(sa));
use(m);

}

>
>>> If your point is that you can use a fancy allocator for this (say, a
>>> specially designed small object allocator) when using the abstract
>>> class/inheritance approach but not when using std::function, then
>>> you may have a point. Dunno.
>>
>> What you call a "fancy allocator" I just call a (custom) allocator;
>> nothing "fancy" about it.
>
> Quibbling. Your main point seems to have come down to "you cannot have
> custom allocators for std::function". That surprises me but you may be
> right about that. You could partially get around that by passing
> to std::function custom function objects instead of lambda expressions,
> and giving those a custom allocator. But I suspect std::function has
> its own strategies.

I suggest you look up the word "quibbling" in a dictionary because that
is the second time you have used it inappropriately.

[Christian Gollwitzer]

Am 12.01.18 um 20:42 schrieb Mr Flibble:

> Some classic (GoF) design patterns are no longer needed in C++.
>
> Lambdas wrapped by std::function, for example, can be used instead of
> the "command" pattern.
>

I fully agree. In fact, if you are used to a dynamic language (Python is
popular these days), then most of these "design patterns" seem very
baroque. std::function, lambdas, auto etc. bring modern C++ much closer
to those dynamic languages and thus make these design patterns obsolete.

There is a saying that "design patterns are actually defects of a
language"
https://stackoverflow.com/questions/1579162/are-design-patterns-really-language-weaknesses

I think that these OO design patterns are actually a proof-of-concept,
it shows that you can reduce all of these usage patterns to class
hierarchies with virtual function calls, but it doesn't mean that you
should actually do that, unless it is the only available option - like
you can prove that pure lambda calculus or SK combinators have the same
computational power as C++, but you wouldn't actually want to write code
like that.

Christian

[Alf P. Steinbach]

On 1/13/2018 8:46 AM, Christian Gollwitzer wrote:
> Am 12.01.18 um 20:42 schrieb Mr Flibble:
>> Some classic (GoF) design patterns are no longer needed in C++.
>>
>> Lambdas wrapped by std::function, for example, can be used instead of
>> the "command" pattern.
>>
>
> I fully agree. In fact, if you are used to a dynamic language (Python is
> popular these days), then most of these "design patterns" seem very
> baroque. std::function, lambdas, auto etc. bring modern C++ much closer
> to those dynamic languages and thus make these design patterns obsolete.

A main feature of the (original) command pattern is support for undo
functionality.

I fail to see how `std::function` does that.

> There is a saying that "design patterns are actually defects of a
> language"
> https://stackoverflow.com/questions/1579162/are-design-patterns-really-language-weaknesses

That question is based on two fanciful rewrites of history, treating
subroutines and OO as earlier times' design patterns. That's bollocks.
Stack Overflow is more like an anti-authority than an authority: my
impression is that at least in the [c++] tag about half of the answers,
and of alleged facts proffered in questions, are subtly or grotesquely
wrong.

> I think that these OO design patterns are actually a proof-of-concept,
> it shows that you can reduce all of these usage patterns to class
> hierarchies with virtual function calls, but it doesn't mean that you
> should actually do that, unless it is the only available option - like
> you can prove that pure lambda calculus or SK combinators have the same
> computational power as C++, but you wouldn't actually want to write code
> like that.

There will always be implementations of design patterns, in languages
and libraries and ordinary code. That's what design patterns for: for
language designers and individual programmers to implement them, adapted
to concrete situations. Andrei's Modern C++ Design book was touted as a
book about how to implement some common design patterns generically,
except that both Andrei and his reviewers were very careful about
stating that it was not, because patterns are language independent and
without the arbitrary constraints of any particular implementation.


Cheers!,

- Alf

[Christian Gollwitzer]

Am 13.01.18 um 09:29 schrieb Alf P. Steinbach:

> On 1/13/2018 8:46 AM, Christian Gollwitzer wrote:
>> Am 12.01.18 um 20:42 schrieb Mr Flibble:
>>> Some classic (GoF) design patterns are no longer needed in C++.
>>>
>>> Lambdas wrapped by std::function, for example, can be used instead of
>>> the "command" pattern.
>>>
>>
>> I fully agree. In fact, if you are used to a dynamic language (Python
>> is popular these days), then most of these "design patterns" seem very
>> baroque. std::function, lambdas, auto etc. bring modern C++ much
>> closer to those dynamic languages and thus make these design patterns
>> obsolete.
>
> A main feature of the (original) command pattern is support for undo
> functionality.
>
> I fail to see how `std::function` does that.
>

I don't know if it is possible using std::function, but in a dynamic
language it is certainly possible. The whole point of the abstract base
class "Command" seems to be that you can manipulate function objects as
objects, store them in a list and invoke a (virtual) method on them. All
of this is trivially possible in Python. You can very easily store
instances or classes in a list without the need to derive them from a
common abstract base class.

Of course, the price to pay is that at runtime there will be a string
search for the name of the method at invocation time, and the compiler
does not statically check if the object does have the necessary methods
at the point of insertion.

Christian

[Chris Vine]

On Sat, 13 Jan 2018 00:27:39 +0000

Your examples are completely contrived. Yes, you can allocate
heap-like storage on the stack of the main function, but you are
quibbling. So far, your "penalties that may be more significant than
those present in the classic pattern implementations" seem to consist
of the fact that std::function cannot take a custom allocator.

Anyway, you announce with your original post that 'some classic (GoF)
design patterns are no longer needed in C++' because 'lambdas wrapped by

std::function, for example, can be used instead of the "command"

pattern'.

That's a point of view, although not a revelation of Damascene
proportions, nor quite as exciting as your announcements about fixed
size integer types. On std::function, you have come to the party 7
years late, but you got there in the end.

Chris

[Jorgen Grahn]

On Sat, 2018-01-13, Christian Gollwitzer wrote:
> Am 12.01.18 um 20:42 schrieb Mr Flibble:
>> Some classic (GoF) design patterns are no longer needed in C++.
>>
>> Lambdas wrapped by std::function, for example, can be used instead of
>> the "command" pattern.
>>
>
> I fully agree. In fact, if you are used to a dynamic language (Python is
> popular these days), then most of these "design patterns" seem very
> baroque. std::function, lambdas, auto etc. bring modern C++ much closer
> to those dynamic languages and thus make these design patterns obsolete.

Aren't design patterns generally seen as a historical mistake these
days? I almost never encounter them -- except the Singleton, and then
it's always someone trying to get rid of a Singleton.

(On the other hand, I also rarely see people do things I think are
important, like invent classes of the right size and with well-defined
responsibilities.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Chris Vine]

On Sat, 13 Jan 2018 09:50:36 +0100
Christian Gollwitzer <auri...@gmx.de> wrote:
> Am 13.01.18 um 09:29 schrieb Alf P. Steinbach:
> > On 1/13/2018 8:46 AM, Christian Gollwitzer wrote:
> >> Am 12.01.18 um 20:42 schrieb Mr Flibble:
> >>> Some classic (GoF) design patterns are no longer needed in C++.
> >>>
> >>> Lambdas wrapped by std::function, for example, can be used
> >>> instead of the "command" pattern.
> >>>
> >>
> >> I fully agree. In fact, if you are used to a dynamic language
> >> (Python is popular these days), then most of these "design
> >> patterns" seem very baroque. std::function, lambdas, auto etc.
> >> bring modern C++ much closer to those dynamic languages and thus
> >> make these design patterns obsolete.
> >
> > A main feature of the (original) command pattern is support for
> > undo functionality.
> >
> > I fail to see how `std::function` does that.
> >
>
> I don't know if it is possible using std::function, but in a dynamic
> language it is certainly possible. The whole point of the abstract
> base class "Command" seems to be that you can manipulate function
> objects as objects, store them in a list and invoke a (virtual)
> method on them. All of this is trivially possible in Python. You can
> very easily store instances or classes in a list without the need to
> derive them from a common abstract base class.

For undo, you can have a second function object in a pair or you can
have the function object take a do/undo tag argument so it knows in
which "direction" to go. This is possibly not as convenient as a
command object having both do and undo virtual functions.

In C++17 you can have lists or other containers of unrelated types via
std::any. But it is better to use C++'s static type system to your
advantage and constrain them using the std::variant sum type.

[bitrex]

Problem is that the performance of std::any in most non-trivial use
cases sucks the lemon.

[bitrex]

Lots of disciplines have "patterns" and IMO the reason they exist is
mainly to give some "axiomatic" structure to design problems where the
degrees of freedom greatly exceeds the number of constraints, that is to
say the problem is under-determined. The fact that the problem is
under-determined doesn't change the fact that some solution or other
needs to be produced.

There might be some optimal-for-an-application solution that involves a
structure completely unrelated to any known "pattern", maybe blows all
of them away by a mile, in fact. How will you ever find it?

[Mr Flibble]

My examples are not contrived at all in fact this is key to the elegance
of the API of neoGFX (my C++ GUI library): when adding a child widget to
a layout or parent widget that child widget can be allocated either on
the free store or on the stack and the std::shared_ptr aliasing
constructor is utilized in achieving this.

> quibbling. So far, your "penalties that may be more significant than
> those present in the classic pattern implementations" seem to consist
> of the fact that std::function cannot take a custom allocator.
>
> Anyway, you announce with your original post that 'some classic (GoF)
> design patterns are no longer needed in C++' because 'lambdas wrapped by
> std::function, for example, can be used instead of the "command"
> pattern'.
>
> That's a point of view, although not a revelation of Damascene
> proportions, nor quite as exciting as your announcements about fixed
> size integer types. On std::function, you have come to the party 7
> years late, but you got there in the end.

I have been using std::function for at least 10 years so how does that
tally with me "coming to the party 7 years late"?

[Melzzzzz]

On 2018-01-13, Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> On 1/13/2018 8:46 AM, Christian Gollwitzer wrote:
>> Am 12.01.18 um 20:42 schrieb Mr Flibble:
>>> Some classic (GoF) design patterns are no longer needed in C++.
>>>
>>> Lambdas wrapped by std::function, for example, can be used instead of
>>> the "command" pattern.
>>>
>>
>> I fully agree. In fact, if you are used to a dynamic language (Python is
>> popular these days), then most of these "design patterns" seem very
>> baroque. std::function, lambdas, auto etc. bring modern C++ much closer
>> to those dynamic languages and thus make these design patterns obsolete.
>
> A main feature of the (original) command pattern is support for undo
> functionality.
>
> I fail to see how `std::function` does that.

Well, std::function holds function object, no? It can call do/undo
whatever, you can place std::functions in a list...

--
press any key to continue or any other to quit...

[cda...@gmail.com]

Someone about a decade ago showed that every design pattern was just special case of the map? function based off the Lambda Calculus.

[Paavo Helde]

On 13.01.2018 17:47, bitrex wrote:

> There might be some optimal-for-an-application solution that involves a
> structure completely unrelated to any known "pattern", maybe blows all
> of them away by a mile, in fact. How will you ever find it?

Deep neural network? Apparently it invented some Go strategies which no
human had thought of so far.

A DNN solution is however not fully satisfactory as there is not much
insight involved in those fine-tuned values of 100,000 parameters. For
human understanding it should be back-translated into some kind of
meaningful structures, possibly inventing new concepts and patterns
along the way. Not sure how well this can be done in general.

[Alf P. Steinbach]

The “deep” in DNN means there are most probably semantic structures in
the net, i.e., it's too some degree a semantic net. The success also
points that way. However, from what I knew about neural nets 15 years
ago it's hard to identify semantic structures: one can infer their
existence, but getting the net to explain its reasoning is überhard.

Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<p3cg0i$dp0$1...@dont-email.me> thusly:

>There will always be implementations of design patterns, in languages

>and libraries and ordinary code. [...]

e.g. sometimes Strategy pattern is just an if statement.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnp5jnlr.e...@frailea.sa.invalid> thusly:

>Aren't design patterns generally seen as a historical mistake these
>days?

Just Singleton :)

[Mr Flibble]

On 15/01/2018 20:24, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
> <p3cg0i$dp0$1...@dont-email.me> thusly:
>
>> There will always be implementations of design patterns, in languages
>> and libraries and ordinary code. [...]
>
> e.g. sometimes Strategy pattern is just an if statement.

Nonsense.

[Öö Tiib]

On Monday, 15 January 2018 22:25:44 UTC+2, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnp5jnlr.e...@frailea.sa.invalid> thusly:
>
> >Aren't design patterns generally seen as a historical mistake these
> >days?
>
> Just Singleton :)

Every misuse is mistake. On one hand Singleton is simpler to misuse
than for example Visitor or Memento. On the other hand misused Visitor
or Memento are far more painful to live with than misused Singleton.

[Mr Flibble]

Actually a misused singleton can be extremely painful to rectify as it
can result on everything erroneously depending on everything else (tight
coupling).