If you have been programming for a while, you have likely experienced "déjà vu" when embarking on writing a new program. Many code and design patterns recur over and over within and across applications. When you realize that you have written something similar in the past, it makes sense to try to leverage this previous work to expedite what you are now trying to create.

Assuming you can remember where the code is that you want to leverage, you need to decide on the best way to take advantage of this existing code. In most cases you will be deciding between one of the following approches:

  1. Clone the Program
    With this approach, you make a copy of the program and adapt the copy to serve your current requirements.
  2. Adapt the Program
    This involves changing the original program so that it not only handles the original requirements for which it was written, but also the new requirements you are seeking within the context of your current project.
  3. Restructure the Program
    This option involves carving out common characteristics of the original program (class) to form a new Superclass that is inherited by a subclass in the original application and another subclass within your current project.

Let's review the advantages and disadvantages of each approach followed by an alternative, which is to develop a model to generate the similar components.

Cloning

Developers often tend to choose the path of least resistance when faced with the challenge of building something similar to a component that already exists. This usually means copying the existing component and adapting the copy to satisfy new requirements. This approach has two main advantages:

  1. This is often the most expedient method of leveraging existing code.
  2. This approach does not impact the existing process whose code you are cloning.

On the other hand, there are a number of pitfalls to this approach that should be carefully considered. These include:

  1. It can take considerable time to study the code to determine what sections should remain in tack, what is not needed to satisfy your requirements and what code needs to be adapted.
  2. Developers have a tendency to leave code in place "in case it is needed". Sometimes this is done for expediency. That is, rather than taking the time to learn exactly what a section of code does, in order to decide whether it can be removed, it is safer just to leave it as is, in case it might be called. This can lead to situations where your application contains a lot of "dead" or unnecessary code.
  3. It is easy to overlook statements that need to be changed, resulting in bugs in the copied code.
  4. In general, this approach leads to a larger and larger code base, since we are copying code rather than reusing code.

Adapting

If it is possible to adapt an existing component to not only serve the needs of its original application but also handle new requirements this is generally preferred over cloning since it results in improved code reuse. Let's review the disadvantages of this approach.

  1. Since this technique involves changes to an existing component, you run the risk of "breaking" existing functionality that is not part of your current scope. Developers and project managers are generally adverse to making changes to something that is working, even if it means improving code reuse.
  2. Often applications are developed in silos so, even if you could create a common component that could be used by multiple applications, the structure and location of the code base may not allow for reusing components across applications.
  3. In many cases, the adapted component would require interface changes that would necessitate other updates to existing code that utilizes the component.

Restructuring

Restructuring is similar to adapting except that it involves splitting the original component (class) into a Superclass and a Subclass and then creating a new Subclass to support your new requirements. This approach suffers from all of the same challenges described in the Adapting section.

Alternative Approaches Available in GenHelm

Next, let's look at how GenHelm solves some of the problems described above.

Code Sharing

When you instantiate a class in GenHelm, the framework first looks for the class within the context of the current site. If it is not found, the framework looks for the class within a common system class folder. This allows any number of websites to share common classes to improve code reuse.

In the adapt or restructure techniques we described earlier, we simply need to move the code that we want to reuse from a specific site to the common system folder then we can call it from both the original site and our new site.

Code Generation

Code generation is a more formal and robust approach to program cloning. Rather than copying and changing programs, code generation involves developing a parameterized model that can clone programs in a rigorous way. Typically, the model will accept parameters that control what code needs to be changed and which sections of code to include or exclude.

Formalizing the cloning process serves to eliminate all of the aforementioned pitfalls associated with cloning while preserving the main benefit, which is increased productivity.

Formalizing the Code Generation Process

One of the main advantages of informal code cloning versus developing a code generator is that cloning tends to be more expedient. That's because, most developers don't have a formal process for developing code generators. That's where GenHelm shines since it provides a complete framework for developing models and using these models to build components.

GenHelm ships with over 70 prebuilt models. Equally important is the fact that GenHelm makes it very easy for you to build models that are specific to your particular domain. Over time, as you develop new models, more and more of your applications will become completely generatable.

It is also important to note that code generation is not a one-time event. Instead, code is maintained by changing the parameters to a model and regenerating. As necessary, you can extend the models to handle more and more edge cases to increase the capabilities of programs that can be generated using the model.