search

dibley1973 / OpenRMS

Open RMS is an Open Source project with the intention of delivering a retail management platform that is free to install, use, modify and distribute.
GNU General Public License v3.0
9 stars 7 forks source link

Consider using "Null Object" pattern instead of using null to represent lack of an object #25

Open dibley1973 opened 8 years ago

dibley1973 commented 8 years ago

I strongly believe that NULLs are EVIL. I am happy to use the Maybe amplifier, but would also l would like to consider using the "Null Object" pattern to represent the lack of an object

dibley1973 commented 8 years ago

Worth watching the "Null Object Pattern" in PluralSight Patterns and Practice.

jadjare commented 8 years ago

This is a short article I was reading about avoiding nulls... No idea how authoritive the author is, but makes sense! http://gsscoder.github.io/2013/03/25/handling-nulls/

dibley1973 commented 8 years ago

@johncollinson2001 , @jadjare So do we agree to ALWAYS return an IEnumerable for any results that could return ZERO or more results? If so we can then close this issue.

johncollinson2001 commented 8 years ago

Sorry I've not had the time to watch the links. Are you proposing IEnumerable when it's know there will be Zero or One results? If so this seems odd.

jadjare commented 8 years ago

Sorry, I need to do more reading / watching Pluralsight course on the NullObject pattern, monads and the Maybe concept to comment.

Not had much time this week for openRMS, but will catch up soon.

jadjare commented 8 years ago

Based on my understanding and discussions (with @dibley1973) I'm concluding that the MayBe monad is currently unnecessary and is not adding much to code readability, e.g. if(result.HasValue)... var item=result.Single() //work on item is no more, or perhaps less readable than if(item!=null)... //Work on item

Using the NullObject pattern means that we create concrete class representations of null/empty objects and doing so negates the need for a MayBe when returning a single object, e.g.

var item = _itemRepository.Find(1);

//If we care about the presence of the object before acting then... 

if(item==Item.Empty) {
    //Complain about it
} 

//Or else just act on the item and an Empty implementation will swallow up the action / behave appropriately 

item.RemoveAllAttributes();

For methods that return a collection they should always return an instantiated collection whether empty or not.

Thus there's never (or rarely) nulls being passed around and calling methods make their own choice whether they care if something's empty/null before acting on it.

Does that meet your expectation @didley1973?