The Laravel Podcast

Matt Stauffer:
Welcome back to Laravel podcast, season four. Today we're talking about Object-Oriented Programming with Alena Holligan. A senior software engineer at Lumen Learning and a former teacher at Treehouse. Stay tuned.

Matt Stauffer:
All right. Welcome back to Laravel podcast season four. I'm your host Matt Stauffer. And a reminder this season, every single episode is about a specific topic that we think folks should be learning as they're stepping into the Laravel world. These first couple episodes are primarily about stuff that aren't just Laravel specific, but there are things that are really helpful for everybody to know.

Matt Stauffer:
So last week we did one about Composer and this week we're going to be talking about Object-Oriented Programming with Alena Holligan. And Alena and I met at Sunshine PHP years ago. Thanks Adam Culp. And since then she's been working with team Treehouse and then recently moved to a company called Lumen Learning. She lives in Portland. So Alena, could you tell me a little bit about yourself. Say hi to people and also talk a little bit about your kind of background and what Lumen Learning is and what your job is like day to day?

Alena Holligan:
Sure. Thanks for having me on here Matt. I appreciate it.

Matt Stauffer:
Yeah, thanks for coming.

Alena Holligan:
So I started out in fine arts and I always thought programming would be the most boring job ever. I had an uncle that was programming and I thought, "No way, never." But I got introduced to programming at The Art Institute of Phoenix as another way of design. Like yeah, you could do some drag and drop stuff, but if you got into programming you could do more. And instead of it being like a painting where you just hope someone gets something out of it. With programming, it gave me the opportunity to hold their hand a little more and bring them through. And like show them what I wanted to show them. And so I really enjoy the fact that programming is another form of design and it's creative and it's a puzzle. I love puzzles.

Alena Holligan:
So I really liked that about programming. So I started programming over 20 years ago now. When I started in PHP close to 20 years ago, it was not at all like it is now and there was no Object-Oriented Programming. And so I started programming what I was doing and then all of a sudden this object oriented stuff came out. And I thought, "Oh okay, this is great." And I tried to try to figure it out, but there was a problem that I ran into was that because we had object oriented now all of the sudden we can do all of these things like frameworks. Frameworks were really difficult before Object-Oriented Programming because there was no way to think of code as separate chunks. Instead it was just this huge procedural base of code. You had to know all of it and have it all in your head and it had to all kind of go together.

Alena Holligan:
Yeah, you could split out files, but you couldn't think of it in chunks. So you couldn't build a chunk of your framework before there was really Object-Oriented Programming. So when it came along, all of the sudden there's all of this new ideas and new ways of going that kind of got mixed up with what object oriented was and what just other new features and abilities were. And so that first off was the big challenge. And then you go to ask questions about object oriented and they throw out all these big words like encapsulation and polymorphism and like they expect you to understand what they're talking about. And you just go way more confused than you were to begin with. And so that was really challenging. And so when I started, it probably took me two years after I had already been programming. It probably took me two years to even feel comfortable with, "Oh, I think I kind of have a grasp on this object oriented thing."

Alena Holligan:
Lorna Jane Mitchell is actually one of my heroes in helping me learn object oriented. She had some videos out at the time that really help me understand what was going on. And so once I understood this, I'm like, "There's got to be easier ways. This isn't that complicated, like there has to be better ways for people to learn this." And so that kind of became my passion was to make this easier for the next person. I don't want it to take... It shouldn't take two years for somebody who's already been programming to learn this new thing. And so that's where I really got focused on. So we moved to Portland about six years ago from a small town. So there wasn't anything where I used to live to all of the sudden there is a meet up going on every night of the week.

Alena Holligan:
Some tech meetup you can go to every night of the week if you want to. I found out there is a 20 meetup limit to join per day on meetups. So that's your limit or else they think you're a robot. I easily did that.

Matt Stauffer:
You discovered this, wow.

Alena Holligan:
Yes, I easily did that. Just things I was interested in in Portland. So that was great. And I started out with the Women Who Code group and things like that. They actually started the week I moved to town. The Women Who Code Portland started that same week. And so I got involved with them right away and started teaching object oriented to new people there in person. And then through code Oregon that really got the word out about Treehouse locally. Lots of people I met at in Portland knew of Treehouse and like it's a great place to work.

Alena Holligan:
So when a job came through on the PHP meetup board about Treehouse, I'm like, yes. I had been a student and I was actually going back through Java because Craig Dennis is awesome and he was a Java teacher at the time. I had done Java before and I'm like, this should give me some being not having gotten my degree in programming. I'm like, I'd like to fill in any cracks. Like where am I missing staff? And so I'm like, it would be good to do something else. So let's go through Java. So I had picked Java mostly because of Craig.

Alena Holligan:
And so when the job came along I applied and two days later still hadn't heard anything. So I'm like, that's fine, I really want to work there. So I tweeted to Craig and I'm like, "Hey Craig, love your courses. I saw there was a PHP opening and I haven't heard anything." And Dave jumped in is like, "I emailed you three times." So my big tip, if you're applying to a company, make sure you don't have their emails filtered for some other reason. Because I had been a student, all the emails went in a filter for my Treehouse emails and I never saw it.

Matt Stauffer:
Tip of the episode. There you go.

Alena Holligan:
Yeah, there's my first big tip. Make sure your email is not getting filtered.

Matt Stauffer:
I love it.

Alena Holligan:
So I worked there for like four years and I was really excited about teaching object oriented. That was my first big thing there.

Alena Holligan:
They really didn't have a robust object oriented training yet to there for PHP. And so that was what I was really excited I'm about. I'm like, I can really reach more people and teach them Object-Oriented Programming. And so I was really, really excited to do that.

Matt Stauffer:
And so now you're at Lumen. So I know it's also educational, but it's obviously not the same thing. Could you tell us a little bit about Lumen real quick?

Alena Holligan:
Sure. I actually am back in development at Lumen and what I'm really excited about there is the fact that I get to work on an old code base and start to refactor that which is something that I also been interested in doing. And so now I have that opportunity to do that. And so we do alternatives to college textbooks for students. And now with the pandemic and people working from home and trying to do school at home, all of a sudden it's even more important that they can have course ware that is conducive to online learning.

Matt Stauffer:
That's awesome.

Alena Holligan:
So we provide... I actually work on the math portion and we cover most topics, college level topics that we do for. So we provide online textbooks. We actually have a lot of open source educational resources that we use and that we can contribute to as well in that realm.

Matt Stauffer:
That's awesome. And we'll link both some of your Treehouse courses and also Lumens website and your Twitter and everything all in the show notes. If anybody's curious about any of that, go check out the show notes and you'll see all these links.

Matt Stauffer:
So I know that you have done a lot of work with OOP, not just in terms of teaching it, but also trying to make it approachable to folks who are new to it. Which is exactly why I got so excited to bring you on because I was like, I want to make OOP approachable. And I remember when I first... I had been programming for years and been writing PHP for years and then I tried to start using, OOP, I think it was in PHP 5.3 or something like that. And I just couldn't wrap my head around the concepts.

Matt Stauffer:
And one of my friends who was a Magento programmer had had to learn it maybe six months ahead of me because they got into OOP a little bit earlier than I did as a result. And he tried to give me the whole like person... All the generic kind of examples and it didn't click and it took me several years to click. So I identify so much with that. And I'm hoping that that's less the case for folks today. But let's assume, well, we'll go there in a second. I always start with the first question, which is if you had to describe this concept, and this particular concept is Object-Oriented Programming to a five-year-old, how would you describe it to them?

Alena Holligan:
It's interesting. I have a six year old, six, seven and eight now.

Matt Stauffer:
Perfect.

Alena Holligan:
Are my kids.

Matt Stauffer:
Nice.

Alena Holligan:
And I always think you should be able to describe anything to a child at five. Once they're five they really can understand most things.

Matt Stauffer:
Yeah, totally.

Alena Holligan:
So if you can't describe it then you don't really understand it. So it's a good question. So if I was going to describe Object-Oriented Programming, it depends on, again, in teaching, how far back do we go into what do they understand? So first before you can teach what's object oriented, you'd have to say what's programming.

Alena Holligan:
So if we're talking about programming and let's say we've had a couple conversations on programming so they have a little bit of an idea about what that is. Then what is Object-Oriented Programming? It's this idea that you have the data and the functionality grouped into pieces that you can work with so that they are individual pieces of code that can work independently and that you can know something goes in and something comes out. And then you can work on these pieces individually.

Alena Holligan:
And that's what really is the power of Object-Oriented Programming is that you can work on this smaller chunk and use that to build more complex things.

Matt Stauffer:
Yeah, I love that. It's so fun because I had, we talked about get in a previous episode and I love when I ask a question and the answer is not the classic answer I think I would expect.

Matt Stauffer:
And like Gemma did that with me with get. I asked what's get and expected one thing and she answered it in a much more nuanced enriched and simpler way and that's what you just did there. So I love that description. But now let's get a little bit nerdier. Let's say you were talking to an experienced programmer who somehow had missed OOP. And it's not because they were deciding to use some other type of programming. It's just because they were still writing procedural code until today. How would you teach them, how would you describe OOP to them? Or would be any difference?

Alena Holligan:
Actually I'd start the same way. I mean it really, if you can't explain it to a five-year-old, then you can explain it to an adult either. And so that's one of the problems with teaching and one of the problems I had with learning it is that people either used terms that you expected they already knew or terms that to make you look good. To make you sound smart and that's not useful. When you throw out word abstraction and encapsulation and polymorphism. Yeah, those are all great OOP concepts, but they don't actually mean anything if you're just new to object oriented and you're just trying to ask a question.

Alena Holligan:
Throwing out those words, those words have no meaning yet because I don't understand them they have no basis in my knowledge. And so throwing out words like that is not helpful.

Alena Holligan:
So yes, I would start with the same way. The great thing about Object-Oriented Programming over procedural code is that now we can work in smaller chunks and more people can work together. Whereas procedural code is really useful if you've got a project and you're the only one you can do procedural code fast and easy. It's a good place to start because there's less complication but you have to store all of it in your head at once.

Alena Holligan:
And so once things become larger or you're working with a larger group of people, all of a sudden procedural becomes much more difficult and you need something else. And that's why object oriented is more helpful than procedural code when you're looking at either a larger code base or working with multiple people. Because object oriented is this idea that you have the data and the functionality grouped together in these small chunks that you can work on. So I need to know what do I pass in and what do I get out. And that's all I need to know about it. And someone else can work on that chunk. So if I need to use it, I need to know what goes in and what comes out.

Matt Stauffer:
Right. Lots of little black boxes floating around that do all the work and you give it data and get data out.

Alena Holligan:
Yeah. It's a lot like functions in that way that you would pass stuff in and you bring stuff out other than functions only perform data. Only perform manipulations on the data. They don't store the data themselves.

Matt Stauffer:
There's that representation, yeah. That's a great point.

Alena Holligan:
So they can't store any of it. They can't store any of the data. So the objects let you store the data with that functionality.

Matt Stauffer:
Yeah. That's great. So if we were to kind of go a little bit forward and say everybody should learn what OOP is. So you've given great kind of a couple sentence descriptions of them. Are there core tenets where it's like the top three this or this principle and that principle that you would think of as really definitive of what Object-Oriented Programming is.

Alena Holligan:
I like to start with a lot of my explaining to people what those words are that go here. So understanding terminology is important because you're not going to be able to... Google's amazing, you can Google and get all kinds of answers, but if you can't understand the answers it doesn't do you any good.

Alena Holligan:
So one of the first steps that I really talk about in learning object oriented is just understanding what those concepts are. They're not hard. What are those terminologies that people are going to throw out there and what do they mean?

Alena Holligan:
So terminology is really important I think. It's one of the most important things that I feel in teaching people. Because like I said, Google's useful but only if you understand it. And you can't understand it if you don't know the words. So understanding the words that's around object oriented is important. And then understanding why we have objects and then something else that I really like about object oriented because it ties that into is our interfaces.

Alena Holligan:
To me interfaces are a good example of what object oriented is for. Not that you even need to use interfaces, but they explain a lot of what it is because like I was saying, I need to understand what goes in, what do I need to give this and then what am I going to expect back. And that is what an interface does it, it sets up that contract. The interface simply says this is the type of data you're going to pass in and this is the type of data you're going to get out.

Alena Holligan:
With PHP 7 and continuing to add on in seven we now have a lot more... We have other choices than just interfaces in being able to make that distinction by giving the type hints for what types are coming in and what type you can expect out and all of that stuff.

Alena Holligan:
Those are anything that helps you knew that I think is really useful because, again, to me the idea of Object-Oriented Programming is the idea that you can work on small chunks and you can all work together to make something bigger and better than you could on your own. And so if I can understand how to work with your piece, that's all I need to know. So it needs to be that interface between your piece of code and my piece of code is what needs to be clear. So however we make that clear, there are several choices, but however we make that clear, that to me is the most important part.

Matt Stauffer:
Yeah, I appreciate that. I also often noticed that OOP is the easiest to describe visually, at least for me. And so trying to have you kind of teach all this stuff over a podcast is definitely tough. So I apologize to you and everyone else, but I think you're doing great so far.

Matt Stauffer:
So you've covered some of the more complicated terms. Just as examples of things that people say without fully making sure the other person understands like polymorphism and encapsulation. But if there were just a couple core concepts. You said terminology is the first thing to know. What are the first couple things that in order for OOP in general and also maybe even just the rest of this conversation to make sense. You mentioned an interface, what other kind of high level concepts are there that somebody should know if they're going to learn OOP? And I'm thinking simple things like classes and everything like that. So what's on your list of things that just you got to get these out of the bat before you can even follow anything else?

Alena Holligan:
Well, the first things that we talk about are properties are the variables that are inside a class in your object instead of a variable it's called the property essentially. And your functions inside of class are called methods, but they're essentially, so the data is your properties, the functionality is your methods. But even within your class, your methods are called function, whatever, because that's what they are. They're the functions. So that helps you to communicate, is this something that's in a class or not in a class?

Alena Holligan:
So if I'm talking about a function outside of a class, it would be a function. A function inside of a class is a method. So that's important to know. Another thing of the very basics that's important to know is understanding this. So that often trips people up. This or some of the ones for static, which are things like static or self or parent with the double colons.

Alena Holligan:
Those are all different ways of referencing the object that's created. So you have your class is your blueprint for your object. That describes how the object will be created. Just like a blueprint for a house. And then the object itself, which there's an each object instance could be called an instance or an object. Those are oftentimes interchanged, but the instance is the individual instance of it. Matt is an instance of a human and I am also an instance of a human. Those are different instances. We're both humans. We've used the same blueprint, we have different things that make us up. But the blueprint is the same. How it's put together. We have the same things. So we have our object, we have our instance, and then to work with those inside of those objects. So inside the class it uses terms like this to refer to itself.

Alena Holligan:
Just like I would use I. I am something. That's what this does. This is referring to this particular instance of that object. So I think that's one thing that often gets... You see this and you're like, "Whoa, that's weird." Because if you've never done a class. Or even if you've seen it, you just don't understand what it is. That to me also was like, "Okay, I've used it even, but I don't really understand what it's doing."

Alena Holligan:
And then especially when you get into static methods, which are ones that you can call without actually instantiating an object. You can read directly from that blueprint, from that class and you can say, "Hey, I don't need to save any state. I don't need to have any data state saved. I just want to know if I give you this data, do something with it and spit it out." Like format something or whatever.

Alena Holligan:
In there, because we don't have it this we haven't created I yet, there's no concept of I. Now you have things such as self-static or parent and those are all with the double colons. And those are all the things that reference this current working with that class. The class itself, this is something here. So I think those are things that really simple concepts that if you don't understand them off the bat, it makes everything else a lot more complicated.

Matt Stauffer:
Yeah. Or everything works and then all of a sudden you change something, you don't know what broke because you don't understand the difference between self and static or self in this whatever. Yeah. Totally.

Alena Holligan:
Yeah.

Matt Stauffer:
Now, that's very helpful. Do you have any... I know that like even understanding that difference between self and static my brain takes a second to register which one I want in any given moment. Do you have any tricks you use to remember which one is which? And for anybody who's not familiar, self and static both refer essentially to the class that you're working on. But one of them refers to the actual class and one of them refers to basically which specific class you're working with, even if that self is being called in one of its parents. So if I were to make like a human class and then there was like a programmer, a subclass of human, and then there was like a teacher subclass of humans and by subclass meaning like... We haven't talked to inheritance at all. Gosh I'm trying explain this one thing without actually going to 10 other topics. But yeah. So basically self-versus static.

Alena Holligan:
It's a challenge.

Matt Stauffer:
Yeah. You're familiar with that challenge more than I am. The self-versus static defines whether when a static method is referring to, I guess it could be other things, but referring to the class blueprint, right? Is it referring to human or is it referring to programmer basically. So it's kind of changing the hierarchy. Like how high up in the inheritance chain am I going before I either call this method, I'm calling on self versus static or before I get this property than getting on self and static?

Matt Stauffer:
I know we haven't talked inheritance, so it's totally my fault that I just dug into this thing. But I'm just super curious. Do you have a shortcut that you use for remembering which one's which?

Alena Holligan:
You're not often using static, you really aren't. They're very seldom that you're using it. But if there's something particular like it's not working the way you want it to, those are the types of you look at. Just knowing there are two ways and that they might refer to different things and how it works together. But once you get into inheritance a little bit more, you'll understand how that works. But really you're not using... Don't often use static, so you will see self-more often. But just knowing that, oh, I want to be able to reference this particularly you probably can. There's probably a way to do it. So if there is something specific that you want to do, there is probably a way to do it. You just have to know the specific way of calling it.

Alena Holligan:
And that to me is much more important than even remembering which way is which. Just going, hey, there is another way to do it. This did not pull the data that I expected it to pull. Oh, there is another way. Yes there is. PHP can do it. You just have to know what that is.

Alena Holligan:
So you can find the specifics. You can look it up. There's no stigma. Nobody's keeping score of how many times you look in the manual. Most developers probably have some sort of manual or something or Google open every day. Everybody looks up something every day. You don't program in a box. So I don't think that's as important to memorize because you won't use it as often. So I would just say don't worry about trying to get that stuck-

Matt Stauffer:
Don't worry about that right now.

Alena Holligan:
Don't worry about getting that one stuck in your head because you're not going to use it that often. But just knowing that it's there and knowing that you can look it up. The PHP docs are actually really helpful.

Matt Stauffer:
Yeah. And anybody who's... So one of the things I try to say in these is we want to make this primarily targeted at people who are new. But make sure that we also are including little tidbits here and there for people who are been around. So if you've been around for a while and you've struggled with self-versus static, what I would tell you is go look up PHP late static binding. And that's actually the thing that was introduced in 5.3. Late static binding is... Again, new folks don't worry about this right now. Nerds, people who've been around a while, we're all nerds, whatever. Learn about late static binding because it was one of the most transformative things that was added to PHP that made modern tooling like we have today available. And it allowed us to give to give... But anyway, yes.

Alena Holligan:
Yes.

Matt Stauffer:
Just go learn about late static biding. I will put the link in the show notes.

Alena Holligan:
Late static binding is really when you're going to use static. So if you're going to use that, that's when you're going to static. That's what it's for.

Matt Stauffer:
Yeah. Perfect. All right, cool. So the next thing I want to start asking you about is use cases of Object-Oriented Programming. So the first thing I want to say is I would say if you're in Laravel, you're going to use OOP whether you like it or not because PHP frameworks, Laravel and the symphony components is based on all of our packages, Composer or all these things are based around the ideas of, OOP.

Matt Stauffer:
So obviously in the Laravel world, almost everything we do is going to be OOP, especially when you're first getting started. But I do want to just ask the high level of question of when do you think it makes the most or the least sense to use OOP? And so far we primarily compared procedural and OOP code. But there were other ways of coding. So if you were to think of an instance in which OOP wouldn't make sense, what would you reach for? What are the other options that you would consider?

Alena Holligan:
I actually really, I'm fascinated by functional programming. That's been some of the best conference talks I've ever gone to are on functional programming. And you wouldn't think about PHP as a functional language, and it's not. But a lot of the same concepts that are used in functional programming, they are available to PHP. And it really helps understanding those concepts are really useful especially for OOP. Because you can use, it's that idea really... It helps you understand why you're returning what you return. That really when you look at it from a functional perspective all of a sudden why do you return this versus returning a value.

Alena Holligan:
So there are some things that crossover with Object-Oriented Programming. So if you are doing Object-Oriented Programming, looking into functional programming will really help you understand why object oriented is doing certain things and it will actually help you to, I think it was almost easier than object oriented in a way that to understand concepts. And so then it helped me to apply that to my objects a lot better.

Alena Holligan:
So I would highly recommend just more looking into functional programming. Again, you can do a lot of it in PHP. Even though PHP isn't designed as a functional language, you can do a lot of functional programming in PHP.

Matt Stauffer:
Yeah, I couldn't agree with you more. And especially with this being kind of like one of the ones where this particular note is a little bit more to the folks who are listening to this going, "Okay Matt, I know what a class is, ask her some more complicated questions." One note for you guys. That was a fantastic tip. And for new folks, don't worry about this yet, but for those of us who've been writing OOP for a while and get it, I love that point. Your OOP will get so much better when you learn functional programming. Not only because you'll bring some functional patterns back in, but your understanding of the motivations and the reasons. We learn OOP for sure. But we don't always really deeply understand what or why or anything. And when we understand those things, we use it better.

Matt Stauffer:
We architect better the next time. And learning functional programming definitely helps that. And I've got an idea in my head that could be entirely wrong. So I'm going to just say I was going to try and Google it. I'm just going to say it. In my mind, if anyone's a like a sci-fi geek or anything, there's an idea called a head cannon. And so if you think about the cannon being the thing that is ultimately true about the universe, right? And so in a lot of Star Wars universe is whatever you've got the cannon.

Matt Stauffer:
This is true and this is not true. And when someone says, my head cannon what they mean is, I've made this up to be true in my head, but I know it's probably not actually something that came out of reality.

Matt Stauffer:
So one of my head cannons about functional programming is that collection pipelines where you're mapping and reducing all kinds of stuff is a deeply functional thing. And I could be wrong. Alena, you may or may not know if I'm wrong, but someone will tell me on Twitter if I'm wrong. But in my mind that's a thing. And the idea of moving from. And so that's why functional programming is one thing. OOP here's another thing, and procedures is another thing. Functional procedural are not the same thing. If you would imagine how would you iterate over an array and do a whole bunch of things to it. You do it one way by passing array, walk into array. This does that with the other and it would look different in a collection pipeline.

Matt Stauffer:
In my mind, the collection pipeline has always been more functionally. Do you know enough to know that I'm right or wrong or should we let somebody on Twitter tell me if I'm right or wrong?

Alena Holligan:
That is a lot. That is one way that PHP really does use functional programming. That idea of functional programming is that it's really is the idea of the pipeline. The functions can be looped together. They can be chained, functions can be chained for things to happen. Yes, that is functional programming.

Alena Holligan:
The problem that people run into is the idea that they think that just because I'm using objects, it means I'm writing object oriented code. Well, you might be using objects but it's not really object oriented code and it's fine. But that's the other thing is that it is okay. That is fine. You can be writing in a very procedural way that uses objects. You can be writing in a very object oriented way that uses functional programming. And that's okay. Being able to use those where it makes sense you and whatever your project is, that's the important thing.

Alena Holligan:
One of probably my biggest tip for people for programming anything is you want to make it readable and usable. If that made it way too complex, if you can't even keep what you just did in your head, you probably don't want to do it that way. Because then it's too complex. So simplifying things, it should make it easier. Object oriented should make it easier than procedural code. If it makes it more difficult, now caveat there.

Matt Stauffer:
Caveat, yeah. Difficult for who.

Alena Holligan:
Again, difficult. Knowing what you're understanding is and if you don't understand objects at all yet everything is going to be more complicated. But when you're making decisions you don't have to go all in and be, "Oh, I'm writing an object oriented program." You can be writing a procedural program that uses objects. I really like the way Adam Latham talks about testing his idea that you don't have to jump all into test driven development.

Alena Holligan:
You don't have to go all in to make it useful for you. Start out with making it useful. Is this easier? Did this help? Then use it. If it's making it more complicated and it's not helping you need to rethink it.

Matt Stauffer:
Yeah, I love that. And I think that the core tenet there that I love so much is it's a combination of two of my favorite phrases which is number one is, it depends. And number two is use it if it works, or use it if it's good for you.

Matt Stauffer:
If it's helping you here, use it. If it's not helping here, don't use it. If you don't know, learn about it. So that's perfect. I'd love that.

Matt Stauffer:
So I want to go further in, but I know we've got a lot more left to cover, but I want to ask you one last question here. And if you don't feel comfortable answering it, I'll just delete this question. If you were to explain functional programming to a five-year-old, how would you explain that?

Alena Holligan:
Functional programming is more like a train because you chain things together and it's the idea of declaring where you want to be. Like you're declaring, I want to go from here to here to there. And it's actually, I think maybe an easier way for people getting started.

Alena Holligan:
And your idea that, what's the first thing that you want to do to this? Well, first I need to do this. Well, and then I need to transform it some way. Like I'm taking my program or my idea. And the first thing I need to do is this. Or we can go backwards and we can do the same thing. Break it down. Functional is a lot like how your brain works. Because if I'm going to say, let's write out the instructions for making a peanut butter and jelly sandwich.

Alena Holligan:
One of those challenges that they have in what first grade or whatever it is that they say, write this out. Well, what are we starting with? Again, are we starting with the bread? First you have to have your ingredients and your tools. You need your ingredients and your tools and then what's your steps. And those steps are really what functional does. Is like I did this first thing, so now I still have everything that I did. I have my sandwich at this point and now I want to... Great you made your sandwich, now you want to cut off the crust. And now you want to cut it into a fun shape. We need to take your sandwich that you made. And then cut off the crust and then put it into a fun shape.

Matt Stauffer:
Step by step.

Alena Holligan:
It's that stepping through. And I think functional program early talks more to that aspect in how you think about it.

Matt Stauffer:
I love that because we do those things in our code and the number of times that we build things where an object that we're working with needs to go through steps or an object transforms into another object that goes through steps. I mean, that's a super common concept. And just a quick note here, again, a little bit more advanced for folks. But if you are taking an individual object and applying modifications for it, that is the number one most useful time to use things that return this. Meaning you're building fluid chains. People at Titan always tease me especially Daniel Colbourne who is no longer there, but he's still a friend of Titan because I almost always, if I see something return this in a pull request, I'm going to delete it because people don't often know what they're doing when they're returning this.

Matt Stauffer:
And I think that things are used fluently when they shouldn't be. But when fluent chaining, and again this is for the more advanced folks, folks who are a little bit newer, just fluid chaining means on your instance you can call one method after another, after another after another. So you'd say whatever car or whatever. Sandwich, arrow, add bread, arrow add peanut butter, arrow add jelly, arrow put together whatever. Basically imagine you're kind of like just constantly offering those things. You have to have each method return this so the arrow of that method can be called on the output of the previous one. And it is most helpful in my mind when you're taking something that is not established, it's not at the state it's going to be eventually and you're taking a multiple steps and when you're done, it's now going to be at that established point.

Matt Stauffer:
It's like data modification or whatever. And so I appreciate you saying that, Alena, because I think that that is one of the ways for me that functional programming ties in is because there's certain programming patterns in OOP that makes sense sometimes and not other ones. And we can see those parallels in there for them. So thank you.

Matt Stauffer:
And I know that I didn't give you prep on that. I was going to ask you that. You did great. So I could talk about that for half an hour, but I know we need to keep going. So let's talk a little bit about what gets people tripped up. What do you think the aspect of OOP is that takes folks the longest to learn or people are most likely to get caught up on, whether it's about length of time or not?

Alena Holligan:
Terminology.

Matt Stauffer:
Yeah.

Alena Holligan:
That to me is really the number one.

Matt Stauffer:
You're very consistent.

Alena Holligan:
Yeah. That's the number one thing that gets people tripped up. So while we're here so we can untrip people. Let's talk about those words that are used in object oriented a little bit.

Matt Stauffer:
Let's do it.

Alena Holligan:
Just because I think those are the things that really trip people up. They hear these words and they automatically just put on this. The wall comes up and they can't get beyond that because of all of a sudden they don't understand this. And so they can't look beyond it to understand what the other things that are said.

Alena Holligan:
Some of the words that we talk about in Object-Oriented Programming. We talked about the class a little bit already, which is your blueprint. And then, but other words that we talk about are things like encapsulation. All of the words in object oriented are not specific to programming. These are not programming concepts. These are world pro concepts. They're in all kinds of places in the world. So the idea of encapsulation is just like I was saying, an object, an object has your data and your functionality put together and that's the idea of encapsulation.

Alena Holligan:
It encapsulates both the data and the functionality of that data. That's what encapsulation really is. And so then we move on to abstraction. People talk about, well, abstract that away. I don't need to know that right now, abstract that. Abstraction, well, what's the idea of abstraction? The idea of abstraction. Again, it's this abstract concept that you talk about, not in programming. What are these abstract concepts? These are things that we talk about without being able to understand just like you get really existential about this. But it's those things that we don't have to understand how they work to talk about them. And that's the idea with objects. And that's what I've gone back to saying before, you need to know what goes in and what comes out.

Alena Holligan:
And that's how we can talk about it. Is the idea that what happens in that object, I don't care.

Matt Stauffer:
It's not defined yet or I may not know.

Alena Holligan:
I don't care how to function works. I don't need to know how that function works. I just need to know when I pass it this information, I'm going to get out this information. And that's what abstraction means is the idea that I don't have to understand it. I don't have to understand how a car works, how an engine in a car works to be able to drive the car. I don't have to understand how that function works to be able to use it or that object works. I need to know how to use it. And that's it. So that's the idea of abstraction. Is that I don't have to understand the inner workings. I just need to know what do I send to it, and what do I get out.

Matt Stauffer:
Yeah. I love that. So you got more. Give me more.

Alena Holligan:
I've got two more real things that I want to get on to. Polymorphism.

Matt Stauffer:
I was going to the next one, so good.

Alena Holligan:
Polymorphism, again, it's not a programming specific one. Polymorphism is the idea that there is something that we all do that all these objects do, but they don't have to do it in the same way. So, for example, like if you were to call speak on an animal, if you were to tell your dog to speak, they're going to bark. If you tell your cat to speak, they're going to meow. A human to speak they're going to... Someone say hello while saying hello in English, versus Spanish, versus French. It's the same thing even though it produces a different result. It's the same type of thing. It's still a response. It's saying hello in a different language.

Alena Holligan:
That is polymorphism. That idea that it's the same thing in a different way. And that's all polymorphism is. And then the last thing is inheritance. I really like the concept of inheritance because being a parent, to me that's very important.

Alena Holligan:
The idea of inheritance. Think of that as a person, whether you have kids or not. We have inherited things from previous generations. We've inherited knowledge, we've inherited good things in the world and bad things in the world that we've inherited from previous generations, that we already have. And hopefully we can grab on their knowledge. And the tools that they've given us and to build something better. That's the idea. You want to give your children all of the information and tools that you can for them to be successful, but you should not want them to be a copy of you.

Alena Holligan:
They should go beyond you. And that's the idea of a child, class. We have parent and child class and it's that same thing is that they inherit. They can do everything that the parent did and then they go beyond that. And that is what inheritance is. And I can determine as when you're creating that parent, you can determine how much things should be changed. This is true, true, and this is the way I see it. But you may need to make up your own mind on how this is going to work for you.

Alena Holligan:
So we can set up what can be overwritten in the child, and what can be extended upon, and what is final final. And you have those controls in object oriented. But the idea is to think about it in a way that you want your child to go beyond. You don't want to just change it. You don't want to take your parent and just change it because you didn't like the way it worked. That's not the idea of it. The idea is to go beyond, is to have all of that functionality, all of those tools and abilities and move beyond that.

Matt Stauffer:
I love that. And that's true both in terms of the ideological, which I really appreciate because I've got young kids too. It's also even true in the practical if you're thinking about DNA. And obviously it's not a perfect parallel because you're not extending to and getting a various mixture of them, but you have some of those same ideas of the things that are expressed in the parent are expressible in the children. But then they also end up having some things that are different in them. So it's not as direct of a thing. So, in terms of those listening, listen to what Alena said then to what I said, but I like it. It's making my brain think because, and again, you're doing this fantastic thing that I love where again, if I were to say what is polymorphism or what is inheritance? I would start talking about classes and children and you didn't do that at all.

Matt Stauffer:
And I love that, you're talking about the high level ideologies and the high level... The ways that our brains work and also you're making all the parents in the room choke up a little bit. Thank you. Thank you for that. That was awesome.

Matt Stauffer:
So I want to go there so long, but we're going to go so overtime. Okay. So I won't do that. I'm glad that later I get to ask you, is there anything else you want to talk about and where should we learn more about this? Because I need to go in, two more questions just before we get there. Which aspect or tool or piece or whatever or pattern in OOP do you think is the most often misunderstood or misused?

Alena Holligan:
I would really like to get beyond the fact that people try to use object oriented concepts to sound smart. Don't throw a polymorphism out as a way to sound smart. Explain the concept? Explain what part of polymorphism actually makes sense here? What do I need to know about polymorphism? Or what piece of polymorphism am I using here?

Alena Holligan:
And so I would say for me especially one of the things that I found most challenging and what tripped me up the most was not being able to understand that answers. So you'd Google something and Google should be great and you should be able to find answers. And yeah, there's all kinds of answers and they've all, yeah, this is the way, this is exactly how it works. And they have words in there that just confuse you even more than you were to start with. And that I think is the really one of the biggest challenges.

Matt Stauffer:
I love that. And I think that you've used that reference. And I love that reference because I definitely remember Googling things and seeing three sentences worth of stuff and whether or not I knew all the words and I frequently didn't.

Matt Stauffer:
It's obviously implying a context that I don't have. And so I'm like, I know that's English, but it means nothing to me. And I also of course love what you're saying here about not using to sound smart both because I think we should just be kind to each other. But also I don't think that the more specific words are the more potential they have for us to use to communicate them well. I get teased a lot for using big words, but the big words I use are because that was the word that most communicated the thing I was thinking.

Matt Stauffer:
And I could have used a simpler more word or whatever, but it wouldn't have been as accurate. And so those words have so much power for communication when we use them in ways that further communication. But if we use them in moments or contexts or whatever else where the purpose is not communication or even if we're not trying to do it, to make ourselves look good. If we're not thoughtful and empathetic to the person we're talking to, to understand and ensure that they understand what we're saying, we're actually decreasing communication by using that word. And so it's a little bit about reading the room. Understand who you're talking to and if you don't know, ask. And make sure that you're using those words in ways that make sense to them. And also don't shame them if the answer, I don't know.

Matt Stauffer:
One of the things that we've in hiring a Titan, and I'm sorry, I'll stop going just one second. One of the biggest things somebody can do at Titan to ensure they don't get a job during the application process is to pretend like they know something and we can tell that they don't know it. Because if you do that, then we can't teach you and we can't work with you because you're going to hurt us and you're going to hurt yourself. You're not going to grow.

Matt Stauffer:
And some people do out of arrogance, but most people do it out of not wanting to look dumb when they're interviewing. It's a totally understandable thing. The problem is doing that keeps you from learning the thing. And so developing the practice of saying. "You know what? I'm not sure what does that mean." On the one side it's really helpful. And the other side saying, "Yeah, I really think we should use polymorphism. Does that make sense or should I kind of go in a little bit more detailed?" Both as non-condescending, peaceful, humble things that we can do to just ensure that we're communicating well. Thank you for bringing that up because that's fantastic.

Alena Holligan:
I'm applauding. I love the use of words where their meaning is clear and that word describes what you're talking about, and that's great. And so really it's about are you breaking down this concept to explain it or are you using these words because you really can't even go into the details of how that works.

Alena Holligan:
Well, I know it's encapsulation, so I'll just use that word. How is encapsulation working here? Well, I don't really know how to explain that to you, so I'm not. And so instead of making yourself feel bad or take that extra time to figure out how to explain it and maybe make you better, you've shoved off your lack of knowledge to somebody else so they feel bad instead of you.

Alena Holligan:
So just be careful that you're not using words in a way to be like, "I don't want to get any further into this concept. This is how much I can explain it. So I'm just going to stop here. I'm going to stop with this word instead of going into the word when that actually answers the question."

Matt Stauffer:
Once again, I love this and let's go, we got two more questions and then I want to ask some learning things. So the first question is, what if any piece or tool or anything of object to our new programming, do you think that people should be using more? Is there something where you said, "Man, I see so many problems pop up that if people were just to use XYZ, they would realize that it's actually solved within the city LG that they're are working in? Or is there nothing that really sticks out for you for that?"

Alena Holligan:
Well two things which kind of build on each other. One, I'm so glad that you already had Jodie on about Composer. I think Composer has been fantastic that it's probably been, to me one of the biggest tools that object oriented made possible. That is super helpful If you don't learn any other tool, you learn Composer. And it's so much more than just a package management, yeah. And that really brings into namespaces again, which is another place where people get hung up on and being able to do auto loading, which is really useful. Those are things looking to Composer that they're great.

Alena Holligan:
But again, name spacing, it's another concept that like, "Oh well, yeah, it's too hard or whatever. I just I don't get it." Or people just assume people know what it is, yeah, just namespace it. If you don't understand it, again, it's really easy to not be able to use it right. So, again, really important things there. Composers is a great place to look at doing that type of thing.

Matt Stauffer:
And if you're not familiar with namespaces, they're basically folders for your classes but the big difference is you're referencing the folder structure when you're referencing those classes. So if you throw it in a different folder, then now the way to reference that class later now has to reference the change in folder. And the good thing about what Alena's saying here is that when you're using PSR for auto loading and using Composer to auto it bringing in your own custom code usually really actually means that in order to change something's namespace you just A, move it to a different folder, and then B, change the line at the top that says namespace. And there's tons of great tutorials out there for you. But in general, that's how I start. You're laughing, is there-

Alena Holligan:
You got into namespace and I'm like, I didn't want to get into so-

Matt Stauffer:
Okay, I will shut up.

Alena Holligan:
No, no, no, no, no. I love it. And it's another thing, name spacing this is another one like, okay, think of name spacing. Your application is the main land. And for name spacing you're always using namespaces even in PHP, even if you don't think so. There's a global namespace. So you're using the global namespace. You're always using a namespace. So your mainland is your application. Your application is the mainland to use anything on any island, which are multiple islands around, those are the other people's code that you're pulling in. These packages that you're pulling in.

Alena Holligan:
And to use them, you have to do two things. First off, you have to have a connection to that island and then you have to tell it that that's the island to go to.

Alena Holligan:
And those are the things to remember in using namespaces because that's where you have the use clause, or the name spacing. I need to know this code is on which island, so we name it. I'm in this on this island. And then to use that first my application has to have a bridge there. And often that's most likely going to be your auto loading things. But you will also make that bridge by going either specifically saying follow this bridge or when you're calling it, go across this bridge to get your box. Or go across this bridge to get your box.

Alena Holligan:
Or you can say at the top set up this bridge. I'm now going to call this bridge A and this bridge B. So use A to get the box or use B to get the box. You need to have both of those. And if you don't have the bridge already, you can't just say go get a box because it doesn't know where to get the box from. And so that's the trick I think people run into with name spacing is what's this long path or what's the use at the top? Well, first you have to have that. Build that bridge first and then tell it where you want to go, which one to go to.

Matt Stauffer:
Yeah. I love it and obviously this yet another topic we can nerd out on forever. But I will go here and I'll ask you, is there anything else before we start wrapping up that you really think that we should have talked about that we didn't get a chance to cover yet?

Alena Holligan:
Be kind to yourself.

Matt Stauffer:
Came on.

Alena Holligan:
Be kind to yourself, object oriented. You don't have to know it all at once, but learning a little bit more, learning as you go, getting better. That's the whole idea of refactoring code. Refactoring to me is something that we always have to do. We are always refactoring ourselves. We're always refactoring our code. As you learn better, do better.

Matt Stauffer:
That's so good.

Alena Holligan:
But don't beat yourself up over what you don't know now.

Matt Stauffer:
Yeah. And interestingly, that's both like a life philosophy, which I love and I appreciate you saying it. But even for someone who has been writing Object-Oriented Programming for a long time, the worst thing that happens to me with Object-Oriented Programming today is if I get paralyzed by needing to get the object relationships and definitions perfect at the beginning.

Matt Stauffer:
And so what is most useful to me in OOP today when I'm especially writing new objects and stuff like that is just to write something. And then as I start using it to figure out, wow, there's way too many methods here. This should be extracted. Or these three methods are all passing the same object between them. Maybe they should be extracted and then store that object as a property on the thing, whatever. And so it's even in the actual practice of being an experienced programmer writing, OOP, there's that same thing. Don't try to get it perfect. Do what you have, refactor it, get your tests. It's that same thing that's in a lot of ways to places. So thank you, Alena. All right. So if somebody wants to learn more what were some good places that they could look to, to learn about OOP?

Alena Holligan:
You can find me on Twitter, AlenaHolligan most places or sketchings. I'm sketchings on GitHub. On my GitHub repo I have a lot of sample code for beginners. We just did a training with Ed Bernard. I just did a training with Ed Bernard for Midwest PHP Conference online where it was a whole two days of beginner tracks with stuff there. So there are code samples and all of our slides are shared there. So you can find all kinds of stuff there and tweet me if you have something specific.

Matt Stauffer:
I love it.

Alena Holligan:
And I'm sure you have lots of other good resources we can link to.

Matt Stauffer:
Yeah, and I'll put a couple of links in the show notes and one of those will probably end up being Laracasts because I know you all love Laracasts as do I. And he covers all these stuff.

Alena Holligan:
Yeah, he does.

Matt Stauffer:
But I'll make sure that I link to all of Alena's stuff and all those things in the show notes will have all that. So go check them out. This is going to be a very rich set of show notes this time. So definitely check it out.

Matt Stauffer:
So the last thing before we go for today is one personal fun thing at the end for everybody. And I have not seen Portlandia, but I have a certain idea in my head when I think of Portland. And right now it is May 8th and behind you there is sunlight and leaves and it looks like it's like a beautiful, perfect windy day. And I know that Portland has a little bit of this reputation of being like rainy all the time. So I just want to ask you, as someone who's been there for six years who's not from there, what do you love the most about Portland?

Alena Holligan:
Oh, the most, one thing?

Matt Stauffer:
One or two or three. Keep under four.

Alena Holligan:
The tech community is great. The food scene is great. Being able to get fresh... I have a friend where I get my eggs and my meat. And just growing vegetables and having a garden and the weather. We have weather. I spent most of my life in Arizona. It was just hot and hotter and we actually have weather here. It changes. I enjoy that, the change in weather and it's not so hot and we don't have a lot of bugs, which is another consideration. There are not a lot of bugs. So all in all, that's pretty ideal. My husband and I did a lot of searching on where we would like to go and ended up in Portland and we're very happy.

Matt Stauffer:
You're happy with your decision. I love it.

Alena Holligan:
Yes.

Matt Stauffer:
Well, Alena, it was an incredible pleasure talking to you as always with people who are wonderful. I could have talked for another three hours, but let's keep it short for the people. So thank you for your time. As always you can follow her on all these plugs she's already made will be in the show notes. And thank you for joining me. It's been a ton of fun.

Alena Holligan:
Yeah, I had a good time too. It's nice to talk to you.

Matt Stauffer:
You as well. Alright. See you all later.