Northeast PHP 2013

Los principios SOLID del desarrollo de aplicaciones

Anthony Ferrara  · 

Presentación

Vídeo

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

whenever you're ready while ago thank you very much all right let's see if we can deal with this feedback issue hey you know feedback issues yeah I like to move so how's everyone doing this afternoon actually I'm the least I'm talking in

the morning so welcome to Boston today I'd like to talk to you a little bit about object-oriented programming and just for a little bit of backstory on this talk I've given this talk a large number of times I've never been happy with it and I keep

thinking I want to shift the focus so this is a brand new version of this talk that you get to experience for the first time so let's talk about object oriented programming what is an object conceptually well we have this classic view where an object is

a physical thing it's something that you can touch you can interact with you model it off of you know a cat or a car or something like that it's this physical object your methods are then behaviors or actions on that physical object and your properties

describe that physical object does this sound familiar a lot of beginner textbooks do this a lot of blog posts to try to teach object or your programming talk about it this way and what you wind up is something like this where you have this inheritance tree

where you have interface animal then class mammal implements animal cat extends animal lion extends cat this is simple right you have code that looks like this where you make a new lion then you make that lion war you move the lion around I mean this is at

least from what I've seen a lot of the way that object-oriented programming is taught and the way a lot of people think about object-oriented programming you have this object and then you do things to this object right makes sense it's simple but is

it realistic if we look at this code again last time I looked to make a new lion it takes two lions in about nine months does a lion have a button to make it roar no what does it mean for a object to hunt we know what a lion does but what is an object do what

is a lion in relation to our application and the reality is we don't know you have to look at this lion class within the greater context of your application and that may make sense and it may not make sense you always I have to depend on context but the

question is does this model work is this model realistic it's very easy to understand because we deal with real-life things every single day so if I want to tell you about an object Howie it's a lot easier for me to say hey you can pick up this chair

this chair has properties let's call this chair an object but the problem is it's easy to understand but it also completely misses the point it's completely impractical if you try to build a realistic system of realistic scale using these techniques

you get lost very very quickly I mean if you want to what is this what is a session okay I know what a session is conceptually what is a session object how do I relate that to the real world you could probably come up with something but it's not easy it's

not intuitive so what I'm gonna introduce here is what I call the modern view about Victorian design there's a number of different ways to describe this this is one way that I found I think works so an object is a connection is a collection of mostly

related behaviors method is a behavior and properties are details of that so what do we really mean by behavior well the classical view says this object this Lyon object conceptually is a lion or this lion object conceptually is a cat behavior does the reverse

which is this object behaves as this other thing that we're trying to model so a session class a session object behaves like a session and then you have a definition of what a session is and every works together nicely because we're dealing with behaviors

we're not dealing with types and this gets important in a second so rather than using these abstract concepts to talk about it like cats and animals and cars and all this stuff why don't we try to talk about something that you as developers me as developer

do all the time let's talk about numbers so let's imagine we wanted to create objects to represent numbers okay we had this interface number and you have a bunch of methods on it what we're really talking about and what this interface describes

is the behavior of a number we don't care how the number is implemented we don't care how you're storing it we don't care about anything except the behavior that we're defining so we take that to a logical conclusion and you have this interface

number which we just looked at and then you have this whole tree of sub number types that we can have where you have an unsigned long integer inheriting from long which inherits from integer and you can get different data types and different you know values

and different sub behaviors but everything on this chart behaves like a number conceptually except this is a lie because we really don't need inheritance we can talk about object oriented and so I consider your talk but that misses the entire point of

object oriented you can do Hopi 100% without using inheritance and a lot of people don't realize this and that's why you get into these really deep trees and you have frameworks where everything has to extend from this base class you don't need

any of that all you need is polymorphism and encapsulation does anyone recognize those two words okay so let's really quickly go over them polymorphism for the purposes of this talk there's a number of types is behavior that's determined dynamically

otherwise known as dynamic dispatch what that means is the person who's calling a method doesn't know what that method does it's determined through some other route so to explain that we have this procedural code and this is relating for that number

again let's say we want to make a function that adds one to a number that we get the body could look something like this if a is a long then we have to return a new long if a is a float then we need to return a new float if a is a decimal we return a new

decimal how many people have seen code similar to this where you have this big chain of ifs or switches or anything like that polymorphism says these are details of that implementation I don't care about the details I want to invert that dependency and

say number you deal with it that's polymorphism that entire block of code now instead of me manually choosing what I'm doing based on what you give it I'm telling that integer object add one to yourself simplifies things it simplifies that relationship

so in the integer class we would have a method that looks something like this where when you call that add method we're gonna return a new integer that adds one to whatever was passed that add the number that was passed in and this is hand wavy on top

the point is it's the class it's the object that's determining behavior float we have a slightly different thing when we return a float value same concept so let's talk about encapsulation encapsulation I tried to define this in terms of behavior

it's where the behavior is completely contained within that object so we could do something like this where we get pull the value directly from the number and we say if value is 5 then we're going to do this otherwise we're gonna do something else

simple straightforward seen this in a lot of frameworks to see this in a lot of code nothing inherently wrong but not object-oriented object-oriented code we want to tell that object compare yourself to 5 so instead of getting five we say number equals and

then pass it an integer representing five and let that object determine how to do equality and the reason is if you've ever tried to implement a fixpoint decimal it is a nightmare it is an absolute nightmare the efficient way to do it is splitting up two

[ ... ]

Nota: se han omitido las otras 3.988 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.