DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Java String Templates Today
  • What Is Retesting?
  • Beginner Intro to Real-Time Debugging for Mobile Apps: Tools and Techniques
  • Building Resilient Systems With Chaos Engineering
  1. DZone
  2. Coding
  3. Languages
  4. Book Giveaway: Dependency Injection Exclusive Chapter Download

Book Giveaway: Dependency Injection Exclusive Chapter Download

Lyndsey Clevesy user avatar by
Lyndsey Clevesy
·
Aug. 28, 09 · Interview
Like (0)
Save
Tweet
Share
12.54K Views

Join the DZone community and get the full member experience.

Join For Free

DZone and Manning Publications have partnered to bring you an exclusive chapter from 'Dependency Injection' (by Dhanji R. Prasanna). This chapter covers organizing code in modules, watching out for tight coupling, designing with loose coupling, testing code in discrete units, and working with key rebinding.

Building Modular Applications

So far, we’ve looked at what it means for objects to be well behaved and classes to be well designed in the small. But in any real-world project, there’s also a big picture to be considered. Just as there are principles that help our design of objects in the micro, there are principles for good design in the macro sense. In the coming sections,
we’ll talk about these design principles and see how to relate them to dependency injection.

Chief among these is testing. DI facilitates testing and testable code, the latter being an extremely important and often-overlooked condition to successful development. Closely tied to this is the concept of coupling, where good classes are linked to the dependencies in ways that facilitate easy replacement and therefore testing—bad ones
are not. We’ll see how to avoid such cases, and finally we’ll look at the advanced case of modifying injector configuration in a running application.

First, let’s start at in the micro level and explore the role objects play as the construction units of applications.

4.1 Understanding the Role of an Object

We’re all very familiar with objects; you work with them every day and use them to model problems, effortlessly. But let’s say for a moment you were asked to define what an object is—what might you say?

You might say an object is:

  • A logical grouping of data and related operations
  • An instance of a class of things
  • A component with specific responsibilities

An object is all these things, but it is also a building block for programs. And as such, the design of objects is paramount to the design of programs themselves. Classes that have a specific, well-defined purpose and stay within clearly defined boundaries are well behaved and reliable. Classes that grow organically, with functionality bolted on when and where required, lead to a world of hurt.

A class can itself be a member of a larger unit of collective responsibilities called a module. A module is an independent, contractually sound unit that is focused on a broad part of business responsibility. For example, a persistence module may be responsible for storing and retrieving data from a database.

A module may not necessarily be meant for business functionality alone. For example, a security module is responsible for guarding unwarranted access to parts of an application. Modules may also be focused on infrastructure or on application logic but typically not both. In other words, a module is:

  • Whole —A module is a complete unit of responsibility. With respect to an application,
    this means that modules can be picked up and dropped in as needed.
  • Independent —Unlike an object, a module does not have dependencies on other
    modules to perform its core function. Apart from some common libraries, a
    module can be developed and tested independently (that is, in an isolated environment).
  • Contractually sound —A module conforms to well-defined behavior and can be
    relied on to behave as expected under all circumstances.
  • Separate —A module is not invasive of collaborators, and thus it is a discrete unit
    of functionality. 

These qualities of a module are largely important in relation to its collaborators. Many modules interacting with one another through established, patent boundaries form a healthy application. Since modules may be contributed by several different parties (perhaps different teams, sister projects, or even external vendors), it’s crucial that they follow these principles. Swapping in replacement modules, for example, replacing persistence in a database with a module that provides persistence in a data cluster or replacing a web presentation module with a desktop GUI, ought to be possible with a minimum of fuss. So long as the overall purpose of the application is maintained, a system of well-designed modules is tolerant to change. Much as different incarnations of an object graph provide variant implementations of a service, different assemblies of modules provide different application semantics. A module is thus an independent, atomic unit of reuse.

Objects and modules that collaborate typically have strong relationships with each other. Often the design of a dependency is influenced by its collaborators. However, each object has its area of responsibility, and well-designed objects stick to their areas without intruding on their collaborators. In other words, each object has its area of concern. Good design keeps those concerns separated.

Click here to download the entire chapter

The above introductory excerpt was taken from Dependency Injection, published in August 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.

 

Dependency injection Object (computer science) application Book Download

Opinions expressed by DZone contributors are their own.

Trending

  • Java String Templates Today
  • What Is Retesting?
  • Beginner Intro to Real-Time Debugging for Mobile Apps: Tools and Techniques
  • Building Resilient Systems With Chaos Engineering

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: