Notes on "Elegant Objects (Volume 1)" - continued

Finishing Chapter 3!

Never Accept null Arguments

In OOP, this problem of an "absent argument" must be solved by a so-called "null object". You do not have anything to give me? Give me an object that behaves like it 's empty. Don 't put this problem on my shoulders by asking me to check whether you gave me an object or null.
I guess I again do not agree with the book.. This is what I go for..


Be Loyal and Immutable or Constant

Basically, there are three elements in every object: identity, state and behavior. Identity is what distinguishes an object from other objects, state is what object knows about the entity it represents and behavior is what the object can do for us on request. The main difference between immutable and mutable objects is that an immutable one does not have an identity and its state never changes. More precisely, immutable objects' identities are exactly the same as their states.
A perfect implementation of a Class should understand that and avoid duplicate instances, which encapsulate the same state. 
This is a very interesting suggestion to be honest. I am not experienced enough to evaluate that, but I think it would cause  a lot of weird problems..
Any system, regardless of its business and technical domains, can and must be designed entirely from immutable objects, including games, desktop apps, mobile apps, web apps, enterprise systems, etc..  
No comment!!!