The greater propensity for code reusability is often put forward as a key advantage of OOP over Structured programming. Some however think that this aspect of OOP is overhyped, and that in fact a number of software design problems may arise from over-stressing code reusability. And I am sharing the sentiment. Let’s look at this issue a bit…
As we all know, ‘reusability’ is built right into object-oriented programming. All that needs to be done to reuse a default class is to write a new class that inherits things from the base that contains all the general attributes and behaviors. Let’s say we have a code that defines object’s dimension. This code can be reused by all objects where the dimension is a characteristic of an object. So I guess, it’s pretty obvious that the idea behind OOP is to reuse things to be more efficient. “I cannot overemphasize to you how important this idea is because it makes application functionally scalable and supportable.” (Code Reusability, 2014). Reuse of code comes with fewer development risks, mostly due to a fact that a generic code is typically using standards applicable to most of the objects being described by the code. Also an actual adoption of standards is decreased development time as there is no need to invent everything from scratch.
The ‘reusability’ is one of the most spoken words in application development today. It seems that it’s a holy grail of all modern architectural styles and software methodologies, and something everyone thinks is the best practice.
But is it?
There are many issues tied to reusability. For example, many experts believe that reuse always comes with cost savings. But that’s not always the correct assumption. If software developers do not adequately consider the functionality and interfaces in their designs than the final application will never provide the south after cost savings and it wouldn’t efficiently reuse the existing code. E.g. Let’s say you code the application with reuse in mind, but at the end of the process you find that you’re only able to reuse about 10 percent of the baseline. How much time was saved and are there any cost savings in such approach?
Another problem is that it takes the time to understand what the system should do and even more time for all team members to encompass how to properly use existing baseline code to implement a valid re-use, taking into account all the other code, databases, dependencies, configurations, 3rd party integrations, web services, etc.
So, we can see that It comes down to doing an informed research, good design and finding a good balance, so at the end of the day, reusability is not decreasing reliability and cost. “It is difficult to realize the expected savings for re-use when the lineage of the code is untraceable and the artifacts that go with a module or app like requirements, unit test history and defect density either were never tracked at that level or are no longer relevant at least at the test level based on modification. The prospects for better-faster-cheaper products as we evolve to new delivery environments and mechanisms is exciting, but on our journey to develop “open” architectures that will allow us to reuse the investments from many programs we cannot lose sight of the actual product we are reusing as it is this product at the lowest level that will be the source of savings or inherited lifecycle costs. “The pros and cons of code re-use (2012)
To conclude this topic, let’s say that the biggest problems is that more we re-use the code, harder the application gets to search, evaluate and adopt for reuse. Or in other words, more you reuse, more complicated the application becomes and less cost savings it provides. Another issue is that once everything is based on baselines, nothing in the code feels like it was invented for its particular purpose.
So, whenever we hear code reuse, let’s just pause and do at least a bit of pushback, take a step back and investigate the application purpose and logic. Ask the question such as: Is this part of the code a good candidate for reuse?
Don’t forget: “Writing generic code is actually quite difficult. If you’re starting a new project by writing a framework or some generic code, you’re doing it wrong and you need to just stop.” (Reuse abuse, 2015)
Spinellis, D. (2016) Reuse: The pros and cons. Available at: http://www.dmst.aueb.gr/dds/etech/swdev/reusepc.htm (Accessed: 26 September 2016).
The pros and cons of code re-use (2012) Available at: http://static1.1.sqspcdn.com/static/f/702523/20866449/1352101959190/201211-Graton.pdf?token=Dom3dTKxDY8Ekf63geXrRpUYE5U%3D (Accessed: 26 September 2016).
Code Reusability (2014) Available at: https://www.quora.com/What-are-the-advantages-and-disadvantages-of-code-reusability (Accessed: 26 September 2016).
Reuse abuse (2015) The cost of code reuse abuse. Available at: https://www.javacodegeeks.com/2015/03/the-cost-of-code-reuse-abuse.html (Accessed: 26 September 2016).