I would much rather prefer just checking whether the value is null. No matter which approach you implement, it's going to get harder to read and harder to maintain.
It’s more systematic than that. Having to check for nulls probably means the business does not understand it’s domain or that it understands it’s domain but chooses to treat its entities as bags of fields to be queried or mutated. When you think specifically about the domain and the operations happening in the domain then you can make these bulls go away or at the least push them down into the infrastructure layer into a single place. Rest and resource controllers etc have made us think in terms of CRUD.
@@Ffaarg7 I think building your infrastructure around dealing with nullable fields is a terrible idea. The author states that "Using null in code causes uncertainty and doubt". I couldn't disagree more with this statement. This comment is a perfect example, that the domain and the operations happening within the domain should not be translated directly into object infrastructure. From a domain- and object oriented perspective, it makes sense to use this "null pattern", but in reality it provides zero business value, as there is already a common consensus on how to use null properties in modern code. It's only going to increase costs of development and confuse any developer coming from the outside.
Everything you are about to develop, except purpose specific algorithms are just CRUD. No matter how many layers of abstractions you will use, you still do CRUD.
The "we want to show an empty string" part ~@4:05 is the main reason you SHOULD probably use NULL in PHP. Since the "show empty string" part is only the case in your current business flow/context. Maybe you want it to be 0000-00-00 00:00:00, maybe you want it to default to when your system was first online, maybe you don't want to show that "posted at" date if it was not "published" on some UI interfaces. So in that case, NULL could simply mean a value "not currently set". And since PHP has `??= `, it makes it really easy to set defaults.
So, the alternative is to convert null to 0000-00-00 when running it through a date function? That's insanity. The problem isn't null, it's your chedder code.
This is why optionals were made. To reduce that cognitive load, as then we'll be aware through typing alone that checking the presence of a value is necessary. The issue then is that an optional wrapper object can be null, but at that point it's just the fault of someone writing the code and not faulty logic.
This is a perfect example how to turn a solution into a problem, add useless classes, an even more useless interface and lose the notion that a value may not be set. Great job ...
If you are not checking for null that means it is not suppose to be null. Just because a program is not crashing or throws exception does NOT mean it is correct. Imagine seeing your production database with empty string every where, now good luck trying to figure out where that empty string is coming from in your 50,000+ lines of code with 100 developers. At least with null it would fail fast crash immediately throw a stack and tell which developer did a bad thing. That is much better than writing the supposed correct value of empty string in all your customers account. Good luck trying to restore the prod db from backup or figure out which customer account was screwed.
I don't understand how you're saving cognitive load... you still have to think about how to deal with null in your app but now it's an empty string instead. And that takes away the flexibility. What if you want to show the null date as "no date" instead of an empty string? What if you have a conditional based on the null date? Feels like over-engineering to me.
the issue with your null objects is that you actively move business logic to them which may not always be desired. making the choice where it is needed is far cleaned and also less mental overhead, not more
Honestly now that we have optional types with the question mark, I don’t agree you always have to think about null. You can see right in the type definition whether you should check for null, or even if you forget your IDE will remind you. That works fine, really
I don't like this NULL-pattern-approach, it is just a workaround for an invalid data-state. In this example every post should have a created-Date. In the end, the same problem exists for all kind of data, which comes from db. So you also could implement a missing case for everything (to avoid "strtolower expects a string, got null" and so on).
Thank you for pointing out the null topic. Like to refresh the basics from time to time. As you mentioned in the video a good way to handle null is to use strict typing and accept only types you want to have. I understand the problem with cognitive load. In my opinion your selected example is too small to justify introduction of several classes. You presenting a solid concept but with the current example you increase the load too much. For smaller situations like this I go for a helper method or a service function. Laravel brings also an interesting approach with macros. Beside that I use guard classes as a concept to group some of my preconditions at the beginning of a method and can focus after that on my functionality.
How much overhead would we want to introduce? EA-Inspections, PHPStan and proper Unit tests are all we need (as much as I understand the congnitive load issue).
The way you write OOP PHP makes me feel like I've been working on a different language for the last months... Do Anyone know a good free crash course or article or something on this "more complete" OOP PHP?
Hey there, glad to learn from you. SELECT TOP 3 * FROM Table; Would the first three selected records in that syntax display the latest records inserted into the table by default? So Top 3 records are the newest 3 records inserted into the table. Am I right? Thanks for taking care of this.
This remind me of NULLPOINTER exception in Java. The most popular error in Object Oriented programming. Javascript actually make the null an object. Php also treat null a special type. Basically, you can't get rid of. It's itself a placeholder of empty object in memory. That's assembly stuff!!!
Thank you. Very interesting. I believe the presence of nulls in domain interfaces is a sign that your domain needs fixing. This is especially true when you have lots of business partners who will be using your services. You try an accommodate them by adding data that belongs outside your domain inside your domain and then litter your domain with branches to take into account all the different use cases which now need to be be identified. If you go fully into ddd then your user interface is never a CRUD interface anyway.
thanks a lot for this cool video ... i didn't think of nulls like that before :D not related to tech ... can we know your camera gear & lighting to shoot this great video
This no problem with null. On your example, if a post can have optional publication date (as you said, if post not published, the date is not set), then you should expect it to be possibly null -- this is nothing wrong with that. On the other hand, if let say post title can never be null (by design), then you never check if its null -- you just use. In the moment when it get null, the code crashes which will indicate the is a bug (in code, if title suddenly was desided to possibly be null and old code is didnt support it OR bug in data source (like database). If you create a server handler, that is totally OK to fail with some http code 500, that it why those codes exists after all. If you create a client part (some app, or website, any UI for end user), you have to try catch large block of code (no need to test each thing with "if" branch) and catch the failure and do what is best at that point. By the way, at this point you also have to decide, what is more important: 1) show only valid data, if you cannot -- ask user to "try latter" or show explanation message -- never misinform user; 2) or you OK to show any data, like if publish date is not valid (null) and you show anything just so you get rid of null in your code :)
I hate nullable properties (and their respective getters and setters) that are nullable only before validation but after they should not. From business point of view they are no longer nullable after validation but technically (and for static analyzers) they still are. For now the only solution that I've found is to write separated model for validation and for my domain logic. But that creates a lot of boilerplate and duplicated code,as the only difference is this "?" removed from the declaration.
How are you storing this data? Normalizing the (relational?) database, by creating two tables, will fix that. One table for drafts, one for published works. We should remember that there is a truth to data and nothing exists that doesn't exist; it either exists, or it's meta and can be normalized away.
I don’t think you need 2 tables. But you could store the publishedAt in another table and avoid the null. And your domain model does not need a 1 to 1 correspondence with your db model.
In my opinion, null object pattern is outdated to modern languages and adds even more unneeded cognitive complexity. Its creating multiple types of "null" which is not actually null and you are always forced to think in that way. Modern PHP is so much more developer friendly when it comes to working with nulls.
Seems like this pattern is most useful, when you use a type like PublishedPost alot in your codebase. If you use another type like that only a few times, writing the extra classes seems like more work than the nullchecks. As Aleksandr has pointed out, please look into Option monads. It does almost the same abstraction, but is a generic type, that can be used for all situations similar to this :)
Is good that null exists! For me null means unassigned (i know it sounds wierd since you can assign null) but is the simplest unassign check that can applied to any type
Yep, null is a nuisance. In fact Microsoft changed their C# syntax recently so you could enable or disable null support for any type. For example "string" doesn't suppose to contain null but "string?" does. It so much easier now, I wonder why they didn't implement it natively in the first place instead of sugaring syntax.
So instead of a simple null check I'll write multiple classes implementing some interface. What if the blog post had a property "updated_by" referencing User class? If the post was not edited by anyone this property should be null, right? So what would you do now? Create a UserNull object for User entity with an interface declaring every User method? This makes no sense, it's really not worth the effort. The boilerplate argument is thrown out of window because you are increasing the codebase substantially, adding unnecessary complexity to your code that your colleagues would really love you for and every change you would want to introduce in an User object you would have to change it in two different classes just because it's too much of a cognitive load to check if the value is defined... not to mention PHP has bunch of useful null operators (even more since PHP 8). No thank you.
One way around writing "if" checks to guard against null reference errors is to write a Utility function that takes in an object and will either return the object itself or an empty string if the input object is null. Of course, this could turn into InvalidFormatExceptions if you're trying to convert or format an empty string, but at least the null exceptions would go away.
so what all these "programming" channels on youtube is that every programming language is flawed, I'm shit, everyones shit and nobody should ever code. You guys are blowing up non-existant problems to get internet fame, either you are a coder or you're just not. either you're fit for the job or you are not. if simple stuff like this triggers you, then sorry.
I think the only one triggered here is you 😄 I think trying to reflect critically on stuff you do every day will bring you forward even if you think it may not need thinking about.
I would much rather prefer just checking whether the value is null. No matter which approach you implement, it's going to get harder to read and harder to maintain.
It’s more systematic than that. Having to check for nulls probably means the business does not understand it’s domain or that it understands it’s domain but chooses to treat its entities as bags of fields to be queried or mutated. When you think specifically about the domain and the operations happening in the domain then you can make these bulls go away or at the least push them down into the infrastructure layer into a single place. Rest and resource controllers etc have made us think in terms of CRUD.
@@Ffaarg7 I think building your infrastructure around dealing with nullable fields is a terrible idea. The author states that "Using null in code causes uncertainty and doubt". I couldn't disagree more with this statement. This comment is a perfect example, that the domain and the operations happening within the domain should not be translated directly into object infrastructure. From a domain- and object oriented perspective, it makes sense to use this "null pattern", but in reality it provides zero business value, as there is already a common consensus on how to use null properties in modern code. It's only going to increase costs of development and confuse any developer coming from the outside.
@@hejloldetermig3850 Only if you hold onto the CRUD resource orientated mindset of development.
Everything you are about to develop, except purpose specific algorithms are just CRUD. No matter how many layers of abstractions you will use, you still do CRUD.
The "we want to show an empty string" part ~@4:05 is the main reason you SHOULD probably use NULL in PHP. Since the "show empty string" part is only the case in your current business flow/context. Maybe you want it to be 0000-00-00 00:00:00, maybe you want it to default to when your system was first online, maybe you don't want to show that "posted at" date if it was not "published" on some UI interfaces. So in that case, NULL could simply mean a value "not currently set". And since PHP has `??= `, it makes it really easy to set defaults.
So, the alternative is to convert null to 0000-00-00 when running it through a date function? That's insanity. The problem isn't null, it's your chedder code.
This is why optionals were made. To reduce that cognitive load, as then we'll be aware through typing alone that checking the presence of a value is necessary. The issue then is that an optional wrapper object can be null, but at that point it's just the fault of someone writing the code and not faulty logic.
This is a perfect example how to turn a solution into a problem, add useless classes, an even more useless interface and lose the notion that a value may not be set.
Great job ...
I'm not convinced of this, I prefer to use null and performs all the checks because they are important and can change from a situation to another.
If you are not checking for null that means it is not suppose to be null. Just because a program is not crashing or throws exception does NOT mean it is correct. Imagine seeing your production database with empty string every where, now good luck trying to figure out where that empty string is coming from in your 50,000+ lines of code with 100 developers. At least with null it would fail fast crash immediately throw a stack and tell which developer did a bad thing. That is much better than writing the supposed correct value of empty string in all your customers account. Good luck trying to restore the prod db from backup or figure out which customer account was screwed.
I don't think null is something we should get rid of.
I don't understand how you're saving cognitive load... you still have to think about how to deal with null in your app but now it's an empty string instead.
And that takes away the flexibility. What if you want to show the null date as "no date" instead of an empty string?
What if you have a conditional based on the null date?
Feels like over-engineering to me.
Just couple more steps and we arrive at NullObject / Maybe monad / Optional type
the issue with your null objects is that you actively move business logic to them which may not always be desired.
making the choice where it is needed is far cleaned and also less mental overhead, not more
Honestly now that we have optional types with the question mark, I don’t agree you always have to think about null. You can see right in the type definition whether you should check for null, or even if you forget your IDE will remind you. That works fine, really
I don't like this NULL-pattern-approach, it is just a workaround for an invalid data-state. In this example every post should have a created-Date. In the end, the same problem exists for all kind of data, which comes from db. So you also could implement a missing case for everything (to avoid "strtolower expects a string, got null" and so on).
Thank you for pointing out the null topic. Like to refresh the basics from time to time.
As you mentioned in the video a good way to handle null is to use strict typing and accept only types you want to have.
I understand the problem with cognitive load. In my opinion your selected example is too small to justify introduction of several classes. You presenting a solid concept but with the current example you increase the load too much.
For smaller situations like this I go for a helper method or a service function. Laravel brings also an interesting approach with macros.
Beside that I use guard classes as a concept to group some of my preconditions at the beginning of a method and can focus after that on my functionality.
i cant find you on audea - can you post audio versions of your videos there? would love to listen to them! thanks again for the great content!
Nice idea for the “null pattern”, thanks. Going to implement it
How much overhead would we want to introduce? EA-Inspections, PHPStan and proper Unit tests are all we need (as much as I understand the congnitive load issue).
The way you write OOP PHP makes me feel like I've been working on a different language for the last months... Do Anyone know a good free crash course or article or something on this "more complete" OOP PHP?
Thank you for this! Super cool video! A+++
Great video. A video on DDD would be awesome.
What if there are no possible "default" values to use? For example, an object that has to be instantiated right away. Something like a File object.
What about Doctrine and DraftPost + PublishedPost? Two tables?
Hey there, glad to learn from you.
SELECT TOP 3 * FROM Table;
Would the first three selected records in that syntax display the latest records inserted into the table by default?
So Top 3 records are the newest 3 records inserted into the table.
Am I right?
Thanks for taking care of this.
This remind me of NULLPOINTER exception in Java. The most popular error in Object Oriented programming. Javascript actually make the null an object. Php also treat null a special type. Basically, you can't get rid of. It's itself a placeholder of empty object in memory. That's assembly stuff!!!
Thank you. Very interesting. I believe the presence of nulls in domain interfaces is a sign that your domain needs fixing. This is especially true when you have lots of business partners who will be using your services. You try an accommodate them by adding data that belongs outside your domain inside your domain and then litter your domain with branches to take into account all the different use cases which now need to be be identified. If you go fully into ddd then your user interface is never a CRUD interface anyway.
thanks a lot for this cool video ... i didn't think of nulls like that before :D
not related to tech ... can we know your camera gear & lighting to shoot this great video
This no problem with null.
On your example, if a post can have optional publication date (as you said, if post not published, the date is not set), then you should expect it to be possibly null -- this is nothing wrong with that.
On the other hand, if let say post title can never be null (by design), then you never check if its null -- you just use. In the moment when it get null, the code crashes which will indicate the is a bug (in code, if title suddenly was desided to possibly be null and old code is didnt support it OR bug in data source (like database).
If you create a server handler, that is totally OK to fail with some http code 500, that it why those codes exists after all. If you create a client part (some app, or website, any UI for end user), you have to try catch large block of code (no need to test each thing with "if" branch) and catch the failure and do what is best at that point. By the way, at this point you also have to decide, what is more important: 1) show only valid data, if you cannot -- ask user to "try latter" or show explanation message -- never misinform user; 2) or you OK to show any data, like if publish date is not valid (null) and you show anything just so you get rid of null in your code :)
I agree with your point about the cognitive load of always having to think about the null case, it's a constant hindrance
This is very interesting and I've learned a lot from it!
I hate nullable properties (and their respective getters and setters) that are nullable only before validation but after they should not. From business point of view they are no longer nullable after validation but technically (and for static analyzers) they still are.
For now the only solution that I've found is to write separated model for validation and for my domain logic. But that creates a lot of boilerplate and duplicated code,as the only difference is this "?" removed from the declaration.
Thank you for sharing your point of view and solution but, I would like to continue checking on null other then creating interfaces and new types 🤷♂️
Спасибо
How are you storing this data?
Normalizing the (relational?) database, by creating two tables, will fix that. One table for drafts, one for published works. We should remember that there is a truth to data and nothing exists that doesn't exist; it either exists, or it's meta and can be normalized away.
I don’t think you need 2 tables. But you could store the publishedAt in another table and avoid the null. And your domain model does not need a 1 to 1 correspondence with your db model.
What about Booleans? Are you worried if they will be true or false? 😋
In my opinion, null object pattern is outdated to modern languages and adds even more unneeded cognitive complexity. Its creating multiple types of "null" which is not actually null and you are always forced to think in that way. Modern PHP is so much more developer friendly when it comes to working with nulls.
Seems like this pattern is most useful, when you use a type like PublishedPost alot in your codebase. If you use another type like that only a few times, writing the extra classes seems like more work than the nullchecks.
As Aleksandr has pointed out, please look into Option monads. It does almost the same abstraction, but is a generic type, that can be used for all situations similar to this :)
You came up with a problem and solved it, great job :D
he came up with a solution and turned it into a problem
Is good that null exists! For me null means unassigned (i know it sounds wierd since you can assign null) but is the simplest unassign check that can applied to any type
Exactly. Null means the value is undefined and this example feels like dancing around an undefined value than addressing it for what it is
Enriching content as always Thank you @brent
How about storing a value other than NULL as the publication date? It would help alot with this mess.
Rust does not have null
Yep, null is a nuisance. In fact Microsoft changed their C# syntax recently so you could enable or disable null support for any type. For example "string" doesn't suppose to contain null but "string?" does. It so much easier now, I wonder why they didn't implement it natively in the first place instead of sugaring syntax.
Started as a Java clone. Later copied kotlin’s null safety type system
So instead of a simple null check I'll write multiple classes implementing some interface.
What if the blog post had a property "updated_by" referencing User class? If the post was not edited by anyone this property should be null, right? So what would you do now? Create a UserNull object for User entity with an interface declaring every User method? This makes no sense, it's really not worth the effort. The boilerplate argument is thrown out of window because you are increasing the codebase substantially, adding unnecessary complexity to your code that your colleagues would really love you for and every change you would want to introduce in an User object you would have to change it in two different classes just because it's too much of a cognitive load to check if the value is defined... not to mention PHP has bunch of useful null operators (even more since PHP 8).
No thank you.
How to relax as a developer? Ignore null, let phpstan do it's job, and fix what needs fixing :D
Hiding it to the database is something I do a lot in my symphony projects. It's super easy with custom DBAL types
symPHony ?
@@miguelgd1985 Symfony :)
Symphpony 🤭🤭🤭
watching this at 404 views haha :)
One way around writing "if" checks to guard against null reference errors is to write a Utility function that takes in an object and will either return the object itself or an empty string if the input object is null. Of course, this could turn into InvalidFormatExceptions if you're trying to convert or format an empty string, but at least the null exceptions would go away.
👏
I'm so used to using null's that I just don't bother about those check's, I gues.... But I found interesting the DDD approach, that you've mention
so what all these "programming" channels on youtube is that every programming language is flawed, I'm shit, everyones shit and nobody should ever code. You guys are blowing up non-existant problems to get internet fame, either you are a coder or you're just not. either you're fit for the job or you are not. if simple stuff like this triggers you, then sorry.
I think the only one triggered here is you 😄 I think trying to reflect critically on stuff you do every day will bring you forward even if you think it may not need thinking about.