Art of Software Reuse
  • About
  • Introduction
  • Why Do Reuse Efforts Fail?
    • Common Pitfalls
    • Conway's Law
    • Care About Risks
    • Pursuing Perfection
    • Lack of Domain Focus
    • Entropy
  • Tenets
  • Success Factors
    • Revisit Assumptions
    • Communicate, Constantly
    • Collaborate
    • Review Code
    • Be Domain Driven
    • Target Quick Wins
    • Reduce Friction
    • Document
    • Build for Immediate Use
    • Address Support Needs
    • Managing Complexity
  • Practices
    • Minimise Jargon
    • Leverage Interception Points
    • Delay Commitment
    • Never Waste A Production Incident
    • Be Disciplined
    • Be Demand Driven
    • Continuous Alignment
    • Iterate, Iterate, Iterate
    • Build a Product Line
    • Understand Lack of Reuse
  • Design
    • Wrap Legacy APIs
    • Think Products, Not Applications
    • Identify Common Needs
    • Create Common Connectivity Components
    • Consistent APIs
    • Manage Domain Variations
    • Evolve Functionality Iteratively
    • Offer Reusable Assets with Multiple Interfaces
    • Leverage Services Across Functional Flows
    • Mediate Service Requests & Responses
    • Refactoring
    • Abstract Utility Functions
    • Reduce Technical Debt
    • Facilitate Extensibility
    • Encapsulate Variations Using Patterns
    • Understand Adoption Barriers
    • Ease Testability
    • Supportability
  • Tips
  • Resources
Powered by GitBook
On this page

Was this helpful?

  1. Design

Offer Reusable Assets with Multiple Interfaces

PreviousEvolve Functionality IterativelyNextLeverage Services Across Functional Flows

Last updated 5 years ago

Was this helpful?

In order to maximize the reuse potential of your assets offer multiple interfaces to the same functionality aimed at targeted audiences. For example, may be you need to expose a service that finds products based on some input criteria. Typically, you might create a findProduct capability that will be generic and reusable and this capability might take input parameters such as product name, identifier, and product family etc. In addition to this basic capability expose additional interface based on line of business – findProduct (name, line of business), findAllProducts (name, line of business) or one based on the relevance criteria – findProduct (name, full-text-match or starts-with-match or fuzzy match) or a combination of these.

This doesn’t mean you run out and build interfaces! More interfaces mean more maintenance so there is a careful balance between flexibility and the number variations that you can effectively manage. On the flip side, if there are multiple interfaces offered your consumers will find it easier to integrate and invoke your reusable assets. To realize this idea, map the variations into a standard set of parameters and the rest of your processing can proceed oblivious of the consumer input. Defaults and standard values can be provided for missing inputs when doing this.

multiple_interfaces

_how do you identify these additional interfaces? _As with everything else, these interfaces need to be identified based on demand and priority. If your business sponsor needs to offer a capability for a particular geographical region (e.g. offer for the Americas first, followed by Europe, and Asia-Pacific) or for a particular product family then that is what you should consider for development.