[No Audio]
So let's kick off this section now with adding
some more meat on the bones to the domain
and repository classes, because this will allow us to
have something a bit more interesting to test.
And we can also talk about some design decisions we
make, along the way as well, which is always useful.
So let's get started. Right? So let's jump
back into this project we've been working with.
So if we open up myapp, go into src main
java, and look at the production code we can see here
we've got the data, service, and web players, and
we've also got this User object as well.
So let's just double click this User object and
we'll just add an extra field on here to
say if the user is currently live.
In other words, it's currently having
an account which isn't suspended, for example.
So it's live on the system and you can log in.
You can imagine setting this flag to false if we
wanted to suspend the user account for whatever reason.
So let's just put that in. Just gives
us an extra field that we can test with.
And actually, you know what,
We'll always set it to true.
So whenever we create a new
user, we'll always set it to true.
In a normal system, you probably
wouldn't want to do this.
And again, we'll put the Getter on here.
To be is live.
The convention for Getters for boolean type
values is instead of being, for example,
get live, it returns isLive.
So it replaces the word get with is.
And we'll also regenerate the
hashcode and equals methods too.
[No Audio]
By the way, before I did Java
7, you don't have to do that. You can
actually change the template which IntelliJ uses.
So, for example, I can use an IntelliJ Default.
And what this does
[No Audio]
click next through these, is that
it generates equals and hash code methods in a way
that's going to work with any JDK version.
So it's probably better to do and that means we
can just nuke these objects reference from Java 7.
And then we've got our user object.
Let's also add an enumeration now as well.
Now the other thing we want to add with this is
basically the notion of a user being a RegularUser.
So a user who's a customer, if you like, on
the website, or who is a superuser, in other words,
an admin or a manager, that kind of thing.
So for now, let's just say there are two types.
There's a user and an admin.
So how can we represent this? So we can either
represent this by, for example, having an enumeration
reference in the user class, or alternatively, by
introducing a new type, for example, super user or
admin user or whatever you want to name it.
Now we can just put an enum here for now. That's fine.
So let's just go up here
[No Audio]
and we just put the enum in like that.
And then we just need to make sure we
can hold a reference to that user type.
So here we're defining two user
types, RegularUser and AdminUser.
[No Audio]
Let's just say we make that final.
[No Audio]
So should we have to assign here the constructor?
[No Audio]
And so we do this.
So we have to be explicit about the type,
that is the type of user that we're creating.
This means that if I find usages of this now
[No Audio]
with command shift F, then call to
the constructor like this will no longer work.
So I could change them.
I could change them now and do
UserType.REGULAR_USER for example.
And I'll do that in this case for
the sake of this demonstration with Hamcrest.
But in general a better approach in my
opinion is to instead mark a constructor as
package private, then instead create static factory
methods to create the different types of user.
And I will just do this now.
In fact, I think about it. So public static user,
public static user create regular user,
[No Audio]
which needs to take the username and password.
[No Audio]
Then we'll do return new user username password.
And now we'll put the user type in here.
So this is nice because basically we're sort of
encapsulating to a very mild degree the logic of what
it means to create a RegularUser or AdminUser
inside this class itself and create another one
therefore add AdminUser
[No Audio]
and you might want to read in these as well too
regular and admin or whatever else.
And additionally, put an extra user role type specific
behavior in each of these constructors to set up what
it means to be an AdminUser, or what
it means to be a RegularUser.
For example, if you had different access rights
or ACL permissions you want to put in,
you can put those in as well. Anyway, let's not get
carried away. We don't really care about that.
Let's just go back to the UserRepository
and now we can do this.
That is, we can use our factory method.
You'll notice here we've got the user
which we can no longer use because
the visibility was marked as package private.
So we can just do now User.createRegularUser and
then we take this out now because we don't need it
anymore, optimize the imports
[No Audio]
and then make the same call here.
So a little bit of refactoring there
just to tie things up a bit nicer.
And now we have this userType.
We probably want to get the userType as well.
Just put a Getter on there for the userType.
And once again please get into the habit.
Whenever you add new fields of regenerating
hashcode and equals
[No Audio]
just accept all those, that's fine.
So this user class is flushed out
a bit more now, which is nice.
So let's go back into UserRepository
and put in some extra users.
And this is because we're also going to create
admin users in this as well, which we can
test with, so let's add another RegularUser
Say suzie
[No Audio]
Debra
And these are regular users
[No Audio]
and now we'll have some admin users.
And let's just say we've got one admin for now.
Which is thomas.
[No Audio]
Yep that looks good.
So that gives us enough code for now, so let's move on.