In the previous lessons we discussed how to use functionality
by referencing other modules. In this lesson
we will see the benefits of using modules and how
adding references influences the application footprint
Let's see first why you should use modules
By splitting functionality into modules you are creating
an abstraction that hides the modules' implementation
and its easier to use so abstraction is the first
benefit of using models. You also
isolate functionality making it easier to test
and to maintain. So isolation is the second benefit
Third, it will be easier to manage complexity
as you will be tackling smaller problems. So
using models allows you to manage the complexity
of the problem at hand. And finally
having different modules leads to more
effecient teamwork. Developers are not always stepping on each other's toes
as they can work on different model at the same time
so these are the benefits of
using modules. And in order to use models to build our applications
we need to use references between those modules
so we need to understand the impact of having references between modules
in the application footprint. So let's try to understand what happens when we
create a reference
and let's use our eBidding application
as an example. So you recall from the previous lessons that
we referenced the suppliers module from the eBidding module
and also the Google Static Map module. To be able to run this application
The code of the referenced modules
all the Suppliers module and the Google Static Map is also included in the
application
so when we publish the eBidding application
we have the code of eBidding module,
we have the code of the suppliers module
and we have the code of the Google Static Map
I'm drawing these me with different sizes because I'm assuming here that
the eBidding application will have more functionality than the suppliers
and more functionality than the Google Static Map
Now the code of the referenced modules is included
so that the application can be compiled and run
Now let's imagine that we
extend the eBidding application, we are extending the eBidding application
by referencing another module where we have
a Product entity, and basically we want to be able to reference
a product when we create a request now
what will happen in this case. So now when we publish the eBidding application we
have
the code of the eBidding module, the code
of the suppliers module, the code of
the Google Static Map, and we also need to include, let me just
highlight here, we also need to include the code
of the OrderManager
Here, I'm drawing the OrderManager
roughly with the same size as the eBidding application, assuming they have
an equivalent amount of functionality
but when we do this, when we reference the
OrderManager, the OrderManager module itself
also has references to other modules. Let me highlight here
these models here
are dependencies of the OrderManager
So in order to publish the eBidding application, to be able to
compile it and run
we also need to include here
all those modules that are
dependencies of the OrderManager
And what happens here is that
we are growing the footprint of the eBidding application
with unnecessary code. All these dependencies here
are really not necessary for the eBidding application because we only need
the product Entity for the eBidding application
So is there a way to avoid this inefficiency
Yes there is, let's take a look at the following example
in this case we have the same eBidding application we have
also here the OrderManager, but the Product Entity
that was included in the OrderManager module
is now on its own module
called Products, in the Products application, and what happens in
this case
let's go through it to be able to publish, to compile
and run, the eBidding application we need the code
of the eBidding module, we'll need the code of the
Suppliers module and also need the code
of the Google Static Map. And now
that we added this reference here
to the Product, we also need to include
the Product module as well
But we don't need to include
all these references here. So as you can see
in this second scenario we have a much more
efficient use of the code
in the eBiddings application compared to what we had
in in the previous example. In the next lesson
we will see a framework that helps you decide
which modulesto create, and still avoid this problem
avoid growing the application footprint
with unnecessary code. And that's it