Win a copy of Microservices Testing (Live Project) this week in the Spring forum!
  • 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
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Best package policy for Factories

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there !
I�m building an application which uses lots of different packages... like patterns , modulos, and so on... I�m trying to organize it the best way I can, but sometimes it has its drawbacks, like package name problem for creating new objects in a factory.
I have a package called com.company.pattern.factory where I place the factory, which is the only factory I want to use in my whole application (by the way.. I don�t know if its the best way ... or having different factories for different modules... ) . Then, I have another package called com.company.area.application.module.command where I have Commands calling the factory for building DAO objects... The problem is : using this structure, I have to pass the right DAO package (like com.company.area.application.module.command ) for instantiating the right object... So... not that practical... but... it works.
On the other hand, If I had the factory placed for instance in the same Command package and had the package name as a literal , it would be much simpler... but sounds a bit amateur... and plastered...
So... what do you suggest... ?
Below, it�s the factory code snippet... (not implemented as a Singleton)
public static InterfaceDAO getDAO(String package, String type) throws ActionException{
Class classe = null;
try{
classe = Class.forName(package+ type);
}catch(ClassNotFoundException e){
throw new ActionException("Classe " +
type+ " n�o encontrada ou inconsistente.",e);
}
Object objetoDAO = null;
try{
objetoDAO = classe.newInstance();
}catch(Exception e){
throw new ActionException ("Erro ao criar objeto " +
type+ "DAO .",e);
}

return (InterfaceDAO) objetoDAO;
}

Thanks in advance...
F�bio
 
Sheriff
Posts: 6962
2
Eclipse IDE Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We had a huge discussion about class packaging in this older thread. It's probably worth taking a look at it.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am quite confused about your notion of a correlation between design patterns and packaging. Can you please elaborate about your motivation of making a pattern.factory package, for example?
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ilja,
I don�t see any correlation between patterns and packages. It�s just a matter of organization... kinda best practice... cause I�ve seen many projects with complex and almost auto-descriptive packages that helped a lot for knowing where a particular kind of class was... for debugging issues ... I mean , you know all DAO classes for determined module are at com.company.project.module.dao ...
I found it helpful and clean... but it�s also a pain ... cause you have to import lots of packages... with , sometimes, huge names... and so on...
I think the main concern is related to organization...
Concerning the package for patterns, it�s a way of centralizing in a clear structure, all the pattern implementations I have... the same way I plan to do with my Util package... where I can put all the useful general classes I create to use in the application...
I don�t know if I�ve been clear... but if not, let me know ...
I just want to know if it�s worth doind this ... for organization sake...
Thanx
F�bio
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic