Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of pajbam@gmail.com designates
 74.125.82.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=OGySa8fh8BABl8GCKhZdbg1dWlJs0Jpmcjaz5QkZ7KOk6QcUE4eAe81tyIeX8PTzS1
         YMmcrkclacVRHPq1M+apUXxayv7WuIq4iVLjs2BtDmGEgMqALtWUX9zBrOL943wcXPW0
         w5a4nlC7L4wCUjz8/6ITGPz6BsO91bAo4uxXU=
Sender: Pierre-Arnaud Marcelot <pajbam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: ACITuple refactoring
From: Pierre-Arnaud Marcelot <pa@marcelot.net>
In-Reply-To: <4C2D986F.3040802@gmail.com>
Date: Fri, 2 Jul 2010 10:46:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA6ABA3B-7DDE-477C-AEA9-BDFE02C4A491@marcelot.net>
References: <4C2D986F.3040802@gmail.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>

Hi Emmanuel,

On 2 juil. 2010, at 09:42, Emmanuel Lecharny wrote:

> Hi guys,
>=20
> I'm going deeper into the ACI review. I have done some refactoring :
> - The ProtectedItem class now does not contain all the ProtectedItem =
subclasses anymore, each one of those classes has now its own Java class
> - ACIItemParser is Schema aware. That means we don't manipulate =
AttributeType as String.

These are two good things... :)

> There are a few more things I want to do:
> 1) ACITuple constructor takes 6 parameters. I do think it's way too =
many, and I'd like to either use setters (but that would make the class =
mutable) or define a factory for tuples.
> 2) The ACDFEngine checkPermission() and hasPermission() methods, plus =
the ACITupleFilter filter() operations take 14 (!!!) parameters. I think =
we should refactor those methods to take a data structure instead, =
because it's really difficult to debug what's going on, assuming that =
depending on the filter, some of the filter's parameters are null, =
because useless.
> 3) The checkPermission() and hasPermission() methods are most =
certainly doing the same thing, I will remove one of them.

+1 for the introduction of a simplified constructor (maybe with not =
parameter at all) and use setters instead.
Same thing for the methods with the idea of a data structure.
This is definitely cleaner.
I looked at the interface and I think it's the larger method signature =
I've ever seen... :D

Regards,
Pierre-Arnaud=