Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #2610

Re: Refactoring discovery

From David Lamb <dalamb@cs.queensu.ca>
Newsgroups comp.lang.java.programmer
Subject Re: Refactoring discovery
References <kbgoo6dfrkh58r3ogel9nb6rekrs258it2@4ax.com> <imigoe$bpa$1@dont-email.me> <atrqo6hgt63ro0nsuhdrlm9kncv3pb7lra@4ax.com>
Message-ID <PgMkp.1470$0s5.1069@newsfe17.iad> (permalink)
Date 2011-03-30 16:21 -0400

Show all headers | View raw


On 26/03/2011 12:50 AM, Roedy Green wrote:
> On Fri, 25 Mar 2011 09:43:56 -0700, markspace<-@.>  wrote, quoted or
> indirectly quoted someone who said :
>
>> I think it would elucidate your refactoring pattern more if you included
>> an example.  What you did post is very general:
>
> You can see the new code at
> http://mindprod.com/applet/canadiantax.html
>
> The class in question is CalculateCanadianTaxes
>
> The outputs include GST, HST, PST tax rates, GST, HST, PST tax
> amounts, total tax, and total payable.

GHAH.  Conceptually that's really
    CalculateCanadianTaxes: farTooManyInputs -> farTooManyOutputs
Single, vastly complex input; single, vastly complex output.  I'm 
serious; I can't see how anyone can think of the results of a tax 
computation as anything other than one big record type.

Much nicer is the Ohio state tax form from around 1975:
   OhioTax = federalTax * factorLessThanOne
But that's a whole other issue.

Back to comp.lang.java.programmer | Previous | Next | Find similar


Thread

Re: Refactoring discovery David Lamb <dalamb@cs.queensu.ca> - 2011-03-30 16:21 -0400

csiph-web