You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directmemory.apache.org by Daniel Manzke <da...@googlemail.com> on 2011/10/14 10:23:11 UTC
Objects instead of String Parameters
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
Re: Objects instead of String Parameters
Posted by Daniel Manzke <da...@googlemail.com>.
I'm with you guys. With a right designed API or architecture, there is no
need for such things. Maybe I'm just a little bit branded by the Stuff I saw
in the last years. (5-6 Methods overloading the original... ;)
2011/10/14 Simone Tripodi <si...@apache.org>
> +1 to Raf & Mau, methods can be overloaded if needed and no needs of
> over-engineered platform
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Oct 14, 2011 at 2:38 PM, Maurizio Cucchiara
> <ma...@gmail.com> wrote:
> > I agree with Raffaele,
> > I myself have used nice stuff like Credential object, but I did only
> because
> > we needed an heterogenuos security envoronment.
> > So.IMO, we should use as much architecture as needs.
> >
> > Sent from my mobile device, so please excuse typos and brevity.
> >
> > Maurizio Cucchiara
> >
> > Il giorno 14/ott/2011 13.19, "Raffaele P. Guidi" <
> raffaele.p.guidi@gmail.com>
> > ha scritto:
> > 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,
> > ...
> >
>
--
Viele Grüße/Best Regards
Daniel Manzke
Re: Objects instead of String Parameters
Posted by Simone Tripodi <si...@apache.org>.
+1 to Raf & Mau, methods can be overloaded if needed and no needs of
over-engineered platform
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Oct 14, 2011 at 2:38 PM, Maurizio Cucchiara
<ma...@gmail.com> wrote:
> I agree with Raffaele,
> I myself have used nice stuff like Credential object, but I did only because
> we needed an heterogenuos security envoronment.
> So.IMO, we should use as much architecture as needs.
>
> Sent from my mobile device, so please excuse typos and brevity.
>
> Maurizio Cucchiara
>
> Il giorno 14/ott/2011 13.19, "Raffaele P. Guidi" <ra...@gmail.com>
> ha scritto:
> 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,
> ...
>
Re: Objects instead of String Parameters
Posted by Maurizio Cucchiara <ma...@gmail.com>.
I agree with Raffaele,
I myself have used nice stuff like Credential object, but I did only because
we needed an heterogenuos security envoronment.
So.IMO, we should use as much architecture as needs.
Sent from my mobile device, so please excuse typos and brevity.
Maurizio Cucchiara
Il giorno 14/ott/2011 13.19, "Raffaele P. Guidi" <ra...@gmail.com>
ha scritto:
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,
...
Re: Objects instead of String Parameters
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
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 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
>