Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@ieee-dot-org.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: A question about some long java code that has getters/setters
Date: Mon, 25 Jul 2011 21:35:16 -0400
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <j0l5mk$15l$1@dont-email.me>
References: <d94f5902-8b2e-484f-8095-9ce034e916d4@t8g2000prm.googlegroups.com> <1672e2f1-a963-4fcf-b651-41b69432c9d7@p29g2000pre.googlegroups.com> <m21uxehzrj.fsf@softwarematters.org> <j0kvh1$1eq$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 26 Jul 2011 01:36:21 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="f8igmItKsWs6nM5YanFxAA"; logging-data="1205"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Bwq5yldzfWcq7tJyG/04q"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
In-Reply-To: <j0kvh1$1eq$1@dont-email.me>
Cancel-Lock: sha1:Ffpz73mWqT21eyx9ro8VwbTJChQ=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6561

On 7/25/2011 7:50 PM, markspace wrote:
> On 7/25/2011 1:27 PM, Patrick May wrote:
>> It encourages a style of programming where
>> objects have too much knowledge about each other.
>
>
> This is an interesting idea. However, I think it might be short sighted,
> or at least incomplete.
>
> For example, I've just been working on a project which involves sending
> commands over a network. There are up to four parameters for all
> commands, and it might be better style to perhaps only create some
> number of constructors which only allow valid combinations of these four
> parameters.
>[... uses "vanilla" constructor plus mutators ...]

     Another approach -- which may or may not make sense in your
situation, but might be worthy of consideration -- is to make Command
immutable, with one constructor that takes a single argument of the
mutable CommandBuilder class.

	public class Command {
	    private final int tweedeldum;
	    private final Control[] tweedledee;
	    ...
	    public Command(CommandBuilder builder) {
	        if (builder.isValid()) {
	            tweedledum = builder.tweedledum;
	            tweedledee = builder.tweedeldee.clone();
	            ...
	        } else {
	            throw new IllegalArgumentException(
	                builder.toString());
	        }
	    }
	}

	public class CommandBuilder {
	    private int tweedledee = 42;
	    private Control[] tweedledum = new Control[0];
	    ...
	    public CommandBuilder setTweedledee(int tweedledee) {
	        this.tweedledee = tweedledee;
	        return this;
	    }
	    public CommandBuilder setTweedledum(Control[] tweedledum) {
	        this.tweedledum = tweedledum;
	        return this;
	    }
	    ...
	}

	...

	Command makeItSo = new Command(
	    new CommandBuilder().setTweedledee(97));
	Command avastYeScurvySpalpeens = new Command(
	    new CommandBuilder().setTweedledum(getControls())
	        .setTweedledee(-86));

     True, the validation and exception-throwing still happen at
run-time -- but it happens at Command construction, instead of later
on when the Command is used and the source of the bad parameters may
be more of a mystery.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid