• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Tranfer Object model.

 
Ranch Hand
Posts: 44
1
Oracle Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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;}
Etc�
}

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.
Cheers
Q
 
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 was her plaything! And so was this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic