Information Technology Reference
In-Depth Information
reuse components and harder to update parts of a system. Many smaller
assemblies make it easier to use your classes as binary components.
The title also highlights the importance of cohesion. Cohesion is the
degree to which the responsibilities of a single component form a mean-
ingful unit. Cohesive components can be described in a single simple sen-
tence. You can see this in many of the .NET FCL assemblies. Two examples
are: The System.Core assembly provides types and algorithms that sup-
port LINQ, and the System.Windows.Forms assembly provides classes that
model Windows controls. Web Forms and Windows Forms are in different
assemblies because they are not related. You should be able to describe your
own assemblies in the same fashion using one simple sentence. No cheat-
ing: The MyApplication assembly provides everything you need. Yes, that's
a single sentence. But it's also lazy, and you probably don't need all of that
functionality in My2ndApplication. (Though you'd probably like to reuse
some of it. That “some of it” should be packaged in its own assembly.)
Yo u s h o u l d n o t c r e a t e a s s e m b l i e s w i t h o n l y o n e p u b l i c c l a s s . Yo u d o n e e d
to find the middle ground. If you go too far and create too many assem-
blies, you lose some benefits of encapsulation: You lose the benefits of
internal types by not packaging related public classes in the same assem-
bly. The JIT compiler can perform more efficient inlining inside an assem-
bly than across assembly boundaries. This means that packaging related
types in the same assembly is to your advantage. Your goal is to create the
best-sized package for the functionality you are delivering in your com-
ponent. This goal is easier to achieve with cohesive components: Each
component should have one responsibility.
In some sense, an assembly is the binary equivalent of class. We use classes
to encapsulate algorithms and data storage. Only the public classes, structs,
and interfaces are part of the official contract, so only the public types are
visible to users. (Remember that interfaces cannot be declared protected.)
In the same sense, assemblies provide a binary package for a related set of
classes. Only public and protected classes are visible outside an assembly.
Utility classes can be internal to the assembly. Yes, they are more visible
than private nested classes, but you have a mechanism to share a common
implementation inside that assembly without exposing that implementa-
tion to all users of your classes. Partitioning your application into multi-
ple assemblies encapsulates related types in a single package.
Splitting functionality into assemblies implies having more code than you
would have in a short essay like an Effective Item. Rather than write an
