I have recently reviewed a few spring projects.
I saw some interface which created for one class in dao and service layer of some projects.
like this:
public interface EmployeeDao(){
//some methods declaration
}
public class EmployeeDaoImp implements EmployeeDao (){
// methods overriding
}
public interface CompanyDao(){
//some methods declaration
}
public class CompanyDaoImp implements CompanyDao (){
// methods overriding
}
there is no need to Polymorphism in this case.
why we need to these interfaces?,what is advantage of these?.
I hope I could express myself.
Spring uses interfaces a lot because they follow the design principle "Program to an interface not to an implementation"
See Programming to an interface
Related
Is it a bad practice to have a Spring Service break down its functionality by implementing multiple interfaces and then having Spring inject that one Service instance using the interface that declares only the required methods where needed?
Like:
public interface OperationsService1 {
public void operation1();
public void operation2();
}
public interface OperationsService2 {
public void operation3();
public void operation4();
}
#Service
public class OperationsServiceImpl implements OperationsService1, OperationsService2 {
public void operation1() {}
public void operation2() {}
public void operation3() {}
public void operation4() {}
}
and then in the calling class:
#Autowire
private OperationsService1 ops1;
or
#Autowire
private OperationsService2 ops2;
This is more a matter of design than a matter of Spring from my point of view. Generally, a class should be responsible for a single functionality (see SRP on wiki). So one service class should implement one service interface.
and then having Spring inject the Service instance using the interface
that declares only the required methods where needed?
First of all I feel like you are confused. In your example there won't be an instance for each interface. When you call
#Autowire
private OperationsService1 ops1;
#Autowire
private OperationsService2 ops2;
they will both point to the same OperationsServiceImpl class because the bean is singleton by default. What you have here is one instace and two interfaces which point to it. By autowiring the interfaces it means that for the first interface you can call only some of the methods in the bean, with the 2nd interface some other methods of the same bean.
It it a good practice?
I don't think so, usually one would use an interface with multiple object instances with various functionality which is not the case here as explained above. It's gonna get even more messy if other classes start implementing these interfaces and you have to use #Qualifier to distinguish between them. If you want a clean solution separate the OperationsServiceImpl into two separate classes and each of them implement the corresponding interface. It would be less complex and easier to support for new developers.
I have an interface like this:
public interface IFoo{
#AnnotationTest(param="test")
String invoke();
}
and I implement this like this:
public class Foo implements IFoo{
#Override
public String invoke(){
Method method = new Object() {
}.getClass().getEnclosingMethod();
AnnotationTest ann = method.getAnnotation(AnnotationTest.class);
if(ann == null){
System.out.printl("Parent method's annotation is unreachable...")
}
}
}
If it is possible to reach parent's annotation, I want to learn the way of it.
Any help or idea will be appreciated.
You can use Spring AnnotationUtils.findAnnotation to read annotations from interfaces.
Example :
Interface I.java
public interface I {
#SomeAnnotation
void theMethod();
}
Implementing class A.java
public class A implements I {
public void theMethod() {
Method method = new Object() {}.getClass().getEnclosingMethod();
SomeAnnotation ann = AnnotationUtils.findAnnotation(method, AnnotationTest.class);
}
}
It obviously requires to include in your project (and import) Spring framework classes.
There is no direct way to get it. If you really need, you have to manually loop over getInterfaces() to find if any implemented interface has the annotation. If you want to search for (eventually abstract) superclasses and the annotation is not #Inherited, you can again iterate the superclass chain until finding Object (*).
But beware, as following post states, there are good reasons for this not to be directly implemented in Java : Why java classes do not inherit annotations from implemented interfaces?
(*) If the annotation is #Inherited it is automatically searched on superclasses, but not on interfaces.
you can't inherit annotations.
But a framework that uses an annotation can check to see if annotation is present on superclass
I am using Java1.7 and spring3.
I have below classes.
MyInterface.java
public interface MyInterface{
String getResult();
}
MyInterfaceImpl.java
public class MyInterfaceImpl implements MyInterface{
#MyCustomAnnotation
public String getResult(){
//some logic
}
}
I annotated method in Impl class. Is it good practice to annotate methods in implementation class? Or do i need to annotate methods in the interface itself?
Thanks!
Classes don't inherit the annotation from interfaces, so you should be really careful using annotations on interfaces.
Here is an example of what can happen if you are not careful:
http://kim.saabye-pedersen.org/2013/05/spring-annotation-on-interface-or-class.html
Imagine you are working on a mature product and a new search feature is requested that is required for 50% of your product. Now assuming you have an established interface inheritance relationship with SomeDao that you don't want to break...
public interface MoneyDao
extends SomeDao<MoneyEntity>
{
//Operation common in much of the application
List<MoneyEntity> findByCriteria(MoneyCriteria criteria);
}
...is there a way to expose the method 'findByCriteria(..)' without repeating it in all the other places similar to MoneyDao where it's required in a cleaner way?
Bare in mind I want to avoid casting in to a new type where its used and modifying SomeDao if at all possible.
Regards,
James
Can you break the findByCriteria into its own interface and extend it in MoneyDao? Something like this:
public interface MoneyDao
extends SomeDao<MoneyEntity>, MoneyFinder
{
}
public interface MoneyFinder
{
//Operation common in much of the application
List<MoneyEntity> findByCriteria(MoneyCriteria criteria);
}
Now your class(es) implementing MoneyDao don't need to change, but you can pass around just the findByCriteria using MoneyFinder.
Its all depends on if you want a class that is searchable and is a Dao, in other words its if your Searchable class must also be a Dao. If its this case I would use a generic approach to make your Dao Searchable.
interface SearchableDao<Entity, Criteria> extends SomeDao<Entity>
{
List<Entity> findByCriteria(Criteria criteria);
}
Now your class can be a simple Dao or a SearchableDao. SearchableDao is also a simple Dao.
class MoneyDao implements SearchableDao<MoneyEntity, MoneyCriteria>
{
List<MoneyEntity> findByCriteria(MoneyCriteria criteria) {...}
}
I have just started learning Scala and I'm now wondering how I could implement two different Java interfaces with one Scala class? Let's say I have the following interfaces written in Java
public interface EventRecorder {
public void abstract record(Event event);
}
public interface TransactionCapable {
public void abstract commit();
}
But a Scala class can extend only one class at a time. How can I have a Scala class that could fulfill both contracts? Do I have to map those interfaces into traits?
Note, my Scala classes would be used from Java as I am trying to inject new functionality written in Scala into an existing Java application. And the existing framework expects that both interface contracts are fulfilled.
The second interface can be implemented with the with keyword
class ImplementingClass extends EventRecorder with TransactionCapable {
def record(event: Event) {}
def commit() {}
}
Further on each subsequent interface is separated with the keyword with.
class Clazz extends InterfaceA
with InterfaceB
with InterfaceC {
//...
}