Re: Tired of 100s of stupid Getter/Setter methods
From: Chris Smith (cdsmith_at_twu.net)
Date: 12/31/03
- Next message: Chris Smith: "Re: How to get the root directory ?"
- Previous message: ak: "Re: How to get the root directory ?"
- In reply to: Joona I Palaste: "Re: Tired of 100s of stupid Getter/Setter methods"
- Next in thread: brougham5_at_yahoo.com: "Re: Tired of 100s of stupid Getter/Setter methods"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 31 Dec 2003 12:57:31 -0700
Joona I Palaste wrote:
> Chris Smith <cdsmith@twu.net> scribbled the following:
> > Of course, in a pinch, the exception-throwing kludge will work; it's
> > integrated into the collections API and even given a fancy name:
> > "optional methods". However, even its light application there is
> > generally acknowledged to be one of the few great failures of that API.
>
> I have to agree. In my Software Design: Java course, a homework problem
> asked me to demonstrate a problem with the Collections framework. My
> answer was "optional methods", which are a design problem.
> In "real" code, I once had to make an abstract class called an
> "ImmutableIterator". It's a java.util.Iterator that makes remove()
> throw an UnsupportedOperationException but leaves the other methods
> as abstract. This is bad OO design, but with java.util.Iterator being
> what it is, how could I have avoided it?
Another real example. Part of what I maintain is a data access
framework for a particular application. Basically, it's a very simple
O/R mapper plus some utility classes. Recently, in response to some
scalability issues from a large customer, I took a method that
previously read objects from a database and populated a java.util.List,
and instead substituted (in some circumstances) my own implementation of
List that maintains a ResultSet and doesn't instantiate the data until
it's requested.
This broke some remote corner of the application. On looking into it,
it turns out that some other developer had ignored the clear
documentation stating that this list should be treated as read-only, and
had instead discovered that the method was returning an ArrayList, and
had modified that list as if it were some private working-space for an
algorithm. I fixed the client code, and added bold tags around the
appropriate warning in the API docs for the data framework... but I
doubt the developer read the documentation before doing so last time,
and I doubt the next developer will read the docs before doing so again.
It would be nice to be able to return an UnmodifiableList that simply
doesn't HAVE those methods.
-- www.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
- Next message: Chris Smith: "Re: How to get the root directory ?"
- Previous message: ak: "Re: How to get the root directory ?"
- In reply to: Joona I Palaste: "Re: Tired of 100s of stupid Getter/Setter methods"
- Next in thread: brougham5_at_yahoo.com: "Re: Tired of 100s of stupid Getter/Setter methods"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
