I'm going to conclude this set of examples with
a system that you might also know, Bash. And in
case you don't, Bash is a Unix shell written as
a free software replacement for the traditional Bourne shell, also
called sh. So what I'm showing here is the
descriptive architecture of the command component of Bash. So, is
the architecture, as implemented, of the command component of Bash.
And the component is the one here sort of highlighted
in gray. And what you can see here, these names are
the sub components of the command component. And if we look at
this architecture, two design problems of the component can kind of jump
at us. The first one is the lack of cohesion within the
component. So, if you look here, you can see that only
a few connections exist between the sub-components. And having a low cohesion
is normally not a good thing for a design. The second thing
that we can note is the high coupling. The component has tons
of connections with other components. They're, these edges that are
leaving the components and going towards other parts of the system.
So basically, this component has low cohesion and high coupling, which
is exactly the opposite of how a good design should be.
Given the structure, it is clear that anytime you change
this component you might need to change a bunch of other
components in the system. And of course, when changing other components
in the system, you might also need to chance the command
component as well. And along similar lines, to understand this
component you probably need to look at many other parts of
the system, which is also less than ideal. And one
important point here is that with all these examples, I'm not
really trying to criticize any specific system, what I'm trying
to show instead, is how complex software architectures can be, and
how much they can degrade over time. And this is true
for most systems, not just the ones that I showed you.