Skip to main content

Modular Design

  • Chapter
  • First Online:
Creating Maintainable APIs
  • 1207 Accesses

Abstract

In the previous chapter, we analyzed information hiding as a mechanism to hide implementation details from external parties (clients and providers). However, we haven’t spent a lot of time looking at our subjects as physical entities. We were complacent with the notion that we do possess some logical entities that need their own API. We have merely struggled to reduce the amount of exposed implementation details to conceive an evolvable API. In this chapter, our focus is on the kinds of entities we usually manage in large software projects, and how such entities are materialized as a unit of use and reuse.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 39.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 49.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    Another good alternative is the NetBeans module system, which is fully OSGi-compliant since version 6.9 ( http://wiki.apidesign.org/wiki/NetBeans_Runtime_Container ). The Eclipse Equinox is an implementation of the OSGi core framework specification ( http://www.eclipse.org/equinox/ ). Java 9 will come up with a modularity support called Jigsaw, but at the time of this writing, it is too early to say how it is going to be accepted. I have a feeling that it will come too late, and will share the destiny of the JDK logging framework. The latter appeared well after Log4J was already established as a de facto standard Java logging solution.

  2. 2.

    You may read the whole book at https://ebooks.adelaide.edu.au/l/locke/john/l81u/index.html .

  3. 3.

    For more information about this book visit https://pragprog.com/book/tpp/the-pragmatic-programmer .

  4. 4.

    See [10].

  5. 5.

    It is an indication that the type isn’t a subclass of java.lang.Object, has special treatment in the Java virtual machine (JVM), and so on. The notion of primitive types was an attempt to make Java acceptably fast in the 1990s. Nowadays, optimizing compilers (like Graal; see http://openjdk.java.net/projects/graal/ ) don’t need such a hint, and can generate fast code even with “normal” subclasses of Object. The notion of primitive types just complicates the JVM. Nobody should design a new language with primitive types anymore.

  6. 6.

    See [10].

  7. 7.

    Another one is the stability of an API, where people think that stable means fixed or unmodifiable. In the case of an API, stable means its readiness for backward-compatible evolution. For a module, greater stability implies bigger resistance to change. Modules with a high number of incoming dependencies (afferent coupling) are said to be stable. The number of outgoing dependencies (efferent coupling) defines the module’s weight. A higher weight ruins usability and testability, as you would need to handle many dependent parts to use and test the module.

  8. 8.

    For information about Racket’s modular framework, visit https://docs.racket-lang.org/guide/modules.html .

  9. 9.

    Sure, you can always simulate recursion using a stack, but that is like simulating OOP in C (e.g., you will have to fiddle with virtual method tables and function pointers to get polymorphism, or you could just leverage GLib).

  10. 10.

    This is not true in general, as modularity considerably influences logical design, too. For example, if you notice that a logical package is split across multiple modules, you need to revisit your logical design to avoid this situation. Also, if you notice a circular dependency between your modules, then you will surely need to refactor your logical design to escape circularity in module relationships. In the end, your logical design always benefits from modularity.

  11. 11.

    See [11].

  12. 12.

    Don’t use Felix SCR’s annotations, as they are obsolete (including the Felix SCR Maven plug-in).

  13. 13.

    In our case, the bnd tool will infer the imports for us, so the pom.xml could be even smaller. I have put it here to showcase the usage of the Import-Package instruction. The only situation when explicit imports are useful is the desire to leave out many parts from a huge OSGi bundle.

  14. 14.

    Cobol programmer (business oriented): “Data?”  Basic programmer (“let for loop live forever” oriented): “There, look!”   Java 8 programmer (nothing surprises her or him, who has seen every possible paradigm on Earth): “No, dude, that is Lieutenant Commander Data from Star Trek.” Turns back and throws a ReflectiveOperationException exception.

Author information

Authors and Affiliations

Authors

Rights and permissions

Reprints and permissions

Copyright information

© 2016 Ervin Varga

About this chapter

Cite this chapter

Varga, E. (2016). Modular Design. In: Creating Maintainable APIs. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-2196-9_2

Download citation

Publish with us

Policies and ethics