We now want to make a new type of WordLibrary
that also scrambles the
individual letters of the words. We click on the
WordLibrary
interface and
press ALT+Enter (our magic key in NetBeans and IntelliJ IDEA). We select
"Implement Interface" and make the name "ScrambledWordLibrary".
Similarly to the ShuffledWordLibrary
, this ScrambledWordLibrary
will also
delegate to another WordLibrary
. We add the field
private final WordLibrary other;
To generate code we click ALT+Insert or right-click + Insert Code... and
select the code we want to create. I select "Constructor" and it then creates
a constructor for me that takes as a parameter the other WordLibrary
. Sweet!
More code generation coming up. If we delete all the methods in the class and
again press ALT+Insert or right-click + Insert Code... we see a selection for
"Delegate Method...". Select that and then select the methods
getWord()
, getScrambledWord()
and
getSize()
. The code is generated to delegate all these
methods to the "other" WordLibrary
.
getWord()
and getSize()
stay the way they
are, but we will change getScrambledWord()
:
First we get the letters from inside the word as a character array
(char[]
). This is an array of the individual letters inside the word. We then add a call
to the scramble(letters)
method. This method does not exist yet; we will write
it in a moment. We then return a new String
with the scrambled letters.
Again, we use ALT+Enter to create the scramble()
method inside the class. The
benefit of coding like this is that you save time thinking about what the
parameters need to be - your IDE figures that out for you.
At this point we do not want to decide how the characters are to be scrambled.
We thus make the scramble()
method
abstract
and remove the method body.
Because the method is abstract
, we need to also make the class abstract
. It
does not make much sense to have a private abstract
method. Abstract has to
be overridden by a subclass, but private cannot be overridden? It's a paradox,
and Java does not allow us to define such methods. It would work to make it
public
, but that would mean that any other class could call this method.
Instead, we make it protected
, which means that only subclasses can call it.
Technically, it is possible for other classes in the same package to also call
this method, but we usually discourage that. The classes in the
eu.javaspecialisdts.courses.juppies2.anagrams.ui
package would not be able to
call that method. Even though other classes in the same
eu.javaspecialisdts.courses.juppies2.anagrams.lib
package can call
the method, we usually try form a mental picture that we cannot.
The explanation why this is, goes way back to before Java 1.0 was even
released. The precursor to Java was called Oak. In that language, we did not
have a private modifier. We only had public
,
protected
and nothing. When we
did not specify anything, this was considered as sort-of private. Only classes
in the same package could access it. There was no way to make a member only
accessible from within one class. When Java 1.0 was eventually released, they
added the private
modifier, and had a private protected
combination that
meant we could only access the member from a subclass, not from other classes
in the same package. This was dropped in Java 1.1, which left us without the
ability to specify that a member can only be seen by a subclass and not by
other classes in the same package. See Newsletter 055.
We hope you enjoyed this tutorial. If you did, you will also enjoy our courses. We suggest you start with Extreme Java - Advanced Java, followed by Extreme Java - Concurrency Performance for Java 8.
We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.
We can help make your Java application run faster and trouble-shoot concurrency and performance bugs...