incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raffaele P. Guidi" <>
Subject Re: Objects instead of String Parameters
Date Fri, 14 Oct 2011 11:18:39 GMT
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 ;)


On Fri, Oct 14, 2011 at 10:23 AM, Daniel Manzke <> 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 our
> login-Method we we are using login(Username, Password) or known from others
> login(Credentials).
> We don't try to force it, because it doesn't make sense in every situation.
> ;)
> Another one is the using of One Object as a Parameter. (like the
> login(Credentials)) This allows you to evolve your API without breaking the
> 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üße/Best Regards
> Daniel Manzke

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message