I watched this video a couple of times when I needed to learn these for exams 8 years ago. Interestingly, last night the intro, "hey... sup" and "ello govn'r" expressions came to my mind. I had forgot your name sir, but I was remembering the video. Now I am here. Thanks for the lessons Mr. Quinn.
I love how good teachers try to get creative so students can pay attention. I know some of you don't see the relationship this teacher is trying to establish, but I do. Yo, yo, yo! That's a cool teacher!
Thank you for the invitation! I don't know if I could handle moving away from family, but if you are serious perhaps there are ways to partner remotely. I think it would be incredible to teach a multinational course through the internet!
So static binding happens during compile time. Meaning in the main, test 1(q) will link back to Person q which will link to test 1 (Person x) {print (“Ello….”);}// It will print out “Ello Govenor” Dynamic binding happens during runtime (late binding). Meaning if we do “q.talk();” in the main method, it will then reference “q” as new student which will then link to the Student’s talk. Does it sound like I understand the differences between the two bindings?
You got it! q.talk() is dynamic because at compile time the computer checks q's type (Person) and sees that it is ABLE to talk but at runtime when the command get executed the instance that q is pointing to (a Student) runs the code with its associated talk method. in the example Test1(q) there is a decision made at compile time to run one of two Test1 methods: the one that uses a Person or the one that uses a Student. Since q is a Person (by reference) the Test1 method that uses a person is chosen and is now statically bound. When you go to run the program it doesn't matter that q is ACTUALLY a Student because the decision to execute the Test1 method for a person had already been made at compile time.
@@sharifsircar ha, no worries. I try to stay on top of comments and respond ASAP. Regardless, I appreciate the kind thoughts. We are one united world in this crisis.
Very well done, liked and subscribed! i just have one question tho, how would i know the methods that get invoked in the compile or the run ( i didn't understand this point) is it like every method that takes parameter will look at the dynamic type of the object ?
The determining factor is whether you are looking at the REFERENCE or the INSTANCE. At compile time you only look at references. If we said "print( joe )" we are talking about the reference called joe. Suppose there are two print methods, one that takes a Person parameter and one that takes a Student parameter, the compiler chooses which one to run based on the type of REFERENCE joe is. Even if we had "Person joe = new Student()" at compile time joe is treated like a Person so the print methods that takes a Person is called. However, let's say in that method it said something like "joe.talk()". Since we are now de-referencing joe we are looking at what joe actually IS. Since he is an INSTANCE of Student that version of the talk method would be called. The best way to figure this stuff out is to make a sample program with lots of overloaded and overwritten methods. In each one simply put a print statement that says what method you are in. Then try different versions or calling methods with multiple combinations of references and you'll start to see the patterns emerge. Hope this helped clarify!
What I don't really understand is during run-time why the program can't see that person q is actually a student in this line: test1(q) and why it can see it when we're doing q.talk()
Olof Enström In both cases test1(q) and q.talk() at compile time the program is ONLY checking to make sure the declared type can do what you are asking (static binding). However, with test1(q) there are overloaded methods. The compiler ALSO turns your computer code into specific instructions to be followed, one of those instructions being which version of the overloaded method to run. Since the compiler is only looking at the declared type and not the instantiated type q appears to be a person so the corresponding test1() method call is made. By runtime the instruction to run that version of the method gets executed. The funny thing is that if q is asked to do something like q.talk() that instruction is executed by the instance, in this case a student. Hope that clarifies, sorry for the delayed response!
So then why can't we just use the line of *Student q = new Student* intstead of using *Person q = new Student*, so that we don't have to deal with that problem you mentioned at the end, with the Test1(q) method. Btw thank you for the video! I have an oop quiz tmrw afternoon :/
You can! This is really a question about "polymorphism", meaning that you can refer to an object many different ways. Sometimes it is inconvenient but other times it can be a huge help. Imagine for example a car dealership that wants to keep track of its inventory. You might do so with an ArrayList of type Car. However Car is more general than FordTaurus, FordF150, and FordFiesta. Each of these specific types of cars might have special methods but it is way more convenient to treat them all like Car objects so they can be in one list. At a school you might have a similar example where you keep a list of Person objects, but in that list you may have Student, Teacher, and Parent objects. There could be an advantage to one vs three lists. That is a design decision, but you need to understand the technical implications in order to make a good decision. Hope that clarifies!
Wow thanks for responding! Esp before my test tmrw! :D Oh i see, so like you could have an Array of type class Car, but inside have different subclasses but with super-class being Car?
Sadeq You got it. it's very common to have one data structure, like an ArrayList, full of different stuff. Technically you could always just declare things as objects, but to your original point it's better to be as close as possible to the actual object so you can use the locally defined methods.
This was very clear. But I still have a question: What if only class Student has a method test1(Student x). Now I call test1(q). Since you said, that I get the test1() method from class Person, what happens when there is no such method in class Person only in class Student?
Great question! If there is no such method as: test1(Person x){ System.out.println("'Ello Govn'r"); } then a call to test1(q) will generate a COMPILE time error. As far as the compiler is concerned test1( ) can only be called with Student objects and since q is referenced as a Person object the compiler will through a type mismatch error even though at RUNTIME q would be treated like a Student because that is how it is instantiated. Think of it this time. Suppose I taught you how to put down the roof of a convertible car. That would be like writing a method takeOffRoof(Convertible c){...}. Now, if I told you "put down the roof on that CAR" you'd probably assume the car is ACTUALLY a convertible, because if it were not you wouldn't be able to put down the roof. A compiler cannot make that assumption though so if I wrote the code: Car c = new Convertible( ); takeOffRoof( c ); I will get an error at compile time because the compiler can't find a method that knows how to take off the roof of Car objects. The following code, however would work: Convertible c = new Convertible( ); takeOffRoof( c );
well, I mean great presentation, except you didn't tell us which one is which.. I had to go watch another video to actually know which one is static and which is dynamic. Nevertheless, a good explanation without the actual labeling of ur explanation.
I watched this video a couple of times when I needed to learn these for exams 8 years ago. Interestingly, last night the intro, "hey... sup" and "ello govn'r" expressions came to my mind. I had forgot your name sir, but I was remembering the video. Now I am here. Thanks for the lessons Mr. Quinn.
I love how good teachers try to get creative so students can pay attention. I know some of you don't see the relationship this teacher is trying to establish, but I do. Yo, yo, yo! That's a cool teacher!
Thanks so much, I really appreciate your comment!
I love how your sense of humor into the lesson.
This is an excellent explanation. Much better than my textbook.
Thank you, glad it helped!
My first thought: "oh, no! he's trying to be funny."
My final though: "I understood. Thanks!"
Kudos on making it through to the end! I hope I didn't lose too many people in the first few minutes.
It is refreshing to see someone teaching java development that isn't a complete square. Good job.
Ben Morris-Rains Thank you! I'm glad that the explanation makes some sense!
I had the same thought, but he got me at:
hey, sup!
This is great. Very clear to understand. Thank you very much.
that intro is an instant thumbs up
creative intro lol :D
come to india
we want a teachers like u
Thank you for the invitation! I don't know if I could handle moving away from family, but if you are serious perhaps there are ways to partner remotely. I think it would be incredible to teach a multinational course through the internet!
thanks mate a humorous insight into dynamic binding.
never really caused me an issue in real wold programming but need it for an exam eh :)
Thank you very much for the great explanation. I found it enjoyable to watch!
Kake Toeter thank you!
I loved the intro.
So static binding happens during compile time. Meaning in the main, test 1(q) will link back to Person q which will link to test 1 (Person x) {print (“Ello….”);}// It will print out “Ello Govenor”
Dynamic binding happens during runtime (late binding). Meaning if we do “q.talk();” in the main method, it will then reference “q” as new student which will then link to the Student’s talk.
Does it sound like I understand the differences between the two bindings?
You got it! Compile time cares about the reference type and runtime cares about the instance type.
Which of those two is static and dynamic binding?
The one with q.talk() is dynamic.
And the one with Test1(q) is static.
Did I get it right?
You got it! q.talk() is dynamic because at compile time the computer checks q's type (Person) and sees that it is ABLE to talk but at runtime when the command get executed the instance that q is pointing to (a Student) runs the code with its associated talk method.
in the example Test1(q) there is a decision made at compile time to run one of two Test1 methods: the one that uses a Person or the one that uses a Student. Since q is a Person (by reference) the Test1 method that uses a person is chosen and is now statically bound. When you go to run the program it doesn't matter that q is ACTUALLY a Student because the decision to execute the Test1 method for a person had already been made at compile time.
Kevin Quinn Thanks for the explanation. Really helpful. Hope to see some more great stuff from you...
@@sharifsircar my pleasure! Stay safe as well!
@@sharifsircar ha, no worries. I try to stay on top of comments and respond ASAP. Regardless, I appreciate the kind thoughts. We are one united world in this crisis.
nice explanation thank you !
My pleasure, glad you found it helpful
definitely not boring 😄 thanks..it was helpful
Glad you found it helpful AND not boring. Thanks!
Thanks for the effort
My pleasure!
That was very helpful, thank you sir!
this was really helpful, thank you
Glad to hear, thanks!
Very well done, liked and subscribed!
i just have one question tho, how would i know the methods that get invoked in the compile or the run ( i didn't understand this point) is it like every method that takes parameter will look at the dynamic type of the object ?
The determining factor is whether you are looking at the REFERENCE or the INSTANCE. At compile time you only look at references. If we said "print( joe )" we are talking about the reference called joe. Suppose there are two print methods, one that takes a Person parameter and one that takes a Student parameter, the compiler chooses which one to run based on the type of REFERENCE joe is. Even if we had "Person joe = new Student()" at compile time joe is treated like a Person so the print methods that takes a Person is called. However, let's say in that method it said something like "joe.talk()". Since we are now de-referencing joe we are looking at what joe actually IS. Since he is an INSTANCE of Student that version of the talk method would be called.
The best way to figure this stuff out is to make a sample program with lots of overloaded and overwritten methods. In each one simply put a print statement that says what method you are in. Then try different versions or calling methods with multiple combinations of references and you'll start to see the patterns emerge.
Hope this helped clarify!
+Kevin Quinn Many thanks sir! very well explained!
Thanks for the video! good and clear explanation!
my pleasure!
Thank you !! Helped a lot :D
Hey Sup!!
Great teaching.
Thanks professor!
My pleasure!
Liked and Subscribed. Thank You.
I am going to share this
Please do!
@@MrQuinnPhysics I shared it
@@nileshdivekar3127 Great, thanks!
@@MrQuinnPhysics god bless you
Sir with more subscribers
Awesome...want more on abstraction
Muchas gracias Kevin :)
De nada!
r/fellowkids to the "hey, sup?"
nah but seriously, great explanation!
Thanks! I don't mind making a fool of myself if it will help get the point across
Epic intro :D
thank you
I clicked a timestamp and I realized that I skipped the interesting intro after reading comments.
Glad that you went back and got to see the intro!
Hey, Sup
Great video :D
Thank you!
Intro is very funny...surprising kinds of👌
What I don't really understand is during run-time why the program can't see that person q is actually a student in this line: test1(q) and why it can see it when we're doing q.talk()
Olof Enström In both cases test1(q) and q.talk() at compile time the program is ONLY checking to make sure the declared type can do what you are asking (static binding). However, with test1(q) there are overloaded methods. The compiler ALSO turns your computer code into specific instructions to be followed, one of those instructions being which version of the overloaded method to run. Since the compiler is only looking at the declared type and not the instantiated type q appears to be a person so the corresponding test1() method call is made. By runtime the instruction to run that version of the method gets executed. The funny thing is that if q is asked to do something like q.talk() that instruction is executed by the instance, in this case a student. Hope that clarifies, sorry for the delayed response!
very good bro...
Where are you from sir
Hello Anjan, I am from Pennsylvania, USA
He should have described those last method parts as interface types. Go language does this.
hey, sup
nice video!
🤩🤩🤩
Spot on - I thought it was funny lol
hey , sub !!
you rock :D !
So then why can't we just use the line of *Student q = new Student* intstead of using *Person q = new Student*, so that we don't have to deal with that problem you mentioned at the end, with the Test1(q) method.
Btw thank you for the video! I have an oop quiz tmrw afternoon :/
You can! This is really a question about "polymorphism", meaning that you can refer to an object many different ways. Sometimes it is inconvenient but other times it can be a huge help. Imagine for example a car dealership that wants to keep track of its inventory. You might do so with an ArrayList of type Car. However Car is more general than FordTaurus, FordF150, and FordFiesta. Each of these specific types of cars might have special methods but it is way more convenient to treat them all like Car objects so they can be in one list.
At a school you might have a similar example where you keep a list of Person objects, but in that list you may have Student, Teacher, and Parent objects. There could be an advantage to one vs three lists. That is a design decision, but you need to understand the technical implications in order to make a good decision.
Hope that clarifies!
Wow thanks for responding! Esp before my test tmrw! :D
Oh i see, so like you could have an Array of type class Car, but inside have different subclasses but with super-class being Car?
Sadeq You got it. it's very common to have one data structure, like an ArrayList, full of different stuff. Technically you could always just declare things as objects, but to your original point it's better to be as close as possible to the actual object so you can use the locally defined methods.
Thank you! :)
This was very clear. But I still have a question:
What if only class Student has a method test1(Student x). Now I call test1(q). Since you said, that I get the test1() method from class Person, what happens when there is no such method in class Person only in class Student?
Great question! If there is no such method as: test1(Person x){ System.out.println("'Ello Govn'r"); } then a call to test1(q) will generate a COMPILE time error. As far as the compiler is concerned test1( ) can only be called with Student objects and since q is referenced as a Person object the compiler will through a type mismatch error even though at RUNTIME q would be treated like a Student because that is how it is instantiated.
Think of it this time. Suppose I taught you how to put down the roof of a convertible car. That would be like writing a method takeOffRoof(Convertible c){...}. Now, if I told you "put down the roof on that CAR" you'd probably assume the car is ACTUALLY a convertible, because if it were not you wouldn't be able to put down the roof. A compiler cannot make that assumption though so if I wrote the code:
Car c = new Convertible( );
takeOffRoof( c );
I will get an error at compile time because the compiler can't find a method that knows how to take off the roof of Car objects. The following code, however would work:
Convertible c = new Convertible( );
takeOffRoof( c );
well, I mean great presentation, except you didn't tell us which one is which.. I had to go watch another video to actually know which one is static and which is dynamic. Nevertheless, a good explanation without the actual labeling of ur explanation.
Hey sup
Hey sup
Hey, sup?
Hey, sup?
Marry me!
Sup