Retrieve object's real class
Hello,
I've got a method that retrieves an object of an interface type:
publicvoid doSomething(IEntity entity)
{
...
}
Within the body of the method I want to get the objects implementation class. Let's assume entity is of Type EntityImpl:
class EntityImpl implements IEntity ....
There will be many classes implementing IEntity, so how do I retrieve the objects concrete implementation AND further on CAST the IEntity-object into that implementation class?
I thought that I have to use reflections for that.
Is it possible to do that things at all?
At the end there shall be possible something like this:
publicvoid doSomething(IEntity entity)
{
// 1. find out entity's class
// 2. cast entity to class
// 3. use the new casted object in another method like anotherMethod(castedObject);
}
Thanks in advance,
Rapthor
Message was edited by:
rapthor
[1315 byte] By [
rapthora] at [2007-10-3 10:12:04]
I will build an IDAO interface that has methods to store hibernate managed objects. I have for example User, Group, Person and so on.
For each class there are always the same things to do: store, update and so on.
Hibernate has a save(Object object) method that takes a User, Person or Group object.
So I want to achieve sth. like this:
class HibernateDAO implements IDAO
{
.....
public void store(IEntity entity)
{
getHibernateTemplate().save( (entity.getClass()) entity );
}
....
}
This method would become universal for all types of objects managed by Hibernate.
But I think that code does not work.
Message was edited by:
rapthor
I agree, this is a smelly design. you're building a coupling between your business objects and what was once a pretty transparent persistence mechanism, for starters. is there another reason you want this IEntity supertype? I'm guessing not since you then want to cast objects to their correct type once unpersisted. I'd see some benefit if IEntity was a supertype for your business objects, and carried some business-related methods, but as I understand it, IEntity is simply a marker for persistent objects. which is unnecessary and pollutes your classes. your app. shouldn't care that hibernate is persisting for you
Okay I get what you mean but getting a persisted object (unpersist it) can be defined in antoher PersonDAO, UserDAO and so on:
class PersonDAO extends HibernateDAO
{
public Person getByID()
{
........
}
}
HibernateDAO will only consist of methods like this:
class HibernateDAO extends HibernateDaoSupport implements IDAO
{
public void save(IEntity entity)
{
getHibernateTemplate().save(entity);
}
....
}
OK I see, Hibernate now knows about IEntity, but it's an interface,not an implementation. The advantages: No matter if I want to save User, Person, Group ... the only method I need is #HibernateDAO.save(..). I fI want to get a User object, I will use #PersonDAO.getbyid(..).
Do you still think that's smelly? The only thing I don't like is IDAO does not have a signature for getByID anymore. So if I want to swap Hibernate with antoher ORM system, I have to remind that I have to write some getbyid() methods again.
but hibernate can do that anyway, without the need for a marker interface. it deals exclusively with Objects. your DAO can have methods typed specifically for your business objects, and do all the heavy lifting like query hibernate and cast objects to type behind the scenes
I'd write your DAO without any consideration for what's doing the actual persistence. worry about that afterwards, you'll almost certainly still be able to achieve what you want. you're in charge, don't let some pesky third-party library dictate how your application will be written. both Hibernate and Spring were designed specifically not to be intrusive on your code, take advantage of that!
