• Post Reply Bookmark Topic Watch Topic
  • New Topic

method parameters  RSS feed

 
Chris Montgomery
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm developing an application using a delegate pattern. My application instance is loosely coupled to a core application and uses interfaces (let me know if you want to see a code example, I'll provide it).

Over time, multiple instances of the application will be developed. As a result, I fully expect a method such as addMember() to be somewhat different from one application instance to the next.

What concerns me is how I'm defining my interfaces and methods. Currently, I'm passing parameters (firstName, lastName, etc.), but I foresee this to be a problem. Eventually, I will want to define an addMember interface/method, which requires, say, 7 String parameters, only to find one already exists.

How can I work around this? Should I be creating a value object and passing that as my parameter? Is this recommended?

Thanks!

Chris
 
Scott Selikoff
author
Bartender
Posts: 4093
21
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Should I be creating a value object and passing that as my parameter? Is this recommended?


Yes, definitely. With this value object your interfaces to the original class will rarely ever change compared with the number of times your interface would change if you keep passing them as they are.

Even in cases with only 1-2 parameters, I'd still pass a value object since I don't know that later on I will want to add more and this would insulate my original interfaces from change.

The value object should have no business logic in it and be entirely made of primitives, strings, arrays, and then getters/setters. This way you can give out the value objects without compromising your business logic.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And how will the value objects interface look?
 
Chris Montgomery
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was thinking about that too.

the core app has to know about the value object that is being passed.
Would an abstract class in the core app be good enough?

is it that easy?
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For general purpose data passing I like to define an interface in terms of a Map. Yes there is overhead in terms of creating a Map, filling it with data, and then pulling data out but you can't beat it for generality.
Bill
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[CLG]: And how will the value objects interface look?

Probably like a bunch of getters and setters, like most all value objects, yes?

I dislike long argument lists for methods or constructors, especially if all or most of the arguments are the same type. And if there are other overloads which look very similar. If there are nine strings in a row, it's hard to tell which is which just by looking at the code:

I'd rather see:


If I later need to add fields, I can generally do so without creating any confusion with the existing fields.

[Bill]: For general purpose data passing I like to define an interface in terms of a Map.

Yeah, I tend to prefer a value object which helps the compiler to complain promptly if I accidentally misspell the name of one of my property names. But there are times when flexibility is more important than prompt compiler errors, and a Map does work well for that. And it's often possible to use enums to help the compiler guard against typos, so that can be useful.
[ November 02, 2005: Message edited by: Jim Yingst ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!