Java Reference
In-Depth Information
Discussion of the network application
Even though our application is not yet complete, we have done the most important part. We
have defined the core of the application—the data structure that stores the essential information.
This was fairly straightforward so far, and we could now go ahead and design the rest that is
still missing. Before doing that, though, we will discuss the quality of the solution so far.
There are several fundamental problems with our current solution. The most obvious one is
code duplication .
We have noticed above that the MessagePost and PhotoPost classes are very similar. In
fact, the majority of the classes' source code is identical, with only a few differences. We have
already mentioned the problems associated with code duplication in Chapter 6. Apart from the
annoying fact that we have to write everything twice (or copy and paste, then go through and
fix all the differences), there are often problems associated with maintaining duplicated code.
Many possible changes would have to be done twice. If, for example, the type of the comment
list is changed from ArrayList<String> to ArrayList<Comment> (so that more details
can be stored), this change has to be made once in the MessagePost class and again in the
PhotoPost class. In addition, associated with maintenance of code duplication is always the
danger of introducing errors, because the maintenance programmer might not realize that an
identical change is needed at a second (or third) location.
There is another spot where we have code duplication: in the NewsFeed class. We can see that
everything in that class is done twice—once for message posts and once for photo posts. The
class defines two list variables, then creates two list objects, defines two add methods, and has
two almost-identical blocks of code in the show method to print out the lists.
The problems with this duplication become clear when we analyze what we would have to do to
add another type of post to this program. Imagine that we want to store not only text messages
and photo posts, but also activity posts. Activity posts can be automatically generated and in-
form us about an activity of one of our contacts, such as “Fred has changed his profile picture”
or “Ava is now friends with Feena.” Activity posts seem similar enough that it should be easy to
modify our application to do this. We would introduce another class, ActivityPost , and es-
sentially write a third version of the source code that we already have in the MessagePost and
PhotoPost classes. Then we have to work through the NewsFeed class and add another list
variable, another list object, another add method, and another loop in the show method.
We would have to do the same for a fourth type of post. The more we do this, the more the code-
duplication problem increases and the harder it becomes to make changes later. When we feel un-
comfortable about a situation such as this one, it is often a good indicator that there may be a better
alternative approach. For this particular case, the solution is found in object-oriented languages.
They provide a distinctive feature that has a big impact on programs involving sets of similar
classes. In the following sections, we will introduce this feature, which is called inheritance .
Using inheritance
Inheritance is a mechanism that provides us with a solution to our problem of duplication. The
idea is simple: instead of defining the MessagePost and PhotoPost classes completely inde-
pendently, we first define a class that contains everything these two have in common. We shall
Search WWH ::

Custom Search