Comments on: Properties – A False Sense of Encapsulation

By: Along Came Betty » Porting Soar to Java or: How I Learned to Stop Worrying and Love Spaghetti (Part 2)

Sat, 27 Dec 2008 03:35:18 +0000

[...] I want the Agent class to be straightforward without a bunch of yucky public members or just as yucky public accessors. I also want an interface that will allow me to refactor all these modules slowly over time [...]

By: Colin Jack

Colin Jack — Sun, 05 Oct 2008 19:56:33 +0000

Definitely going to give this a good read before responding but on the Time And Money example, I think this is a special case where you’re breaking the encapsulation provided by a simple value object (Money) to provide access to the “raw” value. Design wise that’s a very different world from using a property to allow you to set a Customers Address vs. using methods for get/set.

By: Jan Van Ryswyck

Jan Van Ryswyck — Sat, 04 Oct 2008 18:11:28 +0000

I have mixed feelings about automatic properties. To me, they like public member variables all over again.

I try to only incorporate a property when I’m with my back against the wall. If I can deliver cleaner code by incorporating a method, than I always choose for this option.

By: dcarver

dcarver — Fri, 03 Oct 2008 19:36:29 +0000

Maybe I am to old school on Object design. I always thought of properties as fairly obvious. For example location is a property. It probably should be readonly but it is a property of a person no matter what.

Changing location is a behavior of a person. So by allowing the user to change the location property without invoking a method (in this case) to re locate themselves seems wrong.

Color might be another good example. I can not change my color with out invoking some behavior (golaybythepool(…) – which right now sounds like a good idea).

So I guess I would say that you should expose the properties as read only, since they are properties of the object. Then provide methods to change readonly properties acording to the buisness rules.

Either way properties can include buisness rules as needed. I you want simple poperties you should use the new automatic properties in C# 3.0 and then they are truly simple properties with no buisness rules asssociated with them. By using automatic properties you enforce that restriction. That way if you write the code for a property get/set as above it would imply you have additional logic to enforce beyond setting the local variable..

By: Morten Lyhr

Morten Lyhr — Wed, 01 Oct 2008 20:02:44 +0000

You can read my view on Data Structures and Encapsulaed Objects here: http://morten.lyhr.dk/2008/10/data-structures-vs-encapsulation.html

By: Jan Van Ryswyck

Jan Van Ryswyck — Tue, 30 Sep 2008 17:46:24 +0000

@OAB: There are a lot of scenarios where Domain services are the right thing to do. As you know, they are part of the domain as well. The gist of this post is to avoid getters/setters until you have a valid case for them.

Building an anemic domain model for a complex system is an anti-pattern I’ve seen too much the last couple of years. Such a code base typically has a lot of duplicate code an is very hard to maintain.

An anemic domain is perfectly valid in simple, data viewing applications. This is the active-record scenario where the objects are DTO’s.

All I’m saying is that by putting the behavior where the data is, I’m achieving more orthogonality. This is what OOP is all about.

By: trasa

trasa — Tue, 30 Sep 2008 15:32:59 +0000

He’s not saying ‘never use services,’ and neither am I. So what does that have to do with the premise (that reliance on properties are a warning of bad design’)?

By: OAB

OAB — Tue, 30 Sep 2008 14:51:22 +0000

I think those yelling YAGNI are missing the point — once you *do* need it, one of the premises of this blog post falls down — i.e. that business rules belong inside of domain objects.

By: trasa

trasa — Mon, 29 Sep 2008 16:44:30 +0000

@Bill: if making Customer culture-aware is not a requirement, leaving the code in Customer makes sense because everything is self-contained.

This isn’t comparable with Free Shipping as that code requires interaction from all sorts of entities, it makes sense to have a Service orchestrate that.

If, through agile design, we’ve uncovered a new requirement [that we're going to be operating bars all over the world] then we just change the design and promote the age code to a culture-aware service; otherwise, YAGNI.

By: Bill Pierce

Bill Pierce — Mon, 29 Sep 2008 15:38:29 +0000

Anemic or not, I have to agree with David. You will already have to modify CanHaveBeer() to accept some sort of CurrentLocation, because your Customer wouldn’t be old enough to drink when visiting my country

Consider the more plausible example of determining if an order qualifies for free shipping. Are you telling me you would hang that behavior on your Order domain object? Me thinks not.