Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
good afternoon how does a nice little break wasn't it I didn't realize there was beer out there until about two minutes ago I feel gypped so how do I hey guys enjoying product so far good hands up if you enjoyed the conference so far hands up if you
didn't that's a good sign alright so I want to talk to you a little bit today about object oriented design object oriented programming how many here show of hands how many of you practice object or in programming right now that is awesome how many
of you have heard of object or in programming okay and how many of you have no clue what it is be honest Wow nobody that's impressive yeah well I'll give you a hint if you don't know what it is you're gonna have an easier time with the first
part of this talk so there's this question what is an object and I think most people get this wrong and I think that the way that we teach our object oriented programming is wrong so let's go through this for a second in the classic view in what we
teach in textbooks and you know articles online they try to equate this notion of an object or a class to some kind of a physical thing your methods make that physical thing do something and then your properties describe that physical thing so you can have
a car class and this car class has a method called drive and a method called start and a method called stop and the properties are the car is red the car is a you know Ferrari the car is manual transmission yada yada yada yada all the way down the line and
this is popular because it allows you to conceptualize you interact with a car maybe not a Ferrari but you interact with a car everyday you don't interact with these magic things called objects so by equating 121 we can kind of mentally make a map and
that's why people think this is a good idea so we usually wind up with a tree like this how many people have seen something like this before pretty much everybody you have this inheritance tree this hierarchy where you have an interface animal and then
mammal extends from animal and then cat extends from mammal and then lion extends from cat makes sense right kind of maybe not really let's look at what a lion is let's talk a little bit about this lion in classic code we may have something like this
does this make sense does everybody understand this or I've seen something like this before well this raises a couple questions is it realistic have you ever seen real application code that looks like this I know I haven't and the reason is let's
dissect this what does it mean to make a new lion what does that first line mean I could go digging through the source code but mentally in my mind I think you need two lions in about nine months to make a new lion so when you call knew what does that mean
I have no idea okay what does it mean to make a lion roar is there some magic button somewhere on the line where if I press it in just the right way he'll start roaring what does it mean for an object to hunt we can probably come up with a scenario where
this exact code would make perfect sense but by itself it makes absolutely zero because we don't know what a lion is in relation to our application you need to understand the entire application in order to understand this line in this little piece of code
and that's not what object oriented code programming is about letting us ignore the rest of the application so this classic model is very easy to understand which turns out to be both a good thing and a bad thing because it's also completely impractical
so let's introduce a new view the what I'm going to term modern view which is that an object is really a collection of related behaviors behavior is what we're dealing with here your method is the behavior that you want to interact with and your
methods are your behavior I'm sorry your methods are your behavior and properties are the details behind that behavior so they may be dependencies they may be some state information you need to keep track of the key here though is its behavior that we're
dealing with in the classic view we're talking about an object conceptually is a something so an object conceptually is a lion an object conceptually is a car the modern view is really behaves as a so let's walk through an example with some real code
let's talk about numbers numbers are a pretty abstract concept yeah when we think about them we normally think about integers or decimals or things like that but Roman numerals or complex numbers there's really a lot of broad things that fit this concept
of a number so we could talk about this entire hierarchy of types of numbers and inheritance and all these things that behave as this conceptual number but there's a difference here we don't need inheritance to talk about object-oriented that tree
model is a distraction all we need are polymorphism and encapsulation so it's really really simple polymorphism is when you have behavior that is dynamically determined meaning when you call a function in procedural programming you can go look up that
function name and know exactly what it does when you write the function you know exactly what it does polymorphism says we're going to have some kind of a variable that's going to control where that function lives so when you write the code that calls
it doesn't know at that point in time what's happening it's a really really really simple concept it's really difficult to explain well so we have like a block of procedural code with that number example and we have four different statements
here or three different if a is a long integer we do one thing if it's a float we do another if it's a decimal we do another so we have this flow here the problem comes along what if I change add a new type what if i add a complex number or if i add
a Roman numeral or something like that now I need to change my calling code whereas if we use polymorphic code we're telling the integer what we want to happen we're saying hey number add one to yourself I don't care how that's not my worry
my worry is to tell you what to do you worry about doing it that's polymorphism your code looks really simple and that's the whole point of this we want to localize our code and we can do the same thing with the flow as we did with the integer and
it really looks the same just some minor details changed this is something that you really need to play with to really really get a good grasp of so i would suggest trying just try and playing with this try instead of using a raw function call try making it
an object and try changing which object that is so the other half was encapsulation where behavior we want to hide the information that we're dealing with we want to hide details so we can expose abstractions so the example here is we have a detail that
five is stored in the number property of this object if five is the value print the number is five if not print the number is not five this is dangerous because what we're really doing is we're coupling this code to the details behind how number is
written instead we can use a different concept where we don't ask we don't ask for what your value is we say I want you to tell me if you are equal to 25 we're encapsulating those details where encapsulating the information make sense so one of
the reasons for this is well for integer and flow it's pretty easy to do but if we wanted to do it decimal we now have some complex storage so that value property doesn't really exist anymore so now our encapsulated code is safer and we can start to
deal with them as containers bacon so I want to talk about API is for a few minutes if you were in the last talk that was in this room Larry talked quite a bit about api's Krell I want to talk about api's at a fundamental level there's really two
fundamental types of api's you have an interface which is what they're called in PHP which is what they're called in Java where and go in a whole bunch of other languages which is an explicit API it's saying i'm going to give you an object
that implements this interface which means it's going to have these three methods that hopefully do what we promised them to do the point being is that it's explicit it's just as if we signed a contract that says I guarantee this code is going
to do what I say it's going to do the other type is duck typing which is if it looks like a duck it's probably a duck you pass in a object we expect it to have a particular method if it doesn't have a method we're just going to error out we
don't care about the contracts we don't care about the explicitness of it now to be completely fair I used to be a interface everything person if you talk to me to three years ago interfaces of the way to go duck typing is stupid why would you do that
[ ... ]
Nota: se han omitido las otras 4.399 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.