- Intro to Hibernate 2:17
- Hibernate Sessions 2 questions
- Configuring a Project to Use Hibernate 6:34
- Create a Hibernate Configuration File 2 objectives
- Adding a POJO with JPA Annotations 9:34
- Adding JPA Annotations to an Entity 2 objectives
- Building a Hibernate SessionFactory 4:41
- The Builder Design Pattern 8:46
- The Builder Design Pattern 1 question
- Using the Builder Pattern 1 objective
Preview
Video Player
00:00
00:00
The Builder Design Pattern
8:46As 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.
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