Skip to content

Implementing Code Reusability in C#

Code reusability is one of the most important topics in software architecture. This chapter aims to discuss ways to enable code reuse, as well as to help you understand how .NET 5 goes in this direction to solve the problem of managing and maintaining a reusable library.

The following topics will be covered in this chapter:

  • Understanding the principles of code reuse
  • The advantages of working with .NET 5 versus .NET Standard
  • Creating reusable libraries using .NET Standard

Although code reuse is an exceptional practice, as a software architect you must be aware when this is important for the scenario you are dealing with. Many good software architects agree that there is a lot of overengineering due to trying to make things reusable even though they are often single-use or not understood well enough.

 

Technical requirements

Understanding the principles of code reusability

There is a single reason that you can always use to justify code reuse – you cannot spend your valuable time recreating the wheel if it is already running well in other scenarios. That is why most engineering domains are based on reusability principles. Think about the light switches you have in your house.

Can you imagine the number of applications that can be made with the same interface components? The fundamentals of code reuse are the same. Again, it is a matter of planning a good solution so part of it can be reused later.

In software engineering, code reuse is one of the techniques that can bring a software project a bunch of advantages, such as the following:

  • There is confidence in the software, considering that the reused piece of code was already tested in another application.
  • There is better usage of software architects and the senior team since they can be dedicated to solving this kind of problem.
  • There is the possibility of bringing to the project a pattern that is already accepted by the market.
  • Development speed goes up due to the already implemented components.
  • Maintenance is easier.

These aspects indicate that code reuse should be done whenever it is possible. It is your responsibility, as a software architect, to ensure the preceding advantages are utilized and, more than that, that you incentivize your team to enable reuse in the software they are creating.

What is not code reuse?

The first thing you must understand is that code reuse does not mean copying and pasting code from one class to another. Even if this code was written by another team or project, this does not indicate that you are properly working with reusability principles. Let us imagine a scenario that we will find in this book’s use case, the WWTravelClub evaluation.

In this project scenario, you may want to evaluate different kinds of subjects, such as the Package, DestinationExpert, City, Comments, and so on. The process for getting the evaluation average is the same, no matter which subject you are referring to. Due to this, you may want to enable reuse by copying and pasting the code for each evaluation. The (bad) result will be something like this:

 

Bad implementation – there is no code reuse here

In the preceding diagram, the process of calculating the evaluation average is decentralized, which means that the same code will be duplicated in different classes. This will cause a lot of trouble, especially if the same approach is used in other applications. For instance, if there is a new specification about how you have to calculate the average or if you just get a bug in the calculation formula, you will have to fix it in all instances of code. If you do not remember to update it in all places, you will possibly end up with an inconsistent implementation.

 

What is code reuse?

The solution to the problem mentioned in the previous section is quite simple: you must analyze your code and select the parts of it that would be good to decouple from your application.

The greatest reason why you should decouple them is related to how you are sure that this code can be reused in other parts of the application, or even in another application:

An implementation focused on code reuse

The centralization of the code brings to you, as a software architect, a different responsibility for it. You will have to keep in mind that a bug or incompatibility in this code could cause damage to many parts of the application or different applications. On the other hand, once you have this code tested and running, you will be able to propagate its usage with no worries. Besides, if you need to evolve the average calculation process, you will have to change the code in a single class.

It is worth mentioning that the more you use the same code, the cheaper this development will become. Cost needs to be mentioned because, in general, the conception of reusable software costs more in the beginning.

Reusability in the development life cycle

If you understood that reusability will take you to another level of code implementation, you should have been thinking about how to make this technique available in your development life cycle.

As a matter of fact, creating and maintaining a component library is not very easy, due to the responsibility you will have and the lack of good tools to support the search for existing components.

On the other hand, there are some things that you may consider implementing in your software development process every time you initiate a new development:

  • Use already implemented components from your user library, selecting features in the software requirements specification that need them.
  • Identify features in the software requirements specification that are candidates to be designed as library components.
  • Modify the specification, considering that these features will be developed using reusable components.
  • Design the reusable components and be sure that they have the appropriate interfaces to be used in many projects.
  • Build the project architecture with the new component library version.
  • Document the component library version so that every developer and team knows about it.

The use-identify-modify-design-build process is a technique that you may consider implementing every time you need to enable software reuse. As soon as you have the components you need to write for this library, you will need to decide on the technology that will provide these components.

 

Leave a Reply

Your email address will not be published. Required fields are marked *