• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

read/write properties and constructors

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been reading a lot lately (on Agile development, Domain Driven Design, Test Driven Design and a myriad of other OOAD topics) and for the most part have been left with more questions than answers.

In Robert Martin's excellent Agile Software Development, just about all the classes in his code samples use read/write properties. No explanation is given for why this approach is taken.

This seems to run contrary to the idea of data integrity, which would seem to suggest that as few class properties as possible should be made writable. I don't want to expose my classes to the risk that clients will (out of negligence or incompetence) corrupt my object's state by making all properties writable.

I guess my ultimate question has to do with object creation. Before doing all this reading, my philosophy was to design classes with entirely read-only properties and a non-default constructor that took the parameters needed to create the object.

But this approach assumed that that objects were responsible for creating themselves. Robert Martin's book in particular illustrates a new (to me) approach in which objects are created by factories. This seems to require that many, if not all, of a class' properties must be read/write so that the factory class can set the object's various attributes. Given this pattern of object creation, what's the point of having non-default constructors, since class initialization is being orchestrated outside of the class in question?

I look forward to reading people's responses.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The intent of factory classes, in accordance with the GOF factory patterns, is to "create" the objects. This does not mean that the factory class also sets the object's attributes. Default values are specified in the object's class file. Values of the attributes, during runtime are set by the objects that the object interacts with via calling accessor/mutator methods, i.e. get and set methods (in accord with JavaBeans).

Abstract Factory and Factory Method are two Creational object-oriented design patterns.
[ November 12, 2008: Message edited by: James Clark ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, there are (at least) two philosophies to writing code:

- protect it against misuse by incompetent developers, or
- make it a pleasure for competent developers to use it.

Often, the two in fact conflict. And I know that Robert Martin prefers to follow the latter philosophy.
 
Mitch Hartner
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the replies. Ilja, I have no problem adopting the latter philosophy. How does one decide what arguments, if any, should be passed into a constructor?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mitch Hartner:
Thanks for the replies. Ilja, I have no problem adopting the latter philosophy. How does one decide what arguments, if any, should be passed into a constructor?



In my opinion, when the constructor is finished, the object should be in a legal state. That is, I shouldn't *have* to call setters before I can actually use it.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic