OOP (course 3): Inheritance, Abstract Classes, Interfaces and other amazing things

Hey! If you're interested I decided to do just that. I've used the screencast as a foundation to learn stuff like composer and unit testing. https://github.com/sjhuda/k.... The master branch contain what I have so far. I'm still wet behind the ears when it comes to OOP so I'm happy to take on any suggestions.

You'll see my composer.json has an autoload section with the namespace of the classes and the folder it lives in. In bootstrap.php I'm now just including composer's autoload.php (and db settings - but i'm going to move that into a .env file and hopefully do away with bootstrap.php). I had to go round each class and a namespace and look for any place I've used a class and include it at the top.

I loved this series and I think the project is a great foundation to build up our php skills. Up next - unit testing!

Thanks Neal!

Ah yes: we'll create either an episode 4 for OO and include it... or maybe put it in its own mini-episode. It's not something you need to practically take care of anymore due to Composer (of course, as long as you know how to configure it), but it's still a fascinating topic and something good to know!

Cheers!

Yo Milan V.!

Haha, love this! Especially:

> I've got my own life, so we'll be just friends, ok?

Very good tip with (1): using composition over using abstract classes. We do finally talk about composition at the end of the next tutorial: https://knpuniversity.com/s.... If you're reading this and aren't sure, don't worry too much: abstract classes are great and very useful. But then someday (especially if you are writing unit tests) you may find that abstract classes have some limitations, and inheritance becomes an even better option. Basically... this is what you are saying with tip (3) I think :).

About (2), I do (subjectively) warn users against creating their own interfaces unnecessarily in their own code.

> Imagine your application as a Lego -> You can pick whatever piece you want (e.g. The blue one) and when you dislike it, just pick the other (the red one) and the application still works perfectly!

This is SO true! But just make sure that you have a use-case for needing to change from the blue lego to the red lego. If you don't, creating your own interfaces adds a layer of abstraction... which means "misdirection"... which can be a bummer if you don't need it. Not having unnecessary interfaces can make your code easier to trace through.

Thanks for the real-world tips!

Cheers!

Yo weaverryan

Very true, mate :)

I would just add to (1): If you develop in other language than PHP (e.g. Golang) - there is no such a thing as an asbtract class, so you are ... kind of forced to use composition only.

Some good references are:
http://relistan.com/writing...

THIS is one of the best! It describes an application architecture (AKA which layers application consists of, where to use Interface, Dependency injection; etc... ):
https://appliedgo.net/di/

Basically when you are writing a component in your application and feel like it can be exchanged, OR if it will be exchanged for another component, that's the first sign you should use Interface.

Good example is the Repository. We are writing Repository for BoltDB in our Golang application. My collegues asked me if we will write a method `store model into database` for each repository. I responded like - Hey this is a perfect moment to use Interface, because we know which functions we will need in Repository layer. So we wrote a

// Go variable declaration in Go goes like: <name> <type>
`DatabaseInterface{
Store(model interface{}), // Store model into database
Get(id, type string), // Get model from database
//blabla (writing from top of my mind)
}`

This way we secured that our repository is expecting an object which will consinst of methods declared inside `DatabaseInterface` :)

Cheers :)

Ha, very interesting about GO! Really cool stuff :)

BTW, sorry for my Eng, I am really super tired today and didn't read it after myself, but I see mess I just wrote. :) (edited)

Yes, it's a very cool to have strong knowledges about OOP in PHP. There're a lot of CMS, frameworks and simply well designed libraries are exist for today which are written using OOP.

Hey Lukas,

First of all, it might be so that the challenge instance was corrupted during its creation and so it cannot save your changes. In this case, you just need to wait about 15 minutes and the system will recreate a new challenge instance from scratch. Basically, try again - it should work this time :) But if the problem persists - let us know!

Cheers!

You're right - we talk about a lot of great things in this tutorial, but we're saving traits for the future. I've removed "traits" from the description for this tutorial

Cheers!

Hey Volodymyr Vadiasov!

Ah, sorry about the issues! You're right - I can see some challenges failing to boot, that sucks! I'm working on it now - it doesn't affect all challenges, but may affect several of them. I'll update when things are smooth again.

Cheers!

Ok, all the challenges should be working again. Thanks for letting us know, and sorry for issues!

Cheers!

Hey gbillig

Thanks for informing us about it. We had an outage but everything should be back to normal now :)

Cheers!