Null Object Design Pattern in C#
Uploader Comments (ChocolateForDogs)
Top Comments
-
Isn’t there a problem here because NullCar.SpeedUp do nothing carToDrive.CurrentSpeed will always be 0 and (carToDrive.CurrentSpeed < maxSpeedDecired) always be true so we will get an infinite loop – or did I miss something? I know it has nothing with the Null Object pattern to do, but it is a risk that arises due to the way the pattern is used here .
-
Correct me if i'm wrong, but didn't you just create an infinite loop? The while loop seems to never be able to complete if you pass in the NullCar. Otherwise, good explanation on the concept :)
All Comments (18)
-
Late response but just thought I'd share it anyway in case any new viewers read it: NullObject is really not useful in situations where you read values from that object (like in this case reading CurrentSpeed). Instead, you use it in places where you either only write to it or call methods (like SpeedUp).
In this example, Car should be changed to have the check moved into it by adding a method called IsSpeedExceeding(value) where value is maxSpeedDesired). In such a case, the example will work.
-
Writing the text file of subanalytical and ergonomical processes can be a somewhat forensical adversity, as it can result in some pre-made errors and overwhelming discrepancy. However, over the years c++ compilers and engineers have found numerous methods of advancing the techniques utilized in post-subconjuring encryption and ethonopoly. But the treatment of input and output for C3PO computers has readily made using software peripherals and code that much more effective.
-
This video is great. It shows exactly why null objects shouldn't be used, thanks :)
-
nice, but in your example, your while loop is an endless loop :D
when you get your nullcar, speedup() does nothing, so :
while (carToDrive.CurrentSpeed < maxSpeedDesired){ carToDrive.SpeedUp();
}
this is endless, it will never reach maxSpeedDesired
-
Hi.. Thanks for the video. Please post more of these..
-
I totally agree with Archangel Chi.. The video shows good techniques, but the pattern couldnt do more bad down the road.
It is WRONG to return null, emtpy objects, strings, whatever. In such case you should always throw an exception. That is what exceptions are for, otherwise you will end up with huge, painful, costly indiscrepancies in your data in the future.
-
Good video; except it may cause problems later. Mainly if you'd want to actually check if the object is null somewhere in the code. This means you'd have check the instance of or the type of the object - which is expensive.
It's a good pattern, in theory, but you have to be REALLY conscious of where you use it and what you're using it for; otherwise it will be a nightmare.
Also; remember - Singletons need a private constructor so they cannot be instantiated :)
-
This is a solution in search of a problem and the problem it finds is poor design - the solution it introduces is obfiscated, non-intuitive, "spooky" behavior. The car factory should never return a null (it should throw an exception if it's manufacturing parameters are invalid for its context then the condition can be dealt with at object creation) and it sure shouldn't return a phony object that pretends to be valid but does nothing - that produces unexpected behavior tough to debug later.
-
Hate his voice xD
Sorry for the poor quality on this -- it's my first attempt at posting a video. I'll see if I can't fix it somehow...
ChocolateForDogs 4 years ago