Java Reference
In-Depth Information
Listing 2.7
The
RomanticChocolateOffer
class
package fancyfoods.chocolate;
import java.util.Calendar;
import fancyfoods.food.Food;
import fancyfoods.offers.SpecialOffer;
public class RomanticChocolateOffer implements SpecialOffer {
@Override
public String getDescription() {
return "A wonderful surprise for someone you want to impress.";
}
@Override
public Food getOfferFood() {
if (isNearValentinesDay()) {
return new HeartShapedChocolates();
} else {
return new SquareChocolates();
What's on offer depends
on time of year.
}
}
Is it early
February?
private boolean isNearValentinesDay() {
Calendar today = Calendar.getInstance();
return today.get(Calendar.MONTH) == Calendar.FEBRUARY
&& today.get(Calendar.DAY_OF_MONTH) <= 14;
}
}
There's no need to export the
fancyfoods.department.chocolate.offers
package,
because nothing else in the application should depend on it. It's not always possible,
but a good goal in application design is to try to divide bundles into those with
exported packages but no package dependencies (like
fancyfoods.api
) and those
with imported packages but no externals (like
fancyfoods.department.chocolate
).
A bundle that both exports a lot of packages and imports a lot of packages is highly
coupled, and therefore fragile. The ideal dependency graph should look more like a
fork than like spaghetti.
How will other code get hold of the
RomanticChocolateOffer
if the package isn't
exported? To make the class available for dependency injection, you need to provide
metadata for the Blueprint service.
Blueprint metadata should live in a folder called
OSGI-INF
/blueprint. (If for some
reason you need to use a different folder, you can point Blueprint to your files by list-
ing them in an optional
Bundle-Blueprint:
header.) The filename doesn't matter,
but blueprint.xml is a popular choice.
Listing 2.8
A simple blueprint.xml file
<?xml version="1.0" encoding="UTF-8"?>
<blueprint
xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
Namespace is important!
