Chapters

13 Chapters | 1:08:56 |

01

Service Classes

5:46
02

An Army of Service Classes

4:13
03

Sharpening the Battle Result with a Class

8:12
04

Optional type-hinting & Semantic Methods

3:17
05

Objects are Passed by Reference

4:05
06

Fetching Objects from the Database

6:10
07

Handling the Object Id

9:33
08

Making only one DB Connection with a Property

3:53
09

OO Best Practice: Centralizing Configuration

5:51
10

OO Best Practice: Centralizing the Connection

3:47
11

Service Container

4:08
12

Container: Force Single Objects, Celebrate

4:45
13

Container to the Rescue

5:16

> Drupal 8 > OOP (Course 2): Services, Dependency Injection and Containers

Buy Access to Course

04.

Optional type-hinting & Semantic Methods

|

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $6.00

Previous Chapter

Next Chapter

Script
Comments

Login or Register to check out the script

9 Comments

Sort By

Login or Register to join the conversation

DXS 2 years ago

I know that this is a older course, but nowdays as i speak in PHP you can actually put null as ? (question mark):

final class BattleResult
{
    private bool $usedJediPowers;
    private ?Ship $winningShip;
    private ?Ship $losingShip;

    public function __construct($usedJediPowers, ?Ship $winningShip, ?Ship $losingShip)
    {
        $this->usedJediPowers = $usedJediPowers;
        $this->winningShip = $winningShip;
        $this->losingShip = $losingShip;
    }

    public function getWinningShip(): ?Ship
    {
        return $this->winningShip;
    }

    public function getLosingShip(): ?Ship
    {
        return $this->losingShip;
    }

    public function wereJediPowersUsed(): bool
    {
        return $this->usedJediPowers;
    }
}

|

Victor SFCASTS DXS 2 years ago

Hey DXS,

Yes, good catch! You're correct, in modern PHP (starting from PHP 7.1), you can use nullable types if you want e.g. those properties allow null values, i.e. be nullable. So in your specific example $this->winningShip property may be either null or an instance of a Ship class. The same is true for $this->losingShip property.

Cheers!

1 |

Serhii75 7 years ago edited

Hi
My question is about the isThereAWinner method. You have access to private properties inside the class. So, could you please explain why don't you use just:
return $this->winningShip != null;
instead of
return $this->getWinningShip() !== null;
?

I mean, what is the advantage of using method in such cases?

|

Victor SFCASTS Serhii75 7 years ago

Hey Serhii,

Sorry for the late replay, we had temporary outage with Disqus comments synchronization :/

About your question, are you asking about calling method vs calling property directly? Or are you asking about the difference between "!= null" and "!== null"?

Well, actually, if we're talking about simple getters that just return values - I'd recommend you to access property directly, i.e. call "$this->winningShip". First of all, maybe if you would do so - you even won't need that getWinningShip() method at all? If so, that's great. But if you still call that getWinningShip() somewhere outside the class, I'd still recommend you access properties directly in class, easier for refactoring in the future I think, but it depends. So, there's no a big difference at all.

But Abiola below also have a good point, but as I said, it depends on the case, don't think too much about it. ;)

Cheers!

1 |

Serhii75 Victor 7 years ago

Hi!
Thanks for your answer! My question was about calling method vs calling property. As I said below in my reply to Abiola, when I faced a real challenge, I understood the advantage of calling the method. And I also agree with you - it depends on situation.
PS. What about != and !== I know the difference. I should write !== and even better use Yoda conditions, I mean null !== $this->getWinningShip()

|

MolloKhan SFCASTS Serhii75 7 years ago edited

Hey Serhii75

You should use !== every time you can, it's just safer, if you find yourself with the need of using "normal" comparison (!=), you should take a minute and find out why you need it.

About Yoda conditions, well, personally, I don't like them but it's a standard in Symfony internals, so it's up to you if you want to adopt it or not :)

Cheers!

|

Abiola M Serhii75 7 years ago edited

Serhii75 I see your point. I suppose the advantage is 'future-proofing'.

Such that in future if additional logic is ever needed before outputting the winningShip, the logic would definitely sit within getWinningShip() method and then we would not need to worry about adding this additional logic to places where winningShip might have been used directly.

|

Serhii75 Abiola M 7 years ago

Thanks for the explanation! And I have to say that just recently in the process of refactoring I just encountered this situation and now I understand better that the method is preferred (yes, you are right, talking about additional logic)

|

Victor SFCASTS Abiola M 7 years ago

Hey Abiola,

Thanks for sharing your thoughts on it! Makes sense as well.

Cheers!

|

Previous Chapter

Next Chapter