Mailing-List: contact directmemory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: directmemory-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of raffaele.p.guidi@gmail.com
 designates 74.125.82.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALnYuvAvnHtgqmASwtUTruP9ZrUr+vM0Fyvw-1RJ21Cg_ZRE=A@mail.gmail.com>
References: 
 <CALnYuvAvnHtgqmASwtUTruP9ZrUr+vM0Fyvw-1RJ21Cg_ZRE=A@mail.gmail.com>
Date: Fri, 14 Oct 2011 13:18:39 +0200
Message-ID: 
 <CAAnVOG1UPExWv49xB7SY0PL6VapUQd5yM2U7dDMobkhXx_dA_A@mail.gmail.com>
Subject: Re: Objects instead of String Parameters
From: "Raffaele P. Guidi" <raffaele.p.guidi@gmail.com>
To: directmemory-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016364d26114b6c5904af406bf0

--0016364d26114b6c5904af406bf0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My personal(and professional) point of view is: one thing is designing i.e.
a Pointer object which holds the data that is handled by our system (our
domain model), one thing is designing the Object Model of the parameters
that has to be passed to every single function. I feel, and my experience
confirms it, that this could easily lead to over-architecturing. OO is an
approach, not a tax ;)

Ciao,
    R

On Fri, Oct 14, 2011 at 10:23 AM, Daniel Manzke <
daniel.manzke@googlemail.com> wrote:

> Hi guys,
>
> I just wanted to take the chance to discuss one thing with you.
>
> (similar to the Getter- and Setter-Hell)
>
> In the last years, I saw several APIs (like you guys too). In my Company =
we
> started one year ago, to use speaking Classes for Parameters.
> This means if I have a Method with 3 String Parameters, I only know what
> they mean, if I have the JavaDoc. I really had this case. That's why we
> started to use small (no getter and setter beans) classes. Like for the o=
ur
> login-Method we we are using login(Username, Password) or known from othe=
rs
> login(Credentials).
>
> We don't try to force it, because it doesn't make sense in every situatio=
n.
> ;)
>
> Another one is the using of One Object as a Parameter. (like the
> login(Credentials)) This allows you to evolve your API without breaking t=
he
> Compatibility, because you could add now Parameters, define them with
> Default-Values, so every body can use them, if needed, but old
> Implementations are also working.
>
> What do you think? What's your way?
>
> Bye,
> Daniel
>
> --
> Viele Gr=FC=DFe/Best Regards
>
> Daniel Manzke
>

--0016364d26114b6c5904af406bf0--