Hello, Jim.
Today, we are going to lunch with you and other collections of Iraq.
Today we'll talk about you interface and one more important interface that extends you, that is that
interface with the masses in interface.
And I hope you didn't skip lessons because in previous lessons during the General Overy, we already
talked about you and discussed Masset that this interface has.
But today we'll dive into the details.
After that, we'll learn methods in that interface.
Today, we're going to learn what is the difference between these two interfaces.
Also, we'll learn what FTF old principle is and what LIFO principle is.
After we learn interfaces, we'll take a look at the most popular Q and deck implementations.
And I will share with you practical tips and practical cases.
And at the end of the lesson, we are going to review your home task and I will explain how you can
practice your skills.
Let's start and to understand what CU is, we have to understand what FTF old principle is.
If you don't skip lessons, then you remember that FCF also is a method of organizing of a data structure
where the first elements that enter the queue, the first leifs is a Q, in other words, the head of
the queue always processed first f i f o stands for first in first out here on the slide you may see
brutalisation of the Q the Q has the head and the tail.
Students usually wondered where the heart of the Q is and where style of the Q by convention.
The end of the queue at which elements are added is called the tail back Oriya of the Q The end at which
elements are removed is called the hat or front of the Q.
Analogously two words used when people line up to wait for goods or services.
Does it make sense now?
If yes, then let's answer our next question.
Where Q is used.
Imagine that you have two services.
The first service is in charge of onboarding of new customer.
This service process information about the user verifies his payment method at him to the theorem,
checks whether this user already registered, etc. Let's call it onboarding service.
And another service is in charge of handling all payments from the user for his subscription on a monthly
basis.
Let's call this payment service.
Those are two independent services because the first one is in charge of selling subscriptions to customer
only on one side.
But they are different of the similar marketing sites that promotes different products and services
of the company.
Our onboarding service is one out of many services, but the service that is responsible for charging
clients on a monthly basis is used by all websites and systems within the same company.
This is real life scenarios that my team implemented in simplified form also.
But still, I believe you got my point.
And before process payment information from any of the website, the queue exists.
It exists right in the middle between all services and charge and service and all services, including
our onboarding service submits the message in the queue.
The message contains payment profile of our customer and product details and our payment service process.
All these messages one by one and implements all necessary logic related for recurring payments.
Does it make more sense now?
Can you understand now?
Why do we need Kyuss hope?
This brings more clarity and you understand why we need to use Qs.
OK, if you understood cuz let's understand what a deck is and to understand that we have to understand
what LIFO principle is.
LIFO is a method of organizing the manipulation of a data, whereas the last element that entered the
container should be processed first.
LIFO stands for Last In, First Out.
If you remember stack class that extends vector, that is also implementation of LIFO principle.
And on the screen you can see visualisation of stack.
But where we might want to apply LIFO principle, the easiest example of that usage, which you are
faced with on a daily basis, is in the clips.
Have you ever used and do operations in Eclipse?
How do you think the operation works?
Each batch of changes is put in the stack and then the case and those short cards is correct.
The latest separation is removed from the stack.
For example, you wrote Hello World.
The World World is on top of your stack.
When you want to run the operation, it leaves the stack first.
Or imagine your browser history.
You open new pages and then you need.
The return on the previous page or asset allocation in your Java program, we can call one message from
another one and after that call one more method how to track the flow of program execution only with
the help of the stack data structure that stores elements according to LIFO method that it makes more
sense.
Now, can you understand now when do we need stack?
Awesome.
And now when you understood what CU and DEC is and why we need them, I suggest dive deeper into the
details and learn interfaces.
Here is a new interface we have at and of a message here.
Both exist to add elements to the queue.
Both returns through in case element was added to the queue.
Then why do we need two similar methods and why do we need add method here?
If it is present in collection interface?
Let's understand the difference at that is present in queue interface to highlight the specific behavior
of that method in queue type add method adds elements to the queue.
But as you can see from the documentation here in legal state, exceptions will be thrown in case element
couldn't be added because of the capacity restrictions.
To be honest, in most of the cases you wouldn't see this error while working with the implementation
of the queue interface.
Why?
Because most of the implementations have no restrictions on capacity and their unbounded.
And in this case there is no difference between at and of.
A method of a method doesn't throw exception in case element is not added because of the capacity restrictions.
It also can return false hope.
This knowledge will help you during the interview, in case you will be asked what the difference is
between add and offer method in queue interface.
Let's move on.
We have two methods to retrieve elements from the heart of the queue and remove it from the queue.
Zaya, remove and pull.
The only difference between them is the way how they behave in case there are no more elements in the
queue.
Remove Masset in this case will throw no such element exception and Paul MassArt will just returns.
And now what do you see in real life?
I would say evaluate the logic of execution of your program.
First, in case you would ask me what method I would use, I would use full method and would just perform
null check.
I just afraid of all exceptions and I would rather opt for options.
That doesn't throw an exception, but all cases and programming styles are different and I can accept
that.
And that's why it's up to you.
Which method to choose is a similar situation with the next two methods.
We have two methods that allows us to get the elements from the head of the queue, but that don't remove
element from the queue zaya element and pick.
The only difference is that element Masad Maestro.
No such element exception in case there is no more aliments and big method would just return.
Now you already know what I would choose.
That's all methods that are declared in queue interface.
Let's move further and let's investigate what message do we have in that interface.
So as we already discussed, that extends queue interface and organizes data according to LIFG principle.
Let's review methods now that are present here in the top of our list.
We can find a lot of similar methods that can work with the head and with the tail of the queue at first
and at last of a first and of last.
Remove first and remove last, both first and last week first and pick last.
I believe it is clear how they work.
Since we discussed similar methods in queue interface, I noticed that there is no element first and
element last method if to follow the analogy in is naming.
But do we have methods that doesn't remove element from the queue and throws an exception in case there
is no element?
Yes, we have aget first and last method here.
They here also to interest in masses, remove first Securus and remove last appearance.
When we are referring to the first occurrence, we mean first in case we would reverse elements from
the had the tail.
So the first Securus will be closer to the heart of the queue and the last appearance is closer to the
tail of the queue.
After that abasic message from the queue go here and en masse, it adds all elements to the container,
the same as it is declared in connection interface.
There is only one clarification that all elements will be inserted into the end of the queue.
And here are static methods.
We already discussed what the stack is and here's a mass to manage stack push.
It adds element in the heart of the queue.
This method will throw illegal state exception in the case.
Element can't be added due to capacity restrictions.
This method is similar to at first method.
This is even specified in general documentation.
Then why do we need it at all?
For compatibility reasons with legacy class stack, the push and pop methods exist.
This means that they're only to make a transition of all code easier for programa.
The pop method is here and it is equivalent of remove first MassArt.
And I believe you already understood why Oracle left this method in this interface.
The last message that we didn't talk about is the sending iterator.
This message, according to the interface, should return iterator objects that can iterate over the
elements in reverse sequential order.
That is from the last element from our tail to the first element to our hat.
That's all matters that we have in our back interface.
Now let's investigate the most popular Q and deck implementations.
On this slide, you can see the most popular implementations of Q and back interfaces, I recommend
you post the video and read the slide attentively.
I believe there is no need to investigate each of these class in details.
It is better to put our focus on the most popular implementations, the most popular implementation,
in my opinion, and based on the official Oracle tutorials can be split in two major categories implementations
of the interface and implementations of just rescue interface.
In case you need the implementations, then most likely you will be happy with slinked list or array
that class.
If you need Q implementations, most likely you will opt for lenth list of priority queue if you need
thread safe implementations of the queue.
I would like to draw attention to avoid blocking Q and priority blocking queue.
If you need thread safe implementations of DEC, then your choice is linked lock and DEC.
As you can see there is really a lot of options.
But in my opinion and based on my experience in 95 percent of cases when you would need to use DEC implementation
to implement some stack or in case you would need Q you would use in case class the rest five percent
of cases is for thread safe implementation of the Q and DEC and also priority.
Q taking into account we already had lesson about Lindley's and we already learned the Q and DEC interfaces.
There will be nothing hard for you just to call these methods on linked list.
And that is why, for the sake of the demo, I would like to show you how AQ works on the example of
priority.
Q So here I prepared them file.
I will leave link to this file in attachments to the lesson so that you could copy and run this file
on your local computer.
Here I declare it variable of type.
Q Parametrized with the integer type here I created object of.
Q And in these lines you can see that I added to the Q five elements.
They are two eight three one then.
So in the case I'd like to take the first element in the Q what it would be.
Take your time to think about this question because this is a trick question.
We all know how Q works and what is a five for principle, but priority Q has interesting feature.
It automatically source elements according to the natural order.
I hope you didn't skip the lesson about comparator uncomparable.
And you know that natural order is an order that is described in the compared to method because of implementation
of comparable interface.
And that's where a provocative word comes from in the name of the Q it prioritize elements.
So in case I would prefer to control the elements from the head of the Q this would be one even despite
integer object was well your one wasn't inserted the first.
Let me run the program to show you this.
I used polymathic to get elements from the Q and remove it.
So the size of the Q right now is four now in case I call Big Masset and get the hell out of the Q,
but don't remove element here.
You can see in console output that our next object and our priority.
Q is to and the size of the peak.
It is still four because I didn't remove elements from the Q Pay attention to the fact that all elements
that you put into the priority.
Q should implement comparable interface because in case type doesn't implement comparable interface,
Breuer's UCU object would throw exception, glossiest exception that would say that your type cannot
be cast to comparable type.
Let me show you an example.
Let me comment these lines of code here, you can see that I create Q Parametrized by product type.
Just to remind you, product is our custom type that we created during our work on online store implementation.
After that, I want to place my product into this.
Q Let me run the program to show you what would happen and here you can see glass cast exception.
What to do now?
We have two options here.
The first one is to use only types that implement comparable interface.
The second option is to set our priority.
Q How to compare elements.
Let me comment these lines of code to show you the next example here.
You can see that I created the same Q Parametrized by product type, but I pass the product comparison
to the constructor of prosecute.
Now my project knows how to compare products and saw them let me run the program and we can't see error
anymore.
That is because our Q knows how to prioritize products, where to use priority.
Q Imagine that you want to implement helpdesk during the day.
You receive tons of requests and complaints, but you have limited number of operators in your company
that can.
These requests and you have special app for your operators where each operator can click a button,
they can request and move it in progress, and it is obvious that most critical requests should be processed
first in case a customer can't make a payment in the online store or customer already paid.
But some error happened and he or she can't get details of his order.
That is more critical than some random question, like one sorting by manufacturer will be implemented
on your site.
They agree with me and what you have to do probably on the front end, you would implement some dropdown
where you would ask your customer to categorize request.
For example, here on the slide you can see example of support of Panya in your system.
You have some object, something like support ticket type.
You also have to implement logic that would assign support ticket type.
And based on the type of the request, you would assign priority, high, medium or low.
And after that you would pull your support ticket object into the queue.
And you already know that we have to either implement compatible interface in our support ticket or
we have to create a competitor and pass it to priority queue.
Interesting.
I hope it is.
And moreover, implementing something like this already a real life task for our software engineer.
This will be your homework.
But before I would share with you the details of your homework, let's recap what we have learned today.
Today we learned Q and DEC interfaces.
We learned in detail how matters that are described in these interfaces work.
We learned what a FFO and LIFO data store methods are.
We used you and DEC implementations and learned the most popular ones after that.
On the real example, we learned how particular works and now I suggest reviewing your homework.
You have to implement helpdesk facades that would serve as a main interface for a support engineer to
interact with the system, helpdesk facade interface has only three masses that you support.
You could get next support ticket and get a number of tickets according to our requirements, get next
support ticket.
Masset will be called when your support engineer would click on the button.
This message should return top priority item.
I almost explained to you how to implement Help Desk in the online store.
Here you can find the details about what request type might be and priority for specific request type
during the creation of the support ticket will specify only typos request and its priority is defined
automatically based on the Moppin that are written down in the table.
And there is one more requirement in the case.
Support tickets have the same priority.
The one that was created earlier should be processed first.
I can give you a small hint here.
You can implement counter.
This even might be static field and you may consider the value of this field when you would compare
to support tickets, for example.
Does it make sense home?
The task is clear for you.
This is a really interesting task that will help you a lot in understanding of the cues and will give
you some clues to real life experience.
Thank you all for your attention.
Have a great day and see you in the next lesson.