I have a if statement, with multiple instanceof checks. Example:
if (object instanceof Object1) {
// do something
} else if (object instanceof Object2) {
// to something else
} else if (object instanceof Object2) {
// and something else
} ...
What would be a more elegant way to solve this if-else-query?
the best practice in OOP is to put the logic in the object itself and make it implement an interface:
the interface:
public interface MyLogic{
public void doLogic();
}
first object:
public class Object1 implements MyLogic{
public void doLogic(){// logic 1 here}
}
second object:
public class Object2 implements MyLogic{
public void doLogic(){// logic 2 here}
}
and now just move your logic to the objects itself and instead all the if statements just use
object.doLogic(); // make sure object is from type MyLogic, if not, cast it
This seems to be polymorphism so you can create an Interface and implement it for every Object.
interface ObjectToBeImplemented{
method();
}
class Object1 implements ObjectToBeImplemented{
#Override
method(){...}
}
class Object2 implements ObjectToBeImplemented{
#Override
method(){...}
}
class Object3 implements ObjectToBeImplemented{
#Override
method(){...}
}
This is a typical usage for interfaces. See interfaces as defining the Type of an instance. Therefore, you know that all instance of a certain Type can do a particular task. At that point, you don't really care about the concrete class of the object, you just know it has that particular interfaces available to you to use.
Example :
public interface Worker {
public void doWork();
}
public class Object1 implements Worker {
public void doWork() {
// work for this specific object
}
}
public class Object2 implements Worker {
public void doWork() {
// work for this specific object
}
}
public class Object3 implements Worker {
public void doWork() {
// work for this specific object
}
}
Then your if statements would be replaced by
obj.doWork();
This feels like a missed opportunity for polymorphism.
This is where a bunch of classes share the same method signatures as their superclass/interface, so the code that calls it doesn't need to know which type it is.
Without polymorphism:
Employee employee = ...;
if(employee instanceof Doctor) {
salary = calcDoctorSalary(...);
} else if(employee instanceof Nurse) {
salary = calcNurseSalary(...);
}
With polymorphism:
Employee employee = ...;
salary = employee.calcSalary(...);
The magic goes into the subclasses. calcSalary() is abstract in a superclass, or a method signature in an interface:
public abstract class Employee {
public abstract int calcSalary(...);
}
... or ...
public interface Employee {
public int calcSalary(...);
}
Then the type-dependent logic goes into the subclasses:
public class Nurse implements Employee {
#Override
public int calcSalary(...) {
// code specific to nurses goes here.
}
}
Whether to extend a class, or implement an interface, is something you'll learn with experience. Often when one doesn't start with an interface, one regrets it later.
Related
I have a generic interface
public interface Consumer<E> {
public void consume(E e);
}
I have a class that consumes two types of objects, so I would like to do something like:
public class TwoTypesConsumer implements Consumer<Tomato>, Consumer<Apple>
{
public void consume(Tomato t) { ..... }
public void consume(Apple a) { ...... }
}
Apparently I can't do that.
I can of course implement the dispatch myself, e.g.
public class TwoTypesConsumer implements Consumer<Object> {
public void consume(Object o) {
if (o instanceof Tomato) { ..... }
else if (o instanceof Apple) { ..... }
else { throw new IllegalArgumentException(...) }
}
}
But I am looking for the compile-time type-checking and dispatching solution that generics provide.
The best solution I can think of is to define separate interfaces, e.g.
public interface AppleConsumer {
public void consume(Apple a);
}
Functionally, this solution is OK, I think. It's just verbose and ugly.
Any ideas?
Consider encapsulation:
public class TwoTypesConsumer {
private TomatoConsumer tomatoConsumer = new TomatoConsumer();
private AppleConsumer appleConsumer = new AppleConsumer();
public void consume(Tomato t) {
tomatoConsumer.consume(t);
}
public void consume(Apple a) {
appleConsumer.consume(a);
}
public static class TomatoConsumer implements Consumer<Tomato> {
public void consume(Tomato t) { ..... }
}
public static class AppleConsumer implements Consumer<Apple> {
public void consume(Apple a) { ..... }
}
}
If creating these static inner classes bothers you, you can use anonymous classes:
public class TwoTypesConsumer {
private Consumer<Tomato> tomatoConsumer = new Consumer<Tomato>() {
public void consume(Tomato t) {
}
};
private Consumer<Apple> appleConsumer = new Consumer<Apple>() {
public void consume(Apple a) {
}
};
public void consume(Tomato t) {
tomatoConsumer.consume(t);
}
public void consume(Apple a) {
appleConsumer.consume(a);
}
}
Because of type erasure you can't implement the same interface twice (with different type parameters).
Here's a possible solution based on Steve McLeod's one:
public class TwoTypesConsumer {
public void consumeTomato(Tomato t) {...}
public void consumeApple(Apple a) {...}
public Consumer<Tomato> getTomatoConsumer() {
return new Consumer<Tomato>() {
public void consume(Tomato t) {
consumeTomato(t);
}
}
}
public Consumer<Apple> getAppleConsumer() {
return new Consumer<Apple>() {
public void consume(Apple a) {
consumeApple(t);
}
}
}
}
The implicit requirement of the question was Consumer<Tomato> and Consumer<Apple> objects that share state. The need for Consumer<Tomato>, Consumer<Apple> objects comes from other methods that expect these as parameters. I need one class the implement them both in order to share state.
Steve's idea was to use two inner classes, each implementing a different generic type.
This version adds getters for the objects that implement the Consumer interface, which can then be passed to other methods expecting them.
At least, you can make a small improvement to your implementation of dispatch by doing something like the following:
public class TwoTypesConsumer implements Consumer<Fruit> {
Fruit being an ancestor of Tomato and Apple.
just Stumbled upon this. It just happened, that I had the same Problem, but I solved it in a different way:
I just created a new Interface like this
public interface TwoTypesConsumer<A,B> extends Consumer<A>{
public void consume(B b);
}
unfortunately, this is considered as Consumer<A> and NOT as Consumer<B> against all Logic. So you have to create a small Adapter for the second consumer like this inside your class
public class ConsumeHandler implements TwoTypeConsumer<A,B>{
private final Consumer<B> consumerAdapter = new Consumer<B>(){
public void consume(B b){
ConsumeHandler.this.consume(B b);
}
};
public void consume(A a){ //...
}
public void conusme(B b){ //...
}
}
if a Consumer<A> is needed, you can simply pass this, and if Consumer<B> is needed just pass consumerAdapter
In Functional style it is quite easy do this without implementing the interface and also it does the compile time type checking.
Our functional interface to consume entity
#FunctionalInterface
public interface Consumer<E> {
void consume(E e);
}
our manager to process and consume entity appropriately
public class Manager {
public <E> void process(Consumer<E> consumer, E entity) {
consumer.consume(entity);
}
public void consume(Tomato t) {
// Consume Tomato
}
public void consume(Apple a) {
// Consume Apple
}
public void test() {
process(this::consume, new Tomato());
process(this::consume, new Apple());
}
}
You cannot do this directly in one class as the class definition below cannot be compiled due to erasure of generic types and duplicate interface declaration.
class TwoTypesConsumer implements Consumer<Apple>, Consumer<Tomato> {
// cannot compile
...
}
Any other solution for packing the same consume operations in one class requires to define your class as:
class TwoTypesConsumer { ... }
which is pointless as you need to repeat/duplicate the definition of both operations and they won't be referenced from interface. IMHO doing this is a bad small and code duplication which I'm trying to avoid.
This might be an indicator also that there is too much responsibility in one class to consume 2 different objects (if they aren't coupled).
However what I'm doing and what you can do is to add explicit factory object to create connected consumers in the following way:
interface ConsumerFactory {
Consumer<Apple> createAppleConsumer();
Consumer<Tomato> createTomatoConsumer();
}
If in reality those types are really coupled (related) then I would recommend to create an implementation in such way:
class TwoTypesConsumerFactory {
// shared objects goes here
private class TomatoConsumer implements Consumer<Tomato> {
public void consume(Tomato tomato) {
// you can access shared objects here
}
}
private class AppleConsumer implements Consumer<Apple> {
public void consume(Apple apple) {
// you can access shared objects here
}
}
// It is really important to return generic Consumer<Apple> here
// instead of AppleConsumer. The classes should be rather private.
public Consumer<Apple> createAppleConsumer() {
return new AppleConsumer();
}
// ...and the same here
public Consumer<Tomato> createTomatoConsumer() {
return new TomatoConsumer();
}
}
The advantage is that the factory class knows both implementations, there is a shared state (if needed) and you can return more coupled consumers if needed. There is no repeating consume method declaration which aren't derived from interface.
Please note that each consumer might be independent (still private) class if they aren't completely related.
The downside of that solution is a higher class complexity (even if this can be a one java file) and to access consume method you need one more call so instead of:
twoTypesConsumer.consume(apple)
twoTypesConsumer.consume(tomato)
you have:
twoTypesConsumerFactory.createAppleConsumer().consume(apple);
twoTypesConsumerFactory.createTomatoConsumer().consume(tomato);
To summarize you can define 2 generic consumers in one top-level class using 2 inner classes but in case of calling you need to get first a reference to appropriate implementing consumer as this cannot be simply one consumer object.
Another alternative to avoid the use of more classes. (example using java8+)
// Mappable.java
public interface Mappable<M> {
M mapTo(M mappableEntity);
}
// TwoMappables.java
public interface TwoMappables {
default Mappable<A> mapableA() {
return new MappableA();
}
default Mappable<B> mapableB() {
return new MappableB();
}
class MappableA implements Mappable<A> {}
class MappableB implements Mappable<B> {}
}
// Something.java
public class Something implements TwoMappables {
// ... business logic ...
mapableA().mapTo(A);
mapableB().mapTo(B);
}
Sorry for answer old questions, but I really love it! Try this option:
public class MegaConsumer implements Consumer<Object> {
Map<Class, Consumer> consumersMap = new HashMap<>();
Consumer<Object> baseConsumer = getConsumerFor(Object.class);
public static void main(String[] args) {
MegaConsumer megaConsumer = new MegaConsumer();
//You can load your customed consumers
megaConsumer.loadConsumerInMapFor(Tomato.class);
megaConsumer.consumersMap.put(Apple.class, new Consumer<Apple>() {
#Override
public void consume(Apple e) {
System.out.println("I eat an " + e.getClass().getSimpleName());
}
});
//You can consume whatever
megaConsumer.consume(new Tomato());
megaConsumer.consume(new Apple());
megaConsumer.consume("Other class");
}
#Override
public void consume(Object e) {
Consumer consumer = consumersMap.get(e.getClass());
if(consumer == null) // No custom consumer found
consumer = baseConsumer;// Consuming with the default Consumer<Object>
consumer.consume(e);
}
private static <T> Consumer<T> getConsumerFor(Class<T> someClass){
return t -> System.out.println(t.getClass().getSimpleName() + " consumed!");
}
private <T> Consumer<T> loadConsumerInMapFor(Class<T> someClass){
return consumersMap.put(someClass, getConsumerFor(someClass));
}
}
I think that is what you are looking for.
You get this output:
Tomato consumed!
I eat an Apple
String consumed!
Is there anyway, when calling a method through an object (instance) for that method to know which instance (object) called it?
Here's an example (pseudo code) of what I mean:
Pseudo code example
public class CustomClass{
public void myMethod(){
if (calling method is object1){
//Do something here
}
else {
//Do something else
}
}//End of method
}//End of class
And then in another class:
public SomeOtherClass{
CustomClass = object1;
public void someOtherMethod(){
object1 = new CustomClass();
object1.myMethod(); //This will call the 1st condition as the calling object is object1, if it were some other object name, it would call the 2nd condition.
}//End of method
}//End of class
Possible work-around
The only way I've found to do this is to get the method to take another argument, say an 'int' and then check the value of that int and perform whichever part of the 'if else' statement relates to it (or 'switch' statement if definitely using an 'int' value) but that just seems a really messy way of doing it.
What you need is the Strategy Pattern
public abstract class CustomClass {
public abstract void MyMethod();
}
public class Impl1 extends CustomClass {
#Override
public void MyMethod() {
// Do something
}
}
public class Impl2 extends CustomClass {
#Override
public void MyMethod() {
// Do something else
}
}
Use it this way
public static void main(String[] args) {
CustomClass myObject = new Impl1();
// or CustomClass myObject = new Impl2();
}
As your comment says what you really need is perhaps the Template method Pattern
public abstract class CustomClass {
public void myMethod(){ // this is the template method
// The common things
theDifferentThings();
}
public abstract void theDifferentThings();
}
public class Impl1 extends CustomClass {
#Override
public void theDifferentThings() {
// Do something
}
}
public class Impl2 extends CustomClass {
#Override
public void theDifferentThings() {
// Do something else
}
}
You can know the name of current class by calling getClass().getName(). However you cannot know the name of object, moreover this does not have any meaning:
MyClass myObject1 = new MyClass();
MyClass myObject2 = myObject1;
myObject1.foo();
myObject2.foo();
Do you wutant foo() to know that it was invoked using myObject1 or myObject1? But both references refer to the same object!
OK, there are extremely complicated ways to know this. You can use byte code engineering using one of popular libraries like javassist, ASM, CGLib and inject missing information about the "object name" into byte code and then read this information. But IMHO this is not what you need.
You can define a new attribute inside CustomClass which will store the identifier of the instance. If there will be only a few instances of CustomClass then you can use an enum type.
Replace:
object1 = new CustomClass();
with:
object1 = new CustomClass(1);
Add a new constructor and an attribute to CustomClass:
private int id;
public CustomClass(int id) {
this.id = id;
}
Then you can replace:
if (calling method is object1){
with:
if (id == 1){
However, please keep in mind that this is a bad design.
You should not have if conditions differing logic depending on the instance which called this method. You should should use polymorphism for such purpose.
I'm creating a abstractFactory class and I want to be able to send the concrete factory as a parameter. This way I can remove the if/else chain inside my abstract class.
My problem is I'm not sure how to typecast it back to the concrete class within my abstract class in order to call the createVehicle() method.
car = UniversalVehicleFactory.getFactory().createVehicle(CarFactory);
plane = UniversalVehicleFactory.getFactory().createVehicle(PlaneFactory);
Inside UniversalVehicleFactory I have the method createVehicle which is the method I'm having a problem with. What I'm trying to achieve is: take the parameter, determine its class and cast it to that, then call its internal createVehicle class.
public Vehicle createVehicle(AbstractFactory factory) {
// I want to take factory,
// cast it to the concrete factory, and
// call createMethod() on the factory
return factory.getInstance().createVehicle();
}
Help with this problem much appreciated!
I'll answer your question, but I'm curious why you want a universal factory to call a method of an abstract factory, if indeed you have to supply an instance of that factory as a parameter; you would be better off just invoking the creation method of the abstract factory directly.
Generics were invented for this purpose.
interface Factory< T > {
T make();
}
public class CarFactory implements Factory< Car > {
Car make() { ... }
}
public class PlaneFactory implements Factory< Plane > {
Plane make() { ... }
}
public class UniversalVehicleFactory {
public < T extends Vehicle > T make( Factory< T > factory ) {
return factory.make();
}
}
You'll notice that UniversalVehicleFactory doesn't implement Factory< T >.
I think you are trying to apply Abstract Factory pattern here. Here are my solution:
You can have interface VehicleFactory and factory classes:
interface VehicleFactory {
Vehicle createVehicle();
}
class CarFactory implements VehicleFactory {
public Vehicle createVehicle() {
return new Car();
}
}
class PlaneFactory implements VehicleFactory {
public Vehicle createVehicle() {
return new Plane();
}
}
Then if you want to centralize all the factory, you can have a UniversalVehicleFactory:
class UniversalVehicleFactory {
private Map<Class<T extends VehicleFactory>, VehicleFactory> factories;
static {
factories = new HashMap<Class<T extends VehicleFactory>, VehicleFactory>();
factories.put(CarFactory.class, new CarFactory());
factories.put(PlaneFactory.class, new PlaneFactory());
}
public static VehicleFactory getFactory(Class<T extends VehicleFactory> factoryClass) {
return factories.get(factoryClass);
}
}
Then in your code, use can use it like this:
Vehicle car = UniversalVehicleFactory.getFactory(CarFactory.class).createVehicle();
Vehicle plane = UniversalVehicleFactory.getFactory(PlaneFactory.class).createVehicle();
Here is some generalized code that might help you out:
public class A
{
public void paint(Graphics g)
{
}
}
public class B extends A
{
public static void main(String args[])
{
A a = new A();
B b = new B();
// This is the only one that won't work, because a is not an instance of b.
if(a instanceof B)
((B)a).draw(new Graphics());
if(b instanceof B)
((B)b).draw(new Graphcis());
if(a instanceof A)
((A)a).paint(new Graphics());
if(b instanceof A)
((A)b).paint(new Graphics());
}
public void draw(Graphics g)
{
}
}
instanceof is a great tool to use before typecasting to avoid errors. I hope this helped, if it was too general and you want me to apply it more to your situation let me know.
I often get into situation when I'd like to use template method pattern, but the template method expects a different type of a parameter, like this:
public abstract class AbstractFoo {
public void process(TypeA a, TypeB b) {
//do common processing
if (b == null) {
doProcess(a);
} else if(a == null) {
doProcess(b);
}
}
public abstract void doProcess(TypeA a);
public abstract void doProcess(TypeB b);
}
This doesn't look good. One of the supplied paramaters would have to be null and all services would have to implement dummy doProcess methods for other types. Is there any better pattern for this? How do you deal with this ? I don't want to use constructor because these services are spring beans. Also the same problem applies to Strategy pattern.
public abstract class AbstractFoo<T> {
public void process(T a) {
//do common processing
doProcess(a);
}
protected abstract void doProcess(T a);
}
public class Person extends AbstractFoo<Person> {
#Override
protected void doProcess(Person p) {
p.draw();
}
}
public class Car extends AbstractFoo<Car> {
#Override
protected void doProcess(Car c) {
c.draw();
}
}
You're right that it definitely isn't a template method pattern, but I'm not sure exactly what you're trying to do. Maybe you're after the factory pattern:
interface Foo {
boolean isA();
boolean isB();
...
}
class ProcessorFactory {
public Processor getProcessor(Foo foo) {
if (foo.isA()) {
return new AProcessor();
}
if (foo.isB()) {
return new BProcessor();
}
...
}
}
As for constructors, all of my spring beans have constructors that express their dependencies. What's wrong with that?
I think using a Wrapper class can solve this problem. Wrapper class can be a simple Holder entity. You can even consider encapsulating your application specific properties in the wrapper class (more on lines of a Context). With this approach you only need one process method and the sub classes will only process the Message if it has the correct type. To avoid code duplication you can also do that checking in your abstract class. See following example,
public class Context {
private Object body;
public Context(Object obj) {
body = obj;
}
public Object getBody() {
return body;
}
}
public abstract class AbstractFoo {
public void process(Context ctx) {
//do common processing
if (canProcess(ctx)) {
doProcess(ctx.getBody());
}
}
protected abstract <T extends Object> boolean canProcess(T obj);
protected abstract <T extends Object> void doProcess(T obj);
}
I'm looking to create a set of functions which all implementations of a certain Interface can be extended to use. My question is whether there's a way to do this without using a proxy or manually extending each implementation of the interface?
My initial idea was to see if it was possible to use generics; using a parameterized type as the super type of my implementation...
public class NewFunctionality<T extends OldFunctionality> extends T {
//...
}
...but this is illegal. I don't exactly know why this is illegal, but it does sort of feel right that it is (probably because T could itself be an interface rather than an implementation).
Are there any other ways to achieve what I'm trying to do?
EDIT One example of something I might want to do is to extend java.util.List... Using my dodgy, illegal syntax:
public class FilterByType<T extends List> extends T {
public void retainAll(Class<?> c) {
//..
}
public void removeAll(Class<?> c) {
//..
}
}
You can achieve something like this using a programming pattern known as a 'decorator' (although if the interface is large then unfortunately this is a bit verbose to implement in Java because you need to write single-line implementations of every method in the interface):
public class FilterByType<T> implements List<T> {
private List<T> _list;
public FilterByType(List<T> list) {
this._list = list;
}
public void retainAll(Class<?> c) {
//..
}
public void removeAll(Class<?> c) {
//..
}
// Implement List<T> interface:
public boolean add(T element) {
return _list.add(element);
}
public void add(int index, T element) {
_list.add(index, element);
}
// etc...
}
Alternatively, if the methods don't need to access protected members, then static helper methods are a less clucky alternative:
public class FilterUtils {
public static void retainAll(List<T> list, Class<?> c) {
//..
}
public static void removeAll(List<T> list, Class<?> c) {
//..
}
}
What prevents you from just adding new methods to the interface?
If you can't just add the new functionality to old interface, you could consider making another interface and then an implementation which merely implements those two. Just to be clear, in code this is what I mean:
// Old functionality:
public interface Traveling {
void walk();
}
// Old implementation:
public class Person implements Traveling {
void walk() { System.out.println("I'm walking!"); }
}
// New functionality:
public interface FastTraveling {
void run();
void fly();
}
// New implementation, option #1:
public class SuperHero extends Person implements FastTraveling {
void run() { System.out.println("Zoooom!"); }
void fly() { System.out.println("To the skies!"); }
}
// New implementation, option #2:
public class SuperHero implements Traveling, FastTraveling {
void walk() { System.out.println("I'm walking!"); }
void run() { System.out.println("Zoooom!"); }
void fly() { System.out.println("To the skies!"); }
}
I think it's illegal because you can not guarantee what class T will be. Also there are technical obstacles (parent's class name must be written in bytecode, but Generics information get lost in bytecode).
You can use Decorator pattern like this:
class ListDecorator implements List {
private List decoratingList;
public ListDecorator(List decoratingList){
this.decoratingList = decoratingList;
}
public add(){
decoratingList.add();
}
...
}
class FilterByArrayList extends ListDecorator {
public FilterByAbstractList () {
super(new ArrayList());
}
}
There is a delegation/mixin framework that allows a form of this. You can define a new interface, implement a default implementation of that interface, then request classes which implement that interface but subclass from elsewhere in your hierarchy.
It's called mixins for Java, and there's a webcast right there that demonstrates it.
I'm afraid it's not clear what do you want to get.
Basically, I don't see any benefit in using 'public class NewFunctionality<T extends OldFunctionality> extends T' in comparison with 'public class NewFunctionality extends OldFunctionality' ('public class FilterByType<T extends List> extends T' vs 'public class FilterByType<T> implements List<T>')