• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Generic Question about Assignment

 
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I will not talk about my assignment directly but I am just trying to understand if it's ok to go for a data base centric approach rather than using an factory for creation of objects at the run time.

Example (Not related to my assignment): A company has 5 departments and in future there may be additional 2 departments. I need to show the departments in drop down. One approach is go by factory method and create the required object. I don't like this approach.

If I go for database centric approach where dept table has all dept attribs. I just have dept maintenance screen which needs to make one more entry when new dept is introduced and application becomes highly extensible. In the GUI, just pull distinct dept names and code and display in the drop down. Is this kind of approach acceptable in SCEA-part2? Will the evaluator dislike it?
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I didn't quite understand the "factory method" approach mentioned by you. But for the example you quoted, one of the solution could be to go for "generalization". You will have a generalized class called "Department", any specific department could be the specialized classes of this generalized "Department" class. This way, You can make your application extensible.

The database centric approach mentioned by you is also a type of solution that works, provided "department" is just another entry in a table and all department share common properties. If the properties vary, then you can't represent it as just another row.

We can't state that a particular approach to design is always right, it depends on the SuD.
 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

My understanding of the generalization concept is that we will have a general class and other specialized classes for each departement, this is the result as the class diagram. May be i'm wrong, but concretly, will not that be reflected in the application by an Entity class for each departement ?
Which means it will be necessary to change source as many time as a new departement is added.

I see the approach you intituled database centric approach more suitable, like you sayed, a new departement would simply be a new entry binded with specifics attributes. We can also see it other way, each specialized departement is an instance of the departement class(Object diagram). Now with this, the problem is not totally resolved, it's deplaced to the attribute's part, are we assuming that all departements will have the same attributes !
 
Bartender
Posts: 361
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Anil.
Have a generalized Department entity class and then it's specializations which are the real departments. Within the company entity has a collection which can have all these departments.
I won't go with the Database centric approach because that is more of system which was already implemented using some other technology and now i have been asked to do re-engineering using Java/JEE. As a JEE architect i would like to think more in terms of Objects and in terms of domain model and would like to go in a top down manner-where my classes are designed first and using the ORM tool i generate the DDL for the DB objects. More over i would like to keep more control in the hands of Java team rather than give it to DB folks. Any company/client i have ever worked with - it's never easy to deal with DB folks. It's better to do more work in Java/JEE than shift it to them. I will keep all my departments in the XML file where each element is a department. This XML file will be loaded at the application startup and this can be edited using a web based UI. If more departments are introduced-i will add another element for that in the XML file. This will be better in terms of performance as i will avoid DB round trip. If it is going to be a DB record-i will cache it in my integration tier with read-only for better performance.
 
Anil Chowdary
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My understanding of the generalization concept is that we will have a general class and other specialized classes for each departement, this is the result as the class diagram. May be i'm wrong, but concretly, will not that be reflected in the application by an Entity class for each departement ?
Which means it will be necessary to change source as many time as a new departement is added.

I see the approach you intituled database centric approach more suitable, like you sayed, a new departement would simply be a new entry binded with specifics attributes. We can also see it other way, each specialized departement is an instance of the departement class(Object diagram). Now with this, the problem is not totally resolved, it's deplaced to the attribute's part, are we assuming that all departements will have the same attributes



To answer your question of "change source as many time as a new departement is added", You are correct. Using "Generalization", Its not completely possible to accommodate a new department without changing the source. But if you use factory pattern, You just have to write one new class whenever an entirely new department is added to your system. Rest of the code uses the department interface to deal with any specific operation on department, so addition of a new department will not result in changes to the code in rest of the layers.
 
Youssef Ben Kaddour El Wazzani
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys, thanks, i understand better now.

Anyhow, extensible or not, the application still need to be maintened by a team, and planifing a change times to times is not a big deal, the key isn't to avoid it, but to minimize at the maximum, and with the generalization match very well.

And since it's an exam for JEE5, it's completly fit with the entities inheritance strategy of JPA, there is two link i found useful:

For JPA
For hibernate

Thanks,
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic