Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
As a step away from Hibernate, this lesson demonstrates a popular design pattern in coding called the **builder** design pattern. This pattern is used to write *readable* code that creates and configures an object.
Design Pattern Resources
- Overview & description of patterns: https://sourcemaking.com
- Code samples for patterns: https://github.com/iluwatar/java-design-patterns
Using Github With This Course
You can complete this course entirely using code created by you on your local machine. However, if you choose to use the code I've made available to you, you have two options:
- Use the project files linked at the bottom of this page, or
- Use the Github repository I've made available (recommended)
If you choose the recommended option of using the Github repository, it can be found at
https://github.com/treehouse/contactmgr-hibernate
To utilize Github with this course, you can download the Github desktop client for your system or use the command line interface provided with Git.
Clone this repository to your machine using the Github desktop client, or using the following command:
git clone git@github.com:treehouse/contactmgr-hibernate.git
To update your local repository to match a video's starting point, you can use the git checkout ... command in combination with the stage and video number. For example, to update your local repository to match the starting point of Stage 5, Video 4, you'd use the following:
git checkout -f s5v4
Notice the use of the -f option. This forces Git to override all local changes, so be aware: this will cause any changes you made to be lost.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
During the last video, we used a design
pattern to build a service registry and
0:00
I mentioned that we'd circle back to it.
0:05
Well, here we are.
0:06
This pattern, called the Builder Pattern,
is used to address a few common pit falls.
0:08
Mainly, the one of classes
that have many fields.
0:14
Creating an object is accomplished
by calling the classes constructor.
0:17
But, if the class has five
instance feilds, like ours does.
0:21
We might end up with a constructor
that has five perameters.
0:25
But the code that we type to
instantiate an object with
0:29
five perimeters isn't that readable.
0:31
And what if we want to be
able to create an object,
0:34
while specifying only
a couple field values?
0:36
Well, I guess we need a constructor, but
0:39
the order of that parameter list
may not be so obvious either.
0:42
So, we arrive at the builder pattern.
0:46
Using this pattern,
0:48
we're able to create readable code
that's intuitive and easy to use.
0:49
To see how this is done,
let's do this for our contact class now.
0:53
To demonstrate what we'd like to avoid,
I'll use similar code here.
0:58
It's what we used earlier in the course
to construct a sample contact object.
1:01
So, I'll create a contact,
I'll name it contact.
1:06
And I will call a constructor
that doesn't really exist but
1:09
let's pretend that it does.
1:12
I'll pass my first name,
last name, email address.
1:13
And a phone number 773-555-6666.
1:21
Now if we had coded this
1:22
constructor in a contact class, as we
did in workspaces earlier in the course.
1:28
We might remember the order
of our four parameters or
1:32
we could pop open the source code to see.
1:35
Still, this would require an extra step
that draws attention to the fact that our
1:37
code isn't as readable as it should be.
1:41
Even more, what if the contact class came
from a jar file we've included in our
1:43
project and
we don't have access to the source code?
1:47
For those reasons and
1:50
others, many developers choose
the builder pattern to address concerns.
1:51
Wouldn't it be much more intuitive and
1:55
readable if our code coud
look like this instead?
1:57
So, I'll create a contact and
2:01
builder object to specify something
that we feel our users would know.
2:03
The first name and the last name and
then, I'll put this on a separate line for
2:08
readability.
2:12
On that object, I could call a withEmail
method and specify my email address.
2:13
And with that return value,
I could call a withPhone method and
2:22
specify the phone number.
2:26
And that should be a long, not a string.
2:31
And finally, I'd call a build method
to build my final contact object.
2:34
And actually, without too much effort,
our code could look like this.
2:40
So, let's head over to contact.java
to see how we can accomplish this.
2:45
The first thing we'll need to do is,
add a contact builder class.
2:51
And though we could create
this in a separate file,
2:54
we can also embed a static
class in the contact class.
2:56
So for simplicity here in this course,
that's what we'll do and
2:59
I will do this at the bottom.
3:03
Public, static, class, contact, builder.
3:05
We'll need a field in this class for
3:12
each of the contact fields we
want our builder to configure.
3:14
So let's add those now.
3:17
I'll scroll up, and copy and
paste the four that I'm interested in.
3:18
From above, so
I'm interested in these four, right here.
3:22
So, I'll paste those right here and
I'll remove my JPA annotations.
3:27
Great, now the contact builder
constructor will contain
3:39
the two fields that are required.
3:42
And then, we might assume everyone will
get right away, the first name and
3:44
the last name.
3:48
Of course, this assumption could
certainly be up for debate.
3:49
Let's create that constructor now,
public contactBuilder.
3:52
And in there, I'll specify
the first name and the last name.
3:59
And this like any other constructor,
will initialize its fields.
4:05
And now, we get to add those handy
readable methods that we so desired.
4:15
Here is the withEmail method.
4:19
I going to declare it as a public
ContactBuilder method withEmail and
4:22
as a parameter,
we specify the email address.
4:27
Now this method is sort of like a setter,
in that,
4:32
we set a field using
a given parameter value.
4:35
But, there's one glaring difference,
which makes this builder pattern so
4:38
attractive and that is the return value.
4:43
Notice that we're returning
a contact builder object here and
4:46
the return value is this.
4:50
The object on which the method was called,
a contact builder object.
4:53
This is the part that allows
us to chain method calls.
4:57
If I pop back over to application.java,
I see these chain method calls.
5:00
I create a contact builder and
on that builder, I create with email and
5:05
I chain that to a withPhone call and
finally a buildCall.
5:09
So in a similar fashion,
let's now code the withPhone method.
5:17
So below the withEmail, I'll create
a public ContactBuilder method.
5:22
Call it withPhone, and
as a parameter, I'll include a long
5:27
and again, like a setter, we will set
the field using the parameter value.
5:33
Except that we, as opposed to a setter,
5:39
will return a contact builder object,
this.
5:42
Now the final method we need to create
in this class, is the build method.
5:46
So to do that,
5:50
this one will create the contact
object that we are after in the end.
5:51
I'll call this build and
we'll return a new contact object and
5:56
give the contact constructor
a reference to this object.
6:02
And I can't forget to create
the object by using the new keyword.
6:07
Now, since we don't have a constructor
that accepts a contact builder
6:12
object as a parameter,
we need to create that as well.
6:15
So, we'll scroll up here and create that.
6:18
I'll do that after my default
constructor that I listed here.
6:21
Public contact and this will accept
a contact builder object here.
6:24
I'll just name it builder
as the parameter name.
6:29
And in this constructor,
6:32
we'll initialize all the contact
fields with the builder field values.
6:33
So to do that, I'll start with
this.firstName pools builder.firstName,
6:38
this.lastName Equals builder.lastname.
6:46
This.email equals builder.email, and
6:51
this.phone equals builder.phone and
there you have it.
6:56
If you want to prove this
works in application.java,
7:03
you can print the contact object to
standard out and run the application.
7:06
Now, I see that I'm missing an import
statement here, so I'll go ahead and
7:10
import that.
7:14
If you get this prefix of
Contact.ContactBuilder,
7:15
that is because ContactBuilder is
a static class in the contact class.
7:19
If you don't want your
code to look like this,
7:25
you can simply alter
the import statement above.
7:28
You can,
in addition to importing this class,
7:31
you can import ContactBuilder explicitly.
7:35
So below this initialization
of the contact object,
7:40
I can simply display the contact object.
7:44
Which willll call that objects to string
method, which we included in our class.
7:47
Before I run this, I'm going to
comment out the session factor.
7:53
Since we don't want to initialize all
that hibernating functionality quite yet.
7:56
So with that commented out,
I'm going to right click application and
8:02
choose run and
let's see what our output contains.
8:06
There are the results of the Contact's two
string method, I see I got an ID of zero.
8:11
That will be the default
value of that long field.
8:16
As well as a first name, last name, email
address and phone number that I specified.
8:20
It looks like our builder pattern worked.
8:25
Now you've seen the builder pattern.
8:30
Which is often used for
objects that involve complex and
8:32
otherwise, unintuitive configuration.
8:35
For more on Java design patterns,
check the teacher's notes.
8:38
But now back to our regularly
scheduled hibernate program.
8:42
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up