No Properties Please
Let me step lightly into a little controversy regarding properties. The object oriented purist would decry the use of properties as a violation of encapsulation. Properties of an object are required for use by the object, and in most cases are not public.
One book I have been reading on object oriented principles and patterns demonstrates this practice with the example of an oven. The oven object allows you to set the requested oven temperature. Granted this could be done with a property setter or a method. Either way, the user has no understanding of how the implementation works for causing the oven to change to a specified temperature.
The difference is how the user is notified when the oven temperature reaches the desired temperature. You could use a polling technique if the temperature was exposed through the use of a property. The client would be responsible to poll the oven temperature property until the desired temperature was attained.
In contrast, the author recommends the use of a delegate. The oven object is responsible for determining when the temperature reaches the desired value, and then calls all delegates registered for the event. The client, when setting the temperature passes in not only the desired temperature, but also a delegate which will be called when the oven reaches the desired temperature.
One size does not fit all. So, are there guidelines we should use when considering the use of a property in our objects? You can contribute to the conversation by leaving your comments below, or drop an email to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using ASP.NET with SQL Server 2012
In this article, you can find some helpful tips to use ASP.NET with SQL Server 2012.
Featured White Paper(s)
Optimizing analytic workloads using DB2 10.5 with BLU Acceleration
BLU Acceleration is a new collection of technologies for analytic queries that are introduced in DB2 for Linux, UNIX, and Win… (read more)