 Personally, I'm not a fan of the null object design pattern, and here's why. It's too broad, it's too open to interpretation, and you can drive yourself crazy doing this. So the intent of the null object is to encapsulate the absence of an object by providing a suitable alternative that offers suitable default do nothing behavior. What? That makes absolutely no sense. So if you have no object, you would have no behavior. But what they're saying with the null object pattern is have a behavior even if you don't have an object. Vastly open to interpretation, and you can see junior developers going crazy trying to figure out how to get around this pattern and how to make it work. So there are some general rules of thumb, but we're going to cover the cute way of doing it. So when I say the cute way, I have to kind of back up and say, I'm not really telling you the truth because this is so open to interpretation, you can do it millions of different ways. For example, in the queue object, right in the constructor uses this design pattern. If there's a parent, then cute is going to assume the memory management. If there's no parent, then the default behavior is that either the stack or you are going to manage that memory. So if this were created as a pointer, we would not be responsible unless we set a parent. Okay, so there's one interpretation. This logger class, which is very, very simple, is another interpretation of this. So we just simply are saying we're going to log some string value, but we also have to set a file. Of course, we're going to go ahead and check to see if that file even is in memory and if it's even writable. But then what is the default behavior? So let's look at our code here. So we have our logger, logger log, we have not set the file at this point. What's the default behavior? Okay, here we've set the file, but the file is not writable because we have not opened it. So we have different levels of default behavior we could really look at. And this is what I mean by you can really over engineer this if you wanted to. So we could take the easy route and say, okay, if there's no file, then let's go ahead and grab this and say queue warning, no file set. And then go ahead and return it out. And we could, you know, again, do it here, file not writable. And we could have done this a billion different ways. So for example, we could also move this up here and say the default is we will always print something out on the screen, but we'll also give a warning if we can't write to the file. Or we could actually open the file on the behalf of the user, like we could say try to open a file here. And then we would have to define what's the file name, where are we going to put it, what are the permissions, things like that, and we could do all sorts of craziness. You can drive yourself absolutely bonkers doing this. So in short, the null object pattern is not my favorite because it's so open to interpretation, but you need to be aware of it because Qt does use it. Now, general rules of thumb when you're using this, my personal preference, yours may differ. I try to avoid this. If there's no object, I take no behavior because what you're really relying on is the lack of object defining the behavior.