From: Eric Hodel <drbrain@...7.net>
Date: 2003-09-12T10:36:12-07:00
Subject: Re: OO Challenge


--/GPgYEyhnw15BExa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Henry Gilbert (nospam@alliancetec.com) wrote:

> OK, here is my favorite 'Tax Payer' challenge for OO languages.

> There are lot of different groups of people with different rules
> for tax calculation.

Ok... Different groups of people

> One man can be in the same time member of many groups.

Ok... A person is in one or more groups

> If he is member of many groups in the time tax is calculated, his
> tax is the greatest one on the base of all groups he is member.

Ok... A person calculates his tax based on which groups he is in.

> Now, (1) define separate functions that calculate tax for each
> groups, and (2) write polymorphic function that calculate tax for
> tax payer, no matter of his membership to one or many groups in the
> same time. Here is code in procedural language: record
> tax_payer(salary,member_of)
> =20
> Tax Payer problem is all about object (tax_payer) - class (soldier
> ...) membership and polimorphic functions,

In most of the Ruby solutions, the person is the one calculating
the tax, the tax groups don't calculate how much tax a person owes.

> just it is not that simple as designers of OO languages believe
> (object is member of only one class (and superclasses) and does not
> change its membership, function version can be decided solely on
> class membership) - hence one is forced to handle membership relation
> on his own, and OO support integrated in the language is shown to
> be restrictive and cluttering.

A person is in one or more tax groups, which suggests that the
person should hold which professions they are in, not the other way
around.  (With a trivial bit of work, you could have the profession
hold all the people who are in that profession as well, but that is not
useful for the example proposed.)

> It is not the only problem with OO. Inheritance rules are even
> worse; almost everything in that concept is wild guess, and code
> is always much worse.

If you have to fight your language, you're doing something wrong.  The
easy way is probably the right way.  The real problem here seems to be
that the poster doesn't understand how to model problems in OO.

--=20
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04


--/GPgYEyhnw15BExa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/YgQMMypVHHlsnwQRAlOnAKCq78so5q4US/Y7Xm6a8Dzjk+nWxQCZAX3H
wJvXFR9PdnmcbHwW4DUUdGE=
=nMz9
-----END PGP SIGNATURE-----

--/GPgYEyhnw15BExa--