title: Am I breaking the "Law of Demeter"?
body: <p>I just recently became aware of the <a href="http://en.wikipedia.org/wiki/Law_of_Demeter" rel="noreferrer">Law of Demeter</a>.</p>
  
  <p>Like a lot of things, I realized that it was something that I was already doing but did not have a name for.  There are a few places though that I seem to violate it.</p>
  
  <p>For example...</p>
  
  <p>I might have an Address object:</p>
  
  <pre><code>public class Address : IAddress
  {
     public string StreetAddress { get; set; }
     public string City { get; set; }
     public int Zip { get; set; }
  }
  </code></pre>
  
  <p>and a Customer object:</p>
  
  <pre><code>public class Customer : ICustomer
  {
     private IAddress address;
  
     Customer()
     {
        Address = null;
     }
     public string Name { get; set; }
     public IAddress
     {
        get
        {
           if (address == null)
           {
              address = new Address();
           }
           return address;
        }
        set
        {
           address = value;
        }
     }
  }
  </code></pre>
  
  <p>Ok, this is fake code so you probably do not have to jump on me to use IoC to eliminate the <code>new Address()</code> or anything but it is pretty much an example of what I am doing.  I did not include the interfaces as I am hoping they are obvious.</p>
  
  <p>I would then use it in my code for stuff like <code>int zip = customer.Address.Zip;</code> and <code>customer.Address.City = "Vancouver";</code></p>
  
  <p>As I understand it, I am violating the Law of Demeter by manipulating details of Address from Customer.</p>
  
  <p>Then again, it seems like the framework does as well.  After all, wouldn't address.City.Length be a violation?  Should I be adding methods to Address to handle accessing string properties?  Probably not.  So, why clutter up Address?</p>
  
  <p>I cannot really just add methods to Address that relate only to customer.  I have Member, Employee, Dependent, Vendor, Employer, etc. objects that all have addresses too.</p>
  
  <p>Is there a better way to handle this?  What kinds of problems am I risking if I use Address the way I am now?</p>
  
  <p>For the Java folks, the Address class might look something more like the following if it helps:</p>
  
  <pre><code>public class Address extends AddressInterface
  {
     private String m_city;
  
     public String getCity() { return m_city; }
     public void setCity(String city) { m_city = city; }
  }
  </code></pre>
  
  <p>I must admit that <code>customer.getAddress().setCity("Vancouver");</code> rings more alarms than <code>customer.Address.City = "Vancouver";</code> did for me.  Maybe I should switch to Java for a while.</p>