Code reusability requires a combination of two factors: how efficient the definition of the class structure and inheritance within the application, and how the interfaces implemented within the application with proper definition. The benefit of establishing the interface definitions is the fact that when a class implements such interface must adhere the functional requirements of such interface. To achieve such capability, the definition of the interface must maximize the ability to be reused. However, the balance of the functions implementation within the interface must be optimized since too many functions defined within the interface; can create a problem with reusability, whereas a single function implemented within the interface can lead to creating many classes within the application (Class proliferation problem). The other fact of the code reusability within any application is the ability of reusing the implementation of logic within the system through the inheritance capabilities. The combination of inheritance capability within the class structure and the grouping of the interfaces within the application; can reduce the amount of duplicate code and avoid code redundant (Tabib, 2009).
The main goal of the Service Oriented Architecture (SOA) is to achieve reusability across the organization and business partners and also achieve the integration required among applications. This goal can be achieved through the implementation of standard application interfaces which represent a contract with service consumers where the access to such interfaces will be across and beyond the organization, and as such; if the service will not stick to a contract, the services will not be used by the service consumer (Tripathi, 2008).
Michael (2010) explained that the code reusability starts from the design phase where the code will be designed to inherently reusable. However, to achieve such goal, the proper framework should be in place for effective reuse where components are properly standardized, available for release and documented for reuse. If the intention is to build a framework or utility that is designed for reuse it is important to create good releases, versioning and documentations process to increase the chance of having this components to be reusable in the future. It’s also important to define the components within the application that can be reusable for other applications and also available for integration with other systems; and the following are some examples of these components:
· Generic Utility Classes – This type of classes usually don’t contain business context, and usually used to assist in tasks required by the system.
· Implementation Abstraction Framework – Frameworks that isolate changes to the third party products.
· Simplification and Uniformity Framework – This framework is used for specific tasks that might be required by many applications such as containing an abstraction of encryption methods for specific provider.
Michael (2010) also explained that some of the less reusable components are:
· Application and Business Layers – It is exist within the application with unstable dependency since it is always open for changes and adding new features.
· Entities and Data Access Layers – Unless the abstract in these components is very stable, it is so hard to reuse it again since such component usually tuned to the scope of the application.
Maila (2007) explained that the code reuse is the concept of having a complete or a partial of computer program that is written at one time to be used in another program at a later time. Through the object-oriented programming and design, the reusability is a built-in feature where the code reusability is a design issue in the object-oriented programming. In such approach, the developers are forced to encapsulate the methods and the data within the classes; and as a result interfaces become cleaner way of communicating with such data and such approach in the design capability lead to increasing the code reusability. As a result of building the interfaces to allow users to communicate with the hidden data within the application it forced the developers to create the classes that can expose its data through such approach (Interfaces) where it maximize the reusability of the final classes structure. Another reason for code reusability in the object-oriented world is the technique used through the inheritance that can help implementing the code reusability within the object-oriented design.
Maila (2007) also explained that despite the fact that the object-oriented development provides the features of the reusing code, such features don’t automatically create the reusable code, to achieve such goal, a lot of considerations and experience required from the developer to reach such goal, one of these efforts is for the developer to build the interfaces required to be defined for the classes to communicate with other applications components and other classes. An interface consists of a set of methods that can be used to manipulate the object private data, interacting with other objects, getting information about the object state, and etc. In designing such interfaces the developers have to make such interfaces as general purpose as possible to all the class to be reusable outside of the scope of the application.
Gilbert (2007) explained that the acceptable definition of code reusability is the capability of functionality or code to be used in one or more future projects, and there are some potential sources of code reusability such as Components (objects) that expose their functionality through interfaces that can communicate with other applications and User controls which are designed to render any type of data. To extend the code reusability, a repeatable code (Source Code librarian software) can be used with portable documentation and ease of sharing. The advantages of the repeatable code are:
· Repeatable code can be stored in libraries that are easy to search and navigate through the code snippets.
· The source library of such repeatable code allows the users of such library to write documentation about what needed to be known about the code snippet; also such documentation is portable and can be available always for the user of the library.
· The entire libraries can be easily sent to other and shared by different users.
There are many things that don’t change very often or frequently such as the aspects of the business itself, while there are many things that can change in business frequently such as tax rates, prices, new products, advertising, new customers’ areas, or new business’s areas, and as such; business need to be able to change quickly and effectively without business interruption. For these reasons, the software that has infrequently changes has to be decoupled from the software that changes frequently, and this principle is called “The Common Closure Principle”, and when it is applied to the information management enterprise is called Service Oriented Architecture (SOA). The SOA is the practice of taking the core business functions that don’t change frequently into independent services that can be called by one or more presentation programmers that can be used by users and business partners. Such presentation software interprets the consumer of such services and invokes the services that do activities such as registering customer orders, or acquiring the data for current catalogue (Bob, 2007).
The concept of separating of the business functions that are encapsulated by the services from the presentation interface is very important to provide the protection required for the information processing assets of the business. In implementing such services to be accessed it’s important that such services to be called by any order and it’s important to separate the services from the business process and from the presentation of such services. SOA is a designed philosophy decoupled the business functions from the business processes and implementing the presentation of such services to the outside world (Bob, 2007).
Bob (2007) explained that the services interfaces are a contract that communicate with the services consumers and also promote reusability, and integration through the SOA implementation within the organization applications. Such service contracts should promote loose coupling between the system consumer and the system provider since both can be located at various places under different control of entities. It’s also important that services be reusable on its own where SOA design is already promotes such capability within any system architecture. SOA promises high ROI to any organization through advocating loose coupling, cohesion and reusability, and there are two SOA design patterns that can help promoting reusability: contract centralization, and logic centralization, and applying such mechanism in the SOA design patterns results in normalized and standardized services that can support the maximum reusability within any system.
The big changes introduced by the SOA model was the architecture that promotes the design around services rather than application where an independent software pieces can executes a single task upon calling such task by any consumer, and by applying such architecture it brings to the table the reusability of such services through any programs or software that can call such services. Implementing the right SOA architecture reduces complexity, and makes reusability implementation easy through the adoption of services that can help business promotes its customer’s needs (Mulesoft.org, 2011).
Anandagoda (2008) explained that service Oriented Architecture (SOA) is an architectural style that can guides any organization to create independent implementation of technologies and also create collaborative services that are loosely –coupled. The implementation of such architecture can provide the comprehensive and accurate insight of the businesses and also increase the RIO of the IT projects within any organization. In designing such architecture, the services exposed via SOA have to be analyzed with greater care to provide the maximum usability and re-usability requirements of such services. It’s important to follow the guidelines that can lead to the right implementation of the SOA, and some of these guidelines are:
· Services reusability – where interfaces for the existing applications can be used to develop the services required through the SOA architecture.
· Services Orchestration – The SOA enables the coordination of the services assemblies to form the business processes.
· Service Autonomy – Where the services adhering to the services agreement as specified by the WSDL (The service description) which can be interpreted by a UDDI server to provide the mechanism for publishing such service.
Anandagoda (2008) also explained that the flexibility of SOA and the power of such architecture can offer the following benefits to any organization:
· The ability of such architecture to unify the new application with legacy applications across the organization to create a business model that can be reusable for any future applications and future business functionalities.
· The traditional approach of application integration through code fixing proves it is a time-consuming and it is tedious work to be achieved and SOA attempts to improve such integration through the services and messages and creates more dynamic and collaboration among the applications infrastructure within any organization.
· SOA facilitates the well-defined service interfaces that separate the interfaces and the business logic.
· SOA advocates the fact that the services implemented by such architecture should be reusable services that effectively meets the business requirements while safeguarding the investment of the IT infrastructure.
· Through the SOA architecture, the ability to build ad-hoc applications from the existing software services can be achieved through such architecture.
· Through the implementation of SOA architecture, it is possible to achieve the enterprise quality services that can be interoperable across vendor implementations and as such; beak the barriers created by the formal technologies such as DCOM and COBRA.
· The reusability of the services implemented by such architecture (SOA) can bring a huge ROI to any organization, increase the operational efficiency and reduce costs within any organization.
Following the best practice in writing application code, and careful planning for implementing application functionality can increase the code reusability and reduce the amount of work required for post-production errors, revisions of the application code to find the right solution for such error, and cut down the development time. The reusability is measured by how easy an application can be updated with a new functionality, and can be modified or reusing its component for other applications (Eicker, 2011).
Object oriented programming takes the code reusability to a new level where several mechanisms can be used during the design phase to implement the reusability within any application, and its interfaces. Techniques that can be implemented within the code such as class interfaces and inheritance can bring the code to the highest level of reusability (Maila, 2007).
Finally, Service Oriented architecture (SOA) is a conceptual architecture that is used to implement the dynamic business services that can be provided to the end-user applications or other services via published interfaces. Such services expose the discrete business functions in better way which provides the best solution for communicating with business processes. The SOA provides the code reusability required to improve productivity, reduce cost and enhance business practices (Fidal, 2010).
Anandagoda, A. (2008) Service Oriented Architecture – An Overview [Online]. Available from: http://wso2.org/library/3174 (Accessed: 26 March 2011).
Bob, U. (2007) What is SOA really? [Online]. Available from: http://blog.objectmentor.com/articles/2007/04/11/what-is-soa-really (Accessed: 26 March 2011).
Eicker, A. (2011) Why Code Reusability is Important [Online]. Available from: http://www.alaneicker.com/featured/why-code-reusability-is-important (Accessed: 26 March 2011).
Fidal (2010) Service-Oriented Architecture in a Pervasive Environment [Online]. Available from: http://www.thelinkportal.com/education/2896 (Accessed: 26 March 2011).
Gilbert, G. (2007) Repeatable Code – A Step Up From Reusable Code [Online]. Available from: http://www.itstartpage.com/article.phtml?id=96 (Accessed: 26 March 2011).
Michael, J. (2010) Cod Reuse is (Damn) Hard [Online]. Available from: http://geekswithblogs.net/BlackRabbitCoder/archive/2010/05/27/code-reuse-is-damn-hard.aspx (Accessed: 26 March 2011).
Maila, T. (2007) Code Reuse with Interface Design and Composition [Online]. Available from: http://expressionflow.com/2007/03/26/code-reuse-with-interface-design-and-composition/ (Accessed: 26 March 2011).
Mulesoft.org (2011) SOA from the Bottom Up – The Best Approach to Service Oriented Architecture [Online]. Available from: http://www.mulesoft.org/bottom-up-soa (Accessed: 26 March 2011).
Tabib, M. (2009) Code reusability [Online]. Available from: http://www.theserverside.com/news/thread.tss?thread_id=55293 (Accessed: 26 March 2011).
Tripathi, J. (2008) SOA (Service Oriented Architecture) [Online]. Available from: http://completesoa.blogspot.com/2008/09/soa-service-oriented-architecture.html (Accessed: 26 March 2011).