Dependancy Injection, OOP and Class cast

[Bas]

Hello,

I've got 2 trees of classes (I'll show only one level here):
B1 extends A1
and
B2 extends A2

1's classes need 2's classes to do their work. Can I do the following:
class A1 {
private A2 dependency;

public A2 getDependency() {
return this.dependency;
}

public void setDependency(A2 dependency) {
this.dependency=dependency;
}
}

class B1 {
public void someMethod() {
((B2) getDependency()).doJob(); //***
}
}

Dependency injection:
<bean name="b1" class="B1">
<property name="dependency">
<bean class="B2"> <!-- *** -->
<property>
<bean>

Is it safe to do class cast in the line marked with "***"? What is the best practice in this case?

The thing is that I want to use OOP in my Service and DAO classes, but I'm not sure what is the best way to provide all Services with their dependencies (DAOs) without providing each Service subclass with DAO of concrete type and geters/seters for that DAO.

Thank you.

[Costin Leau]

Class casts are justifiable though they usually indicate a design problem. Casting is needed since the caller wants to use some extra functionality not provided by the base class.
You could identify what this functionality is and isolate it into some interfaces. Implementations can behave differently but they in the end, fulfill the same contract.
If you want to add something else then basically you are changing the contract and in most cases, these can be provided through some different interfaces.
In your case, does B2 is a subclass of A2 - if so why doJob is not part of the A2. Can't the doJob functionality be implemented when subclassing A2 inside one of A2 methods?
Also note that you can just as well add a dependency on B2 - you'll have the same object in two places - depA2 and depB2 for example but from a dependency point of view things are more clear (plus you are not losing any memory or CPU power).

[Bas]

Thanks, Costin. It works great. You know, it's very hard to escape from logic in a legacy code. I looked at it from the different prespective (what you suggested) and it helped. Thanks.

[Costin Leau]

You're welcomed. If you are interested in the subject I recommend looking at the "red books" especially Expert One-on-One development (and I'm not being biased here) - they provide plenty of insight about architecture and enterprise development (at least IMO).
You can also look at the Domain Driven Design (by Eric Evans).

[Bas]

Yeah, I've read "Professional Java Development with the Spring Framework". I'm going to read those two as well.