The DRY Principle defines the responsibility of the Developers and Code Reviewers to be vigilant in ensuring that Developed Code Bases are free from Code Block Duplications.

The definition of the Don’t Repeat Yourself Principle calls for the creation of the following Software Entities:

1. Private Helper Methods for Reusable Duplications within the current Type
2. Public Class Utility Methods for Reuse in the Current Type and Other Code Types
3. The implementation of the Request / Response Pattern for passing State DTO Request Classes that encapsulate repeated Constructor Parameter Patterns that returns a single Complex Composite DTO as a Package Object for the calling class to consume

Compliance with DRY Creates a Code Base that has

… A lower Total Cost of Ownership (TCO) for the Client

…… Throughout the Software Development Life Cycle (SDLC).

Duplicate code within assemblies creates an unmanageable code base for the Maintenance Developer.

When a Change Order is received to modify the repeated code it is very difficult to ensure that all versions of that code have been updated.

The Missed Code Blocks are Generally Found, if Lucky, in QA Testing

… but More than Likely when Deployed to Production.

All efforts must be taken during development and code review to guarantee that the DRY Principle has been complied with in the code base.

Dry violations are easy to identify. Any code block that appears more than one time should be refactored.

If it is unique to that current Software Entity then it becomes a Private Helper Method.

If it could serve more than one Software Type it is refactored into Public Utility Class as a Public Helper Method.

If Class Methods are passing the same parameters, a State DTO should encapsulate the parameters and pass them as an object.

This creates an encapsulated object that could be extended in the future for additional parameters.

The Request / Response Design Pattern, using Composite DTOs, supports an easy implementation of a Generic Method typed to a common Request Base Class and a common Response Base Class.

This Enables an infinite Usage of the Generic Method

… With Different Derived Classes for a Single Reusable Method

This is the Ultimate DRY Principle Compliance!

Here are the major signs of a Software Entity that has violated DRY:

1. Conditional Statements – Multiple “ifs” that are processing the results in the same fashion
2. Constructor Method Parameters repeated in Overloads or separate Methods – You can eliminate Overload noise using a Composite DTO to pass Constructor parameters. Only use the provided parameters from the calling Method.
3. Formatting Code Blocks– Dates, Phone Numbers, Addresses and Contact information like Emails, Web Pages and Twitter Handles that are using a common display format should be refactored into Public Utility Helper Methods for consistency of reuse
4. Related or Similar Classes – Methods that are identified as using a common pattern throughout the encapsulated Class are candidates for the Request / Response Generic Method Design Pattern

Here is an example of DRY Violations:

This demo program create a list of three Customers and either displays the first Customer or all three based on a variable value: infoCustomer.

The string format display block uses the exact same code copied twice to create the displayed output to the Console.

This violates the DRY Principle as it is repeated code

Here are the violations refactored into DRY compliance:

In the refactored version the common code has been refactored into a private helper method: CreateCustomerDisplay().

This refactored version complies with the DRY Principles as common code is used as a Method Call in each of the two possible Customer displays.

This is a performance increase as well as the Just-In-Time compiler ca use “EnRegistration” to create pointers to the Method Signatures and only use memory for the code when required