• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
  • Himai Minh
  • Carey Brown
  • salvin francis

Tranfer Object model.

Ranch Hand
Posts: 44
Oracle Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All

I'm working on the B&S. I�ve been playing with a few ideas since receiving my assignment while I wait to attend a course book by my company run by sun which will help me with ideas.

I�m looking to made use of design patterns where ever I can. The first that comes to mind is the Transfer design pattern as mentioned in Andrew Monkhouse�s book ( he applies it to replicate the record structure for his DVD class). In his example his example he defines this class that that it is pretty rigid, it matches his data file�s current structure. In my assignment I would have something like the follow to represent the equivalent:

Public contractor{
private Boolean deleted;
private int recordNo;
private String name;
private String location;
private String specialties;
private String size;
private String rate;
private String owner;
�. Constructor goes here populating all the above values.
Public void setName(String name){this.name = name;}
Public getName(){return this.name;}

Now, as a developer I have found over a number of years working, especially on green field projects, the user community keeps changing their mind on what they want (even after they've signed off the specifications). The supplied data file only 6 has columns. So what if they decide they want to add the phone number or remove the size column. With the above structure you would have to modify this class to add/remove getter and setter methods, visit the classes and methods that require the new method or remove the deprecated method including in the GUI swing components when using the MVC design pattern.

Can anybody explain why it is not a good idea to use a transfer data factory type object that uses generics and a map collection?
public class transferObject<key,val> {
Map<key,val> transferMap;
transferObject (Map<key,val> transferMap)
this.transferMap = transferMap;

The way I see it I can then take advantage by my front end never having to know what is basing its view on, it will be told at runtime what model to use. I am developing both models to see the difference as I go along to compare issues, but at the moment my generic method is seemingly a far better solution.

Any views and assistance welcome.
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hmmm, interesting thoughts on your design. I went the route of using a traditional DTO, java bean representing a Contractor. This felt more natural to me, it's also more self-documenting in that method signatures are defined with the use of the Contractor class. And IMHO regardless of whether you're using a DTO or a map, changes to the underlying data structure will still need to be propagated to client code. Your gui will still need to access a new phone number field, you've just decided to do it via a key/value pair in a map, versus a getter from a DTO. This is my 2 cents. Let me know if overall you find the map route a better solution, to each their own, especially in the SCJD
I think I'll just lie down here for a second. And ponder this tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic