In practice, most code is very abstract, so identifying the proper 'things' that should make up your code isn't easy (and arguably a fool's game). I would just write the code as straight procedural code, then see if you can logically group stuff into classes one at a time. The biggest thing to keep in mind is to be careful about using inheritance. In fact, you shouldn't feel obligated to use inheritance at all.
I'm trying to learn to work with classes and this is exactly the answer to the question I had in mind. I've tried for days to find the answer but nobody really seemed to ever talk about how you start writing in an object oriented way. Thank you!
@@bpaudel2239 Thats is where Design Patterns come into play, instead of inventing something new or reinventing the wheel, just copy existing designs and fix what does not work for your project on go. Does not really mean that you need to read and understand books before starting to code, just look at existing codes and repeat their approach. This is how juniors do when joining projects with OOP language tech-stack.
Just write it as it should be, then think what needs to be modified as required by style/policy. I add one more step which is inversion of control so that I can isolate the responsibilities of a specific module. I may be doing things wrong. I'll have to reevaluate. Thanks
My favourite part of OOP-esque approaches is using mixins / multiple inheritance. Specifically to have mixins that provide a fully self-contained set of functionality, such that those mixins can be sprinkled into other classes later. Programming starts to feel like cooking, with mixins providing convenient bits of spice and flavour that gets you where you need to be.
Can I just say your presentation is brilliant I love the fact that you avoid using some of the typical terminology that others use and take time to explain what you have said , others on here try to wrap everything in once sentence and it is terribly confusing.
I really like your concise definition of object oriented programming. Something my OOP Professor failed to impart over an entire course, you delivered in 2:24.
My final year of comp-sci in highschool was 1993, and the main thrust was C. However I'd written a bunch of games and utilities in Qbasic on my own but owing to the limitations of arrays having to be generally of a pre-defined size, no local variables, etc., I'd begun to rewrite these in turbo-pascal. TP had the ability to define classes and use objects but at that time no course at high school nor my own research into basic, Qbasic, or C had ever come across them, my implementations stayed strictly procedural. In TP, defining linked (or doubly-linked) lists of records provided more than enough flexibility in terms of size and 'groupability' in terms of data for anything I'd previously written to be vastly improved in the ports over from Qbasic. Simply paying close attention to any possible accidental side effects meant I simply had to pass pointers to a record which needed to be updated avoiding unnecessary duplication of data. At a time when a 1G hard drive was a rarity and a 486 was fast, well this speed things up dramatically. Doubly linking lists made it unnecessary to run through the entire list from the head node to find a parent item. In fact I often kept lists in loops where tail pointed to head directly removing the constant need to check for the tail case: perhaps dangerous in that infinite loops might occur, but with careful logic these could be avoided and the increase in performance was marked on slow machines. "Inheritance" could be achieved by having a field of one record be the type of a different record. If many sprites needed the same graphics (multiple instances of monsters) a loop of the frames of the sprite's graphics stored in a looped linked list could be pointed to from a pointer stored in a field of the monster's record, eliminating storing multiple copies of the same bitmaps. Memory was at a premium after all! Perhaps I'm old-school, but I don't see any advantage to OO over an approach like this. It seems unnecessarily complicated and resource intensive, particularly for single thread, single programmer projects... I'm sure many people will argue the opposite but records, pointers, and linked lists are group able, flexible, and require no copy when passed to functions and procedures as long as you take care of your logic when changing values of fields to not produce unwanted side effects: good practice anyways, no?
Wow, seems interesting, even if I barely understand the technicality of your approach, being a rookie in C programming, do you have a blog or something where you can elaborate a bit more on this approach?
First year in cs so correct me if I'm wrong but dont you run into serious scalability problems with this concept? Sure everything works but its time consuming and very costly if you have even a single error in logic at any point. My current understanding is that OOP is the fundamental concept that your program should work whether it's being used for one thing or a million and it should do it in the most efficient manner
@@KlassickG I'm not sure that relying on OOP to safeguard against errors in logic is better than testing to ensure correct logic in the first place. Also, functions and procedures can be tested just as well as the methods of any object. So scalability aside, I don't see that testing one's own code is problematic. Now, scaling up, provided documentation (comments ) and code are clear to begin with I imagine it shouldn't be too rough to ensure code remains free of unwanted side-effects . The biggest worry might be choosing a variable name to use locally, and accidentally misspelling it to match a global variable... That'd be hard to catch for sure, but with good naming conventions agreed to it seems unlikely... But then again, I've never worked on a large scale, multi programmer project. And these days efficiency less and less of a consideration as bandwidth, RAM, processor speed etc keep improving. But still, there's something beautiful about concise clean code...
@@zikomo8913 I don't have a blog, sorry, and my C is suuuper rusty, but if memory serves C has pointers, yes? A linked list item in simplest form is made of a piece of data (could be a variable, an array, a record, a boolean variable, whatever) and a pointer pointing to the next item in the list. The final item points to 'null' or itself if you want a loop. The first item sometimes has a special pointer called 'head' pointing to it, but if the list is circular it isn't necessary as long as you have a pointer pointing somewhere on your list. You can read and write data to the data field of the item your index pointer points to, then set your index to point to it's item's 'next' item, thus iterating over (around) your list. You can insert or delete items, cut lists into sub-lists, etc. But you never have to make a copy of your list just to, say, pass it to a function, so for any sort of recursion it saves mucho memory. I don't know if that's clear at all: there are far better/smarter folks out there who could likely give you a way better explanation. But hope that makes it a little clearer.
Nowadays especially, linked lists (especially doubly linked) are going to result in big performance hits compared to array lists in most cases. Linked lists are slower at random access, but their biggest issues are ones of space: they add 4-16 extra bytes to each item and aren't laid out contiguously, so they lead to terrible caching problems (I think there's actually a video on this channel that mentions this). I'd argue that OOP has the advantage of syntactic sugar - I actually think it's a good enough syntactic sugar that it's a legitimate advantage. If it's used right, it's also going to help you avoid spaghetti code; it's used poorly often enough that I don't really think that one counts.
Thankyou, after watching this video I feel like I understand not just what OOP is, but also why I would want to use it. Some of the other videos I'd seen covered the same topics but left me scratching my head about what it all actually means.
Not sure why people care about your tone of voice. If you were here to learn you would be paying attention to what he is teaching. Not debating how he sounds. He is to the point, clear, and understandable. Fantastic refresher video for those who have been out of the OOP game for awhile.
Loved this "tutorial" :) even though it has been a year since I started with functional programming and I am probably never going back to OOP (FP is simple and I'd like to keep it that way). It was nice to see a well-explained concept in programming
I think that James Coplien came with valid critique when he highlighted the focus on classes instead of interacting objects within a use case. Most software developers don’t seem to get OOP, sure they write classes - “Service” classes are far too common. They use DI and so. But they don’t model objects from the real-world. They would rather separate behavior from data in some pseudo-procedural module style.
Yes and no, imperative and procedural are sometimes considered synonyms, but they really describe different concepts all together. Imperative languages is a list of statements which is executed in the order they are written (as opposite descriptions of the result without any detailed specifics of how to reach it). Procedural languages are languages with procedures (aka. functions). In fact many object oriented languages are also imperative but not as commonly procedural.
Most OO classes I've seen start with too much Software Engineering right up front. For a beginner I think your approach works much better. Just code and see what patterns show up, then abstract over them. As you get used to it, you'll have a much easier time modeling before coding.
Ignore the haters, been looking through videos to strengthen the knowledge on OOP and your video is by far the best, clear explanations, understandable examples and most importantly proper english, all these indian accents are hella annoying lol, subbed
Read clean code by uncle Bob, and you'll see that Brian is not very good at programming. OOP is one of the best ways to structure your code. His alternatives seem so messy to me.
I thought that you did a very good job of explaining the core concepts of object-oriented programming. You provided deep analysis of the different core concepts and used examples and simple language that everyone could understand. I do think that the video could be enhanced through the uses of more metaphors and diagrams. These visuals aids allow different types of learners to engage better in the material. Also, you could try breaking the video up into smaller segments, as it is often hard for a learner to engage for 30 minutes straight. By creating smaller sub videos, it would allow both a single leaner to take breaks and finish up when they are more engaged, and also allow people to watch specific sections if that is the area in which they need help.
Thanks for the very helpful video! I know it's old, but I'd like to add one language specific detail: You said that "classmethod" and "static method" are the same thing. I don't know much about the other languages, but in python they aren't. Classmethods get the class itself passed in as an argument automatically, so the classfields can be accessed through that passed class within the classmethod, but static methods are really just functions within the namespaces of classes.
C++ and it's template deduction is nice because I don't have to pinky promise what I pass in to a for each loop has a pre increment and a deference, it'll just work if Ive actually defined those for what I pass in (and if it doesn't I'll get the world's longest error telling me about every iterator that exists)
I would say Lua is another language of note that uses prototypical inheritance. In fact, I find these dynamic languages with prototypical inheritance somewhat better for doing OOP, becasue they are more flexible.
Thank you so much! 5 years of programming, and I never understood polymorphism. Once you explained overriding - something else I never understood; but to be fair I never tried to understand it - polymorphism made since. I still don't get encapsulation, though. And I learned that an abstract class *is* an interface - at least in Java. So, what exactly is the difference between the two?
If you look at the word encapsulation, it's made from the word capsule. To encapsulate something, is (more or less) to put it in a capsule. To enclose it in some logical collection, with some amount of protection.. protection of the things inside from the things outside. You don't want the outside things messing with, or getting mixed up with, the inside things. In java you have public, protected and private 'things' in a class. When you define a class, you make the capsule. When you declare fields or methods as public, protected or private, you are defining a level of protection, or what level of access outside things have to the inside things, or indeed what access inherited classes have to parent class fields or methods. (like poking a small hole in the wall of the capsule) Encapsulation is more of a concept for you to use when understanding how objects interact with other objects, rather than a functional part of the code.
About class which have one parent, it's not only Python and Java and in Objective-C the same - NSObject is a parent of all classes that you will create
This is perfect. I was making an animal simulator in Unity that is text based and writes to the console using Debug.Log and players can input into a text field in a serialized object. I have found a use case then for standard OOP design patterns. Next a car simulator. I was thinking of a Person class and derived from it a Male and Female, but then I have over-engineered my solution to require a generic List
I go over this a bit in my video on programming languages. The two distinctions I prefer are imperative vs functional and procedural vs object-oriented. The procedural vs object-oriented distinction is a matter of emphasis on actions vs. data. In the imperative vs. functional distinction, imperative code modifies state freely while functional code attempts to minimize state change.
I'm not as knowledgeable as the guy in this video, I'm a novice and studying to become an engineer BUT I have to say at 4:50, at least in Java, it IS true that the executions within methods are by default not varying like new instances of field/variables, however a method can be overrided, which basically let's you retweak the executions in a method.
Object-Oriented Programming doesn't begin with data, it begins with types. It's all about classifying and relating things into some hierarchical world-view, under the assumption that it will let you create reusable components. In actuality, this results in an extremely rigid framework that is impermeable to change, and thus leads to even less code reuse as even minor revisions cause enormous code ripples. Sure, OOP is good for modeling, but for programming, it's a nightmare that generates far more work than necessary. What programmers really want is dynamic and mutable typing. But they won't say that because it's taboo and evil for reasons that no one can sensibly explain (ego, bureaucracy, lack of preoptimization (aka. static compilation and manual memory management), the misguided belief that static typing magically eliminates some huge class of common bugs that no one can actually list, being too lazy to use a debugger or write unit tests yet not too lazy to complain about the reasons why they exist, etc.)
So you have no clue about all the best practices for OOP programing? And dynamic typing is cancer. It shifts a huge number of compilation errors to runtime, making it harder to detect errors. It's convenient occasionally, sure... But like don't.
@@jasonapril4868 Basically what he does, is strips down the code to it's very basics, which may seem shorter, and easier to understand, but on the long run that'll be cancer to maintain.
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." -- Fred Brooks (Flowcharts being functions, and tables being data-structures). I don't know who Fred Brooks is but I read this quote in the book *The practice of programming* by Brian Kernigan (long live Brian Kernigan) and Rob Pike.
Class inheritance has been useful to me so seldom that I almost forget it's possible. Seems like most problems involve similar but really different types of data so that parent classes add only complexity and generic programming is a better solution.
This video has to be one of the most useful for explaining this topic! I would only say that some more detailed animations and illustrations would have been even more helpful.
This is one important video for people like me who are coming back to OOP after almost 4 years or more. It is a good revision of the concepts and quite concise. Now I can move to the programming part knowing I have covered the basics properly.
A computer teaching me about computers, the optimum demonstration of self awareness. This will lead to a new epoch of bio-mechanical peace and understanding. JK JK. As per eush, thanks for the most excellent, free information.
It's because the death star is *under construction* . That image was from when the death star was not yet finished being built. *random side-note:* One problem with the way OOP programming conceptualizes the concept of construction is that it gives you the false impression that there only can be one centralized way of building an object. In reality, you could have multiple functions for constructing the same object (even with the same data type signature) if you made the constructors be global functions external to the class. Thus, for example, in a more procedural style you could have both something like "TypeX MakeObjectOfTypeX_CartesianCoordinates(float, float)" and "TypeX MakeObjectOfTypeX_PolarCoordinates(float, float)" and both would simply be global functions that return a constructed instance of the object of TypeX (i.e. constructors are just functions that return filled out instances of the underlying data structure). In other words, constructors aren't actually special on any kind of fundamental level. OOP constructors don't allow you to do this because you can't overload a function name with two functions that have the same type signatures (e.g. "float, float" here). Under the hood, constructors are actually implemented as just global functions whose return type is a struct of the same data type as the object's fields gathered together and placed in a plain struct. Also, "methods" in OOP are also actually essentially nothing more than global functions in disguise whose first input parameter is a pointer to an object of that type named "this" which is implicitly used whenever you refer to the instance's member variables. In other words, to an extent, OOP actually obscures the syntax of what is actually going on and makes it less general from a notation standpoint. However, it does implement a "v-table" (which is how polymorphism is implemented under the hood) to enable inheritance and that is the only real fundamental difference between global procedural functions and OOP methods once you truly understand what is going on under the hood.
It's rarely known upfront how inheritance will work in complex system. Interfaces are more flexible and ultimately more useful concept. They also providing convenient bridge to functional programming.
You know, and object is not a data type. It is a container of data and logic. And an object can contain no data. I have been listening this debate againt OOP now for long enough and I come to the realization that alot of misinformation is being said. Object Oriented programming is not bad. Inheritance is aso not bad. What is bad is misusing OOP and misusing inheritance.
THank you .. Students who need a real-life example for object oriented design can download that report here: www.objectorienteddesign.org I have shared my personal experience of a software project that I completed for one of my client.
Great video... I'm a JavaScript developer and lately have been working with a lot of Java and C# code bases. Your video detailed it out for me easily to start understanding project structure. Thanks!
At 16:11, you say 'any class that you create is going to be ancestor of object', I guess you should say it other way around, I.e Object class is the ancestor of any class you create. Please correct me if I'm wrong.
*My first year programming lecturers, first class of the year* Okay so heres OOP *Me, never done programming before* yeeeeeees I have no idea whats going on.
This is the most clear explanation I've ever seen.
Please don't quit. This channel has been a gem!
Just when the world needed him the most... he wasn't there
I learned from this video that I have been performing spaghetti-oriented programming.
DrHokeyPokey Pasghetti
+naiveyuu lol
LOL
Better that than no programming! Glad you're learning :)
oh dear.... kinda thought of the same thing to comment :O
In practice, most code is very abstract, so identifying the proper 'things' that should make up your code isn't easy (and arguably a fool's game). I would just write the code as straight procedural code, then see if you can logically group stuff into classes one at a time. The biggest thing to keep in mind is to be careful about using inheritance. In fact, you shouldn't feel obligated to use inheritance at all.
I'm trying to learn to work with classes and this is exactly the answer to the question I had in mind. I've tried for days to find the answer but nobody really seemed to ever talk about how you start writing in an object oriented way. Thank you!
@@bpaudel2239 Thats is where Design Patterns come into play, instead of inventing something new or reinventing the wheel, just copy existing designs and fix what does not work for your project on go. Does not really mean that you need to read and understand books before starting to code, just look at existing codes and repeat their approach. This is how juniors do when joining projects with OOP language tech-stack.
@@lex-fridman thank you! Your comment also helps me a lot!
Just write it as it should be, then think what needs to be modified as required by style/policy.
I add one more step which is inversion of control so that I can isolate the responsibilities of a specific module. I may be doing things wrong. I'll have to reevaluate.
Thanks
"A Car is not a kind of steeringwheel", wise words.
Except a steering wheel is attached to a car.
@@ccgb92 What about cars that do not have a steering wheel?
@@killistan It has an engine, wheels and it moves, but no steering wheel? Then it's obviously a motorcycle.
@@mattias7407 Or a hoverboard.
@@mattias7407 or a train
00:00 - Definition
05:00 - encapsulation
07:45 - inheritance
12:35 - inheritance usage guide
14:05 - multiple inheritance
16:32 - overriding inheritance
18:55 - polymorphism
22:00 - constructors
22:48 - interface
25:15 - abstract class
26:25 - prototypical inheritance
Yours is the first straight forward explanation of when an interface is used. Thank you.
Yes, experience makes it easier, and in time you pick up on conventions, like when to make factories, managers, singletons, and so forth.
My favourite part of OOP-esque approaches is using mixins / multiple inheritance. Specifically to have mixins that provide a fully self-contained set of functionality, such that those mixins can be sprinkled into other classes later. Programming starts to feel like cooking, with mixins providing convenient bits of spice and flavour that gets you where you need to be.
Can I just say your presentation is brilliant I love the fact that you avoid using some of the typical terminology that others use and take time to explain what you have said , others on here try to wrap everything in once sentence and it is terribly confusing.
I really like your concise definition of object oriented programming. Something my OOP Professor failed to impart over an entire course, you delivered in 2:24.
This provided a GREAT crash course for a job interview, my coding is a bit rusty, but this was straight forward and legit. Thanks a lot!
prolly the best explanation of the topic i have ever seen
My final year of comp-sci in highschool was 1993, and the main thrust was C. However I'd written a bunch of games and utilities in Qbasic on my own but owing to the limitations of arrays having to be generally of a pre-defined size, no local variables, etc., I'd begun to rewrite these in turbo-pascal. TP had the ability to define classes and use objects but at that time no course at high school nor my own research into basic, Qbasic, or C had ever come across them, my implementations stayed strictly procedural. In TP, defining linked (or doubly-linked) lists of records provided more than enough flexibility in terms of size and 'groupability' in terms of data for anything I'd previously written to be vastly improved in the ports over from Qbasic. Simply paying close attention to any possible accidental side effects meant I simply had to pass pointers to a record which needed to be updated avoiding unnecessary duplication of data. At a time when a 1G hard drive was a rarity and a 486 was fast, well this speed things up dramatically. Doubly linking lists made it unnecessary to run through the entire list from the head node to find a parent item. In fact I often kept lists in loops where tail pointed to head directly removing the constant need to check for the tail case: perhaps dangerous in that infinite loops might occur, but with careful logic these could be avoided and the increase in performance was marked on slow machines. "Inheritance" could be achieved by having a field of one record be the type of a different record. If many sprites needed the same graphics (multiple instances of monsters) a loop of the frames of the sprite's graphics stored in a looped linked list could be pointed to from a pointer stored in a field of the monster's record, eliminating storing multiple copies of the same bitmaps. Memory was at a premium after all!
Perhaps I'm old-school, but I don't see any advantage to OO over an approach like this. It seems unnecessarily complicated and resource intensive, particularly for single thread, single programmer projects... I'm sure many people will argue the opposite but records, pointers, and linked lists are group able, flexible, and require no copy when passed to functions and procedures as long as you take care of your logic when changing values of fields to not produce unwanted side effects: good practice anyways, no?
Wow, seems interesting, even if I barely understand the technicality of your approach, being a rookie in C programming, do you have a blog or something where you can elaborate a bit more on this approach?
First year in cs so correct me if I'm wrong but dont you run into serious scalability problems with this concept? Sure everything works but its time consuming and very costly if you have even a single error in logic at any point. My current understanding is that OOP is the fundamental concept that your program should work whether it's being used for one thing or a million and it should do it in the most efficient manner
@@KlassickG I'm not sure that relying on OOP to safeguard against errors in logic is better than testing to ensure correct logic in the first place. Also, functions and procedures can be tested just as well as the methods of any object. So scalability aside, I don't see that testing one's own code is problematic. Now, scaling up, provided documentation (comments ) and code are clear to begin with I imagine it shouldn't be too rough to ensure code remains free of unwanted side-effects . The biggest worry might be choosing a variable name to use locally, and accidentally misspelling it to match a global variable... That'd be hard to catch for sure, but with good naming conventions agreed to it seems unlikely... But then again, I've never worked on a large scale, multi programmer project. And these days efficiency less and less of a consideration as bandwidth, RAM, processor speed etc keep improving.
But still, there's something beautiful about concise clean code...
@@zikomo8913 I don't have a blog, sorry, and my C is suuuper rusty, but if memory serves C has pointers, yes? A linked list item in simplest form is made of a piece of data (could be a variable, an array, a record, a boolean variable, whatever) and a pointer pointing to the next item in the list. The final item points to 'null' or itself if you want a loop. The first item sometimes has a special pointer called 'head' pointing to it, but if the list is circular it isn't necessary as long as you have a pointer pointing somewhere on your list. You can read and write data to the data field of the item your index pointer points to, then set your index to point to it's item's 'next' item, thus iterating over (around) your list. You can insert or delete items, cut lists into sub-lists, etc. But you never have to make a copy of your list just to, say, pass it to a function, so for any sort of recursion it saves mucho memory.
I don't know if that's clear at all: there are far better/smarter folks out there who could likely give you a way better explanation. But hope that makes it a little clearer.
Nowadays especially, linked lists (especially doubly linked) are going to result in big performance hits compared to array lists in most cases. Linked lists are slower at random access, but their biggest issues are ones of space: they add 4-16 extra bytes to each item and aren't laid out contiguously, so they lead to terrible caching problems (I think there's actually a video on this channel that mentions this).
I'd argue that OOP has the advantage of syntactic sugar - I actually think it's a good enough syntactic sugar that it's a legitimate advantage. If it's used right, it's also going to help you avoid spaghetti code; it's used poorly often enough that I don't really think that one counts.
9 years later, this video is still relevant! 🔥
3 years after this video he released "Object-Oriented Programming is Bad" video.
Thankyou, after watching this video I feel like I understand not just what OOP is, but also why I would want to use it. Some of the other videos I'd seen covered the same topics but left me scratching my head about what it all actually means.
Not sure why people care about your tone of voice. If you were here to learn you would be paying attention to what he is teaching. Not debating how he sounds. He is to the point, clear, and understandable. Fantastic refresher video for those who have been out of the OOP game for awhile.
Right? His voice is not a annoying, high pitch poorly recorded voice at least. This is easy to listen to.
Jordan Moorman
He’s montonic
This feels like the villain origin story
thanks and I prefer your monotone rather than pure marketing Blasie like tone.
TIMESTAMPS:
00.00-- Definition
05.00 - encapsulation
07.45 - inheritance
12.35 - inheritance usage guide
14.05 - multiple inheritance
16.32 - overriding inheritance
18.55 - polymorphism
22.00 - constructors
22.48 - interface
25.15 - abstract class
26.25 - prototypical inheritance
Design patterns book
Great video. Voice is not monotone, is calm a explaining it in a very soft way. I like it!
"My cat has 7 lives left, yours has 5." is this a threat.
lol
Loved this "tutorial" :) even though it has been a year since I started with functional programming and I am probably never going back to OOP (FP is simple and I'd like to keep it that way). It was nice to see a well-explained concept in programming
Excellent work , ur explanation is clear and precise ,pls keep on uploading new vedios .I really appreciate ur work & looking forward to learn more .
He sounds a bit like the usual voice they use for Bruce Wayne. XD
Awesome! The video itself was quite informative and very easy to understand.
STER Gaming sweet so Batman is teaching me CS
Handsome voice lol sounds manly
+STER Gaming Also sounds like Roy Mustang
+STER Gaming Sounds like Charlie the unicorn :p
Neil Peart! When the video first started, I thought it was Neil Peart! Awesome!
Just wanted to say that these explanations are spot-on, straight to the point, and very easy to understand. Great video. Thanks!
Nice video. I remember this being explained overly complicated back in my student days.
You keep it simple.
That was a very good lecture, Brian. Thoroughly enjoyed watching it and I will be watching it for reference in future. Thank you.
I think that James Coplien came with valid critique when he highlighted the focus on classes instead of interacting objects within a use case.
Most software developers don’t seem to get OOP, sure they write classes - “Service” classes are far too common. They use DI and so. But they don’t model objects from the real-world. They would rather separate behavior from data in some pseudo-procedural module style.
That's not developers getting OOP wrong, that's just OOP as it was intended
I am a molecular biology student trying to learn programming and this video skull fucked me into another dimension.
wow that memory part and the method only being stored once is important to know!! Thanks
Best explanation I've ever encounter... I found myself hoping that there was a lot more time left so that I could learn more....ty
Yes and no, imperative and procedural are sometimes considered synonyms, but they really describe different concepts all together. Imperative languages is a list of statements which is executed in the order they are written (as opposite descriptions of the result without any detailed specifics of how to reach it). Procedural languages are languages with procedures (aka. functions). In fact many object oriented languages are also imperative but not as commonly procedural.
I'm lost in my AP comp sci class. This video is so helpful, thank you.
2:30 "...create a class to represent a cat...a number for its age, or remaining lives."
I died.
+Brandon G XD brilliant
A little bit of programmers humor ... 🤣🤣 ... nice video
Most OO classes I've seen start with too much Software Engineering right up front. For a beginner I think your approach works much better. Just code and see what patterns show up, then abstract over them. As you get used to it, you'll have a much easier time modeling before coding.
I needed a review for an interview, this worked great. Thanks!
Ignore the haters, been looking through videos to strengthen the knowledge on OOP and your video is by far the best, clear explanations, understandable examples and most importantly proper english, all these indian accents are hella annoying lol, subbed
Read clean code by uncle Bob, and you'll see that Brian is not very good at programming. OOP is one of the best ways to structure your code. His alternatives seem so messy to me.
I thought that you did a very good job of explaining the core concepts of object-oriented programming. You provided deep analysis of the different core concepts and used examples and simple language that everyone could understand. I do think that the video could be enhanced through the uses of more metaphors and diagrams. These visuals aids allow different types of learners to engage better in the material. Also, you could try breaking the video up into smaller segments, as it is often hard for a learner to engage for 30 minutes straight. By creating smaller sub videos, it would allow both a single leaner to take breaks and finish up when they are more engaged, and also allow people to watch specific sections if that is the area in which they need help.
jesus christ are you really so lazy that you can't even be bothered to hit the pause key?
I was feeling like a kid in bed while listening a tale, a very good one of course! great video thanks!
Thanks for the very helpful video!
I know it's old, but I'd like to add one language specific detail:
You said that "classmethod" and "static method" are the same thing. I don't know much about the other languages, but in python they aren't. Classmethods get the class itself passed in as an argument automatically, so the classfields can be accessed through that passed class within the classmethod, but static methods are really just functions within the namespaces of classes.
Thank you for putting your knowledge on the internet for free.
Check out this vid if you'd like to broaden your base.
ua-cam.com/video/iGtBVeqYQKY/v-deo.html
Neo: Morpheus?
Neo: I thought it wasn't real.
Morpheus: Your mind makes it real.
C++ and it's template deduction is nice because I don't have to pinky promise what I pass in to a for each loop has a pre increment and a deference, it'll just work if Ive actually defined those for what I pass in (and if it doesn't I'll get the world's longest error telling me about every iterator that exists)
If you manage to deal with the monotony of his voice, this tutorial is a god damn BEAST. Be patient in the beggining and it will be worth. Thank you.
I would say Lua is another language of note that uses prototypical inheritance. In fact, I find these dynamic languages with prototypical inheritance somewhat better for doing OOP, becasue they are more flexible.
Thank you so much! 5 years of programming, and I never understood polymorphism. Once you explained overriding - something else I never understood; but to be fair I never tried to understand it - polymorphism made since. I still don't get encapsulation, though. And I learned that an abstract class *is* an interface - at least in Java. So, what exactly is the difference between the two?
If you look at the word encapsulation, it's made from the word capsule. To encapsulate something, is (more or less) to put it in a capsule. To enclose it in some logical collection, with some amount of protection.. protection of the things inside from the things outside. You don't want the outside things messing with, or getting mixed up with, the inside things.
In java you have public, protected and private 'things' in a class. When you define a class, you make the capsule. When you declare fields or methods as public, protected or private, you are defining a level of protection, or what level of access outside things have to the inside things, or indeed what access inherited classes have to parent class fields or methods. (like poking a small hole in the wall of the capsule)
Encapsulation is more of a concept for you to use when understanding how objects interact with other objects, rather than a functional part of the code.
That moment you explained what is an Interface is just blown my mind !! Thanks a heap. :)
About class which have one parent, it's not only Python and Java and in Objective-C the same - NSObject is a parent of all classes that you will create
Respect , this is the best OOP explanation in all net , even java creators couldnt explain that shit like you did
This is perfect. I was making an animal simulator in Unity that is text based and writes to the console using Debug.Log and players can input into a text field in a serialized object. I have found a use case then for standard OOP design patterns. Next a car simulator. I was thinking of a Person class and derived from it a Male and Female, but then I have over-engineered my solution to require a generic List
I go over this a bit in my video on programming languages. The two distinctions I prefer are imperative vs functional and procedural vs object-oriented. The procedural vs object-oriented distinction is a matter of emphasis on actions vs. data. In the imperative vs. functional distinction, imperative code modifies state freely while functional code attempts to minimize state change.
Great video. One of the easiest to understand and best organized I've come across for general OOP principles.
I'm not as knowledgeable as the guy in this video, I'm a novice and studying to become an engineer BUT I have to say at 4:50, at least in Java, it IS true that the executions within methods are by default not varying like new instances of field/variables, however a method can be overrided, which basically let's you retweak the executions in a method.
Object-Oriented Programming doesn't begin with data, it begins with types. It's all about classifying and relating things into some hierarchical world-view, under the assumption that it will let you create reusable components. In actuality, this results in an extremely rigid framework that is impermeable to change, and thus leads to even less code reuse as even minor revisions cause enormous code ripples. Sure, OOP is good for modeling, but for programming, it's a nightmare that generates far more work than necessary.
What programmers really want is dynamic and mutable typing. But they won't say that because it's taboo and evil for reasons that no one can sensibly explain (ego, bureaucracy, lack of preoptimization (aka. static compilation and manual memory management), the misguided belief that static typing magically eliminates some huge class of common bugs that no one can actually list, being too lazy to use a debugger or write unit tests yet not too lazy to complain about the reasons why they exist, etc.)
So you have no clue about all the best practices for OOP programing?
And dynamic typing is cancer. It shifts a huge number of compilation errors to runtime, making it harder to detect errors.
It's convenient occasionally, sure...
But like don't.
You're both wrong. It begins with messages according to Alan Kay, who coined the term "object-oriented."
@@janisir4529: There are no "best practices." There's only bad OOP and less bad OOP. Watch Brian Will's other videos on OOP.
@@jasonapril4868 Basically what he does, is strips down the code to it's very basics, which may seem shorter, and easier to understand, but on the long run that'll be cancer to maintain.
@@janisir4529 That's quite the assumption. Would you say that about the Linux kernel?
Taking CS 1 in the Fall. Learning OOP and OOD before I start the course though.
What a video, I actually started making handwritten notes, fantastic!
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." -- Fred Brooks (Flowcharts being functions, and tables being data-structures). I don't know who Fred Brooks is but I read this quote in the book *The practice of programming* by Brian Kernigan (long live Brian Kernigan) and Rob Pike.
OMG this quote is terrific; it explains a lot not only about programming, but about understanding in general. Great quote.
Thank you for such a nice and concise definition of important basic concepts.
You really know a lot about code logic
Class inheritance has been useful to me so seldom that I almost forget it's possible. Seems like most problems involve similar but really different types of data so that parent classes add only complexity and generic programming is a better solution.
This video has to be one of the most useful for explaining this topic! I would only say that some more detailed animations and illustrations would have been even more helpful.
+1 for explaining interfaces and abstract classes. And -1 to all the gurus giving demos on how to implement them but fail to explain why.
Clear, concise and imaginable.
Thank you very much, mister Will.
Best explanation of OOP
Great video. The information is presented in a clear and elegant way. Thanks!
This is one important video for people like me who are coming back to OOP after almost 4 years or more. It is a good revision of the concepts and quite concise. Now I can move to the programming part knowing I have covered the basics properly.
public class AbstractManagerFactorySingletonServiceFactory
This was very thorough! Well done.
A computer teaching me about computers, the optimum demonstration of self awareness. This will lead to a new epoch of bio-mechanical peace and understanding. JK JK. As per eush, thanks for the most excellent, free information.
This is wonderful. For those complaining about the monotone voice: use subtitles :)
btw, you should do a video on design patterns next.
OO is just about overengineering everything.
Very clear and effective descriptions, thank you!
Thank you so much for this :). OOP exam tomorrow
thanks for the update, getting back into coding with Swift 3, just what I needed!
Why is there a picture of the death star when constructors are explained? Is something going over my head? (Helpful video btw!)
It's because the death star is *under construction* . That image was from when the death star was not yet finished being built.
*random side-note:*
One problem with the way OOP programming conceptualizes the concept of construction is that it gives you the false impression that there only can be one centralized way of building an object. In reality, you could have multiple functions for constructing the same object (even with the same data type signature) if you made the constructors be global functions external to the class. Thus, for example, in a more procedural style you could have both something like "TypeX MakeObjectOfTypeX_CartesianCoordinates(float, float)" and "TypeX MakeObjectOfTypeX_PolarCoordinates(float, float)" and both would simply be global functions that return a constructed instance of the object of TypeX (i.e. constructors are just functions that return filled out instances of the underlying data structure). In other words, constructors aren't actually special on any kind of fundamental level. OOP constructors don't allow you to do this because you can't overload a function name with two functions that have the same type signatures (e.g. "float, float" here).
Under the hood, constructors are actually implemented as just global functions whose return type is a struct of the same data type as the object's fields gathered together and placed in a plain struct. Also, "methods" in OOP are also actually essentially nothing more than global functions in disguise whose first input parameter is a pointer to an object of that type named "this" which is implicitly used whenever you refer to the instance's member variables. In other words, to an extent, OOP actually obscures the syntax of what is actually going on and makes it less general from a notation standpoint. However, it does implement a "v-table" (which is how polymorphism is implemented under the hood) to enable inheritance and that is the only real fundamental difference between global procedural functions and OOP methods once you truly understand what is going on under the hood.
Thanks! That didn't click in my head when I first watched this video.
5:03
Encapsulation is the notion of grouping data together with methods.
And what this video says is just data hiding / access.
You seem to me mixing encapsulation with abstraction..he is right in the video
Good example, the cat class with the "meow method."
Your voice reminds me of Archer. Great video.
I love this video and how the guy presents it without BS. Thanks man.
نه8
Very helpful and well explained.
c# is dynamic too
+Garegin yep handled by the DLR (Dynamic Laguage Runtime)
Very good work son, really clear
Thank you for making us better programmers
"Mario, we have to save Princess CodeSchool!" :D
Thx for this. Struggling through my first year programming class. This helped.
I'm here on behalf of Prof Domingos Begalli. Who else with me here????
Thank you. REALLY APPRECIATE your effort of putting things so simply here.
This is really good introduction! After learning GO basics, this helps me a lot.
It's rarely known upfront how inheritance will work in complex system. Interfaces are more flexible and ultimately more useful concept. They also providing convenient bridge to functional programming.
You know, and object is not a data type. It is a container of data and logic. And an object can contain no data.
I have been listening this debate againt OOP now for long enough and I come to the realization that alot of misinformation is being said. Object Oriented programming is not bad. Inheritance is aso not bad. What is bad is misusing OOP and misusing inheritance.
Please keep doing these, wonderful content and with excellent way of explaining!
Excellent video
what, no "OOP is Hitler" today?... Instead a brake down of what OOP is all about (and a nice job i might add)... I am shocked... xD
+zoran djipanov This video is 3 years older than his OOP is bad video
y ik...
THank you ..
Students who need a real-life example for object oriented design can download that report here: www.objectorienteddesign.org
I have shared my personal experience of a software project that I completed for one of my client.
Great video... I'm a JavaScript developer and lately have been working with a lot of Java and C# code bases. Your video detailed it out for me easily to start understanding project structure. Thanks!
At 16:11, you say 'any class that you create is going to be ancestor of object', I guess you should say it other way around, I.e Object class is the ancestor of any class you create. Please correct me if I'm wrong.
yes, he probably meant to say "any class you create is going to be a *descendant* of Object"
Except for GUI's and graphic objects, Procedural Programming is the best way of programming.
No
Good video for reviewing OOP, but not recommended for beginners trying to learn OOP.
As somebody who learned how to program using an imperative language I found it fine
*My first year programming lecturers, first class of the year* Okay so heres OOP
*Me, never done programming before* yeeeeeees I have no idea whats going on.
Thank you this is a good refresher.
Thanks (tack). What differentiates procedural and functional languages then?