public abstract class CommonClass {
abstract void send(<what should i put here???>) {}
}
public class ClassA extends CommonClass {
void send(List<Comments> commentsList) {
// do stuff
}
}
public class ClassB extends CommonClass {
void send(List<Post> postList) {
// do stuff
}
}
I am new to OODP, I am trying to have a method that is able to take in any kind of List data so that I can abstract things out. How can i do this?
You could make it generic on some type T. Like,
public abstract class CommonClass<T> {
abstract void send(List<T> al);
}
And then, to implement it - use the generic. Like,
public class ClassA extends CommonClass<Comments> {
#Override
void send(List<Comments> commentsList) {
// do stuff
}
}
public class ClassB extends CommonClass<Post> {
#Override
void send(List<Post> postList) {
// do stuff
}
}
Also, as discussed in the comments, your class names could be improved to be more intuitive; something like,
public abstract class AbstractSender<T> {
abstract void send(List<T> al);
}
and then
public class CommentSender extends AbstractSender<Comment> {
#Override
void send(List<Comment> commentsList) {
// do stuff
}
}
public class PostSender extends AbstractSender<Post> {
#Override
void send(List<Post> postList) {
// do stuff
}
}
That has the advantage(s) of being more readable and easier to reason about (I can tell what a PostSender does by reading the name, ClassB not so much).
Finally, this looks like a case where an interface would work since your abstract class is purely virtual (and should be preferred since you can implement multiple interface, but can only extend from a single parent class);
public interface ISender<T> {
void send(List<T> al);
}
public class CommentSender implements ISender<Comment> {
#Override
void send(List<Comment> commentsList) {
// do stuff
}
}
public class PostSender implements ISender<Post> {
#Override
void send(List<Post> postList) {
// do stuff
}
}
In order to achieve this, you can take multiple approaches, I would suggest looking into Generics: https://docs.oracle.com/javase/tutorial/java/generics/index.html
With that said, there is one approach that is the most elegant and simple: you can supply a List<T> where T is a generic type.
public abstract class CommonClass<T> {
abstract void send(List<T>) {}
}
public class ClassA extends CommonClass<Comment> {
void send(List<Comments> commentsList) {
// do stuff
}
}
public class ClassB extends CommonClass<Post> {
void send(List<Post> postList) {
// do stuff
}
}
You can do that with the help of generics. https://www.tutorialspoint.com/java/java_generics.htm
Example
The abstract class
public abstract class CommonClass {
public abstract <T> void send(List<T> data);
}
Its child
public class Child extends CommonClass {
public <T> void send(List<T> data) {
// code here
}
}
Retrieving the list's contents
Retrieving the generified list's contents is similar to retrieving any list's contents. In the scope of the method, "T" is a type of object contained in the list.
for (T t : data) {
// to check if t is a string
if (t instanceof String) {
// code
}
}
You can also use lambdas to retrieve every element in the list.
Related
Whats the recommended design approach/alternative to the situation below:
BaseCalculator:
BaseType prepareData()
useData(BaseType)
Derived calculators use derived type to override base functionality -
DerivedCalculator1:
BaseType prepareData(){ return DerivedType1}
useData(BaseType t1){ DerivedType1 t=(DerivedType1)t1 //typecast down and proceed....}
DerivedCalculator2
BaseType prepareData(){ return DerivedType2}
useData(BaseType t1){ DerivedType2 t=(DerivedType2)t1 //typecast down and proceed....}
Is there a design approach to avoid typecasting by the derived classes - as it always leaves the gate open for a run-time mishap?
One alternative is to move the polymorphic behavior into the implementations of the BaseType rather than in the implementations of BaseCalculator. For example:
public interface BaseType {
public void process(Calculator calc);
}
public class DerivedType1 implements BaseType {
#Override
public void process(Calculator calc) {
// Do something specific to derived type 1
}
}
public class DerivedType2 implements BaseType {
#Override
public void process(Calculator calc) {
// Do something specific to derived type 2
}
}
public class Calculator {
public void doSomething(BaseType bt) {
bt.process(this);
}
}
If that type of solution is insufficient, a more complex solution is the Visitor Pattern. The Visitor Pattern allows any arbitrary BaseType object to be handled by any arbitrary BaseCalculator using double-dispatch. The catch is that all BaseCalculator implementations must have an method to handle each of the BaseType implementations. For example:
public interface BaseType {
public void process(Calculator calc);
}
public class DerivedType1 implements BaseType {
#Override
public void process(Calculator calc) {
// Do something specific to derived type 1
}
}
public class DerivedType2 implements BaseType {
#Override
public void process(Calculator calc) {
// Do something specific to derived type 2
}
}
public interface BaseCalculator {
public void handle(DerivedType1 dt);
public void handle(DerivedType2 dt);
}
public class DerviedCalculator1 implements BaseCalculator {
#Override
public void handle(DerivedType1 dt) {
dt.process(this);
}
#Override
public void handle(DerivedType2 dt) {
dt.process(this);
}
}
public class DerviedCalculator2 implements BaseCalculator {
#Override
public void handle(DerivedType1 dt) {
dt.process(this);
}
#Override
public void handle(DerivedType2 dt) {
dt.process(this);
}
}
Code base is littered with code like this:
BaseRecord record = // some BaseRecord
switch(record.source()) {
case FOO:
return process((FooRecord)record);
case BAR:
return process((BarRecord)record);
case QUUX:
return process((QuuxRecord)record);
.
. // ~25 more cases
.
}
and then
private SomeClass process(BarRecord record) { }
private SomeClass process(FooRecord record) { }
private SomeClass process(QuuxRecord record) { }
It makes me terribly sad. Then, every time a new class is derived from BaseRecord, we have to chase all over our code base updating these case statements and adding new process methods. This kind of logic is repeated everywhere, I think too many to add a method for each and override in the classes. How can I improve this?
First solution: good old polymorphism.
Simply add an abstract process() method to the BaseRecord class, and override it in every subclass. The code will thus become:
BaseRecord record = ...;
record.process();
If you can't add the process() method into the BaseRecord class (and its subclasses), then implement the visitor pattern. It will leave the process method outside of the BaseRecord class, but each time you add a new subclass, you'll be forced to modify the Visitor interface, and all its implementations. The compiler will thus check for you that you haven't forgotten a case somwhere in a switch.
public interface RecordVisitor<T> {
T visitFoo(FooRecord foo);
T visitBar(BarRecord foo);
...
}
public abstract class BaseRecord {
public abstract <T> T accept(RecordVisitor<T> visitor);
}
public class FooRecord extends BaseRecord {
#Override
public <T> T accept(RecordVisitor<T> visitor) {
return visitor.visitFoo(this);
}
}
public class BarRecord extends BaseRecord {
#Override
public <T> T accept(RecordVisitor<T> visitor) {
return visitor.visitBar(this);
}
}
Now you simply have to implement RecordVisitor for each block of logic described in the question:
RecordVisitor<Void> visitor = new ProcessRecordVisitor();
record.accept(visitor);
Both Visitor Pattern and Strategy pattern can be put in use here. http://en.wikipedia.org/wiki/Strategy_pattern and http://en.wikipedia.org/wiki/Visitor_pattern
I think this is instructive:
package classplay;
public class ClassPlay
{
public void say(String msg) { System.out.println(msg); }
public static void main(String[] args)
{
ClassPlay cp = new ClassPlay();
cp.go();
}
public void go()
{
A someClass = new C();
say("calling process with double dispatch");
someClass.dueProcess(this);
say("now calling process directly");
process(someClass);
}
public void process(A a)
{
say("processing A");
a.id();
}
public void process(B b)
{
say("processing B");
b.id();
}
public void process(C c)
{
say("processing C");
c.id();
}
abstract class A
{
abstract public void id(); // { System.out.println("Class A"); }
public void dueProcess(ClassPlay cp) { cp.process(this); }
}
class B extends A
{
public void id() { System.out.println("Class B"); }
public void dueProcess(ClassPlay cp) { cp.process(this); }
}
class C extends A
{
public void id() { System.out.println("class C"); }
public void dueProcess(ClassPlay cp) { cp.process(this); }
}
}
Suppose I have two classes A and B where A is a superclass of B. Now, I write a function (override), say funct() in both the classes. Then, if I want to call the funct() in A from an object of B, is it possible?
class A {
public void f() {...}
}
class B extends A {
#Override public void f() { super.f(); }
}
Is that what you want?
If instead you want to call A#f() directly on an instance of type B, you must provide a placeholder function for that:
class B extends A {
#Override public void f() { ... }
public void superF() { super.f(); }
}
new B().f(); // calls B#f();
new B().superF(); // calls A#f();
I have trick such as this situation to operate it in an illogical manner using Flag argument in funct() method :D, like this:
class A {
public void funct(boolean callSuper) {
// avoid using callSuper arg here
}
}
class B extends A {
#Override
public void funct(boolean callSuper) {
if (callSuper) {
super.funct(callSuper);
return;//if return type is void
} else {
//do here the functionality if the flag is false
}
}
}
or
class A {
public void funct() {
}
}
class B extends A {
private boolean callSuper = false;
#Override
public void funct() {
if (callSuper) {
super.funct(); // call A.funct() functionality
setCallSuper(false);
} else {
//do here the functionality of B.funct() if the flag is false
}
}
public void setCallSuper(boolean callSuper){
this.callSuper = callSuper;
}
}
Given classes like
class A {
public void funct() {...}
}
class B extends A {
#Override
public void funct() {...}
}
You ask
Then, if I want to call the funct() in A from an object of B, is it
possible?
So let's take
B b = new B();
b.funct();
A a = b;
a.funct();
((A)b).funct();
The above all do the same thing because of polymorphism and late-binding.
The only way to call the superclass' implementation is to get a reference to that member through the super keyword.
class A {
public void funct() {...}
}
class B extends A {
#Override
public void funct() {
super.funct();
}
}
I am not familiar with "Generics". Is it a correct use of "<T extends SuperClass>" ? And do you agree that the codes after using generics are better?
Before using Generics
=================================================
public abstract class SuperSample {
public void getSomething(boolean isProcessA) {
doProcessX();
if(isProcessA){
doProcessY(new SubASample());
}else{
doProcessY(new SubBSample());
}
}
protected abstract void doProcessX();
protected void doProcessY(SubASample subASample) {
// Nothing to do
}
protected void doProcessY(SubBSample subBSample) {
// Nothing to do
}
}
public class SubASample extends SuperSample {
#Override
protected void doProcessX() {
System.out.println("doProcessX in SubASample");
}
#Override
protected void doProcessY(SubASample subASample) {
System.out.println("doProcessY in SubASample");
}
}
public class Sample {
public static void main(String[] args) {
SubASample subASample = new SubASample();
subASample.getSomething(true);
}
}
After using Generics
=================================================
public abstract class SuperSample {
public void getSomething(boolean isProcessA) {
doProcessX();
if(isProcessA){
doProcessY(new SubASample());
}else{
doProcessY(new SubBSample());
}
}
protected abstract void doProcessX();
protected abstract <T extends SuperSample> void doProcessY(T subSample);
}
public class SubASample extends SuperSample {
#Override
protected void doProcessX() {
System.out.println("doProcessX in SubASample");
}
#Override
protected <T extends SuperSample> void doProcessY(T subSample) {
System.out.println("doProcessY in SubASample");
}
}
public class Sample {
public static void main(String[] args) {
SubASample subASample = new SubASample();
subASample.getSomething(true);
}
}
If you want to do what I think you want to do, I don't think that this is the right way (*). If you want that every subclass needs to implement a method that processes it's own type, then you can use the CRTP trick:
abstract class Super<S extends Super<S>> {
abstract void process(S s);
}
class SubA extends Super<SubA> {
void process(SubA s){ /* do something */ }
}
class SubB extends Super<SubB> {
void process(SubB s){ /* do something */ }
}
Note that this pattern enforces the generic signature of the subclasses, e.g. class SubA extends Super<SubB> wouldn't compile.
Java itself uses that trick in java.lang.Enum, by the way.
(*)If this is not the behavior you want to enforce, please clarify.
it's correct to use . It means that you restrict type T to be subclass of SuperSample. And for second answer, yes I think code with generecis is better because it keeps you from wrong casting of classes for example with containers (List ...). But in fact generics in Java are only syntax suger and so they are erased during runtime.
I designed the following for a problem:
class Animal {
// ...
}
class Guppy extends Animal { ... }
class Pigeon extends Animal { ... }
class TailedAnimal extends Animal {
// ...
}
class Dog extends TailedAnimal { ... }
class Cat extends TailedAnimal { ... }
class HornedAnimal extends Animal {
// ...
}
class Ram extends HornedAnimal { ... }
public static void main(String[] args) {
Animal a = getSomeAnimal();
a.doSomething();
if (a instanceof TailedAnimal) {
// do something
}
if (a instanceof HornedAnimal) {
// do something else
}
}
Animal, HornedAnimal and TailedAnimal are used mainly as data models.
Since Java does not support multiple inheritance, I have trouble creating Rhinoceros which is a Horned and Tailed animal. After asking around, someone recommended using composition and interfaces. I came up with the following:
class Animal {
// ...
}
class Guppy extends Animal { ... }
class Pigeon extends Animal { ... }
class Ram extends Animal implements IHorned { ... }
class Cat extends Animal implements ITailed { ... }
class Dog extends Animal implements ITailed {
BasicTail t = new BasicTail();
public Object getTail() {
return t.getTail();
}
public void setTail(Object in) {
t.setTail(in);
}
}
interface ITailed {
public Object getTail();
public void setTail(Object in);
//...
}
class BasicTail implements ITailed {
Object myTail;
public Object getTail() { return myTail; }
public void setTail(Object t) { myTail = t; }
}
interface IHorned {
// getters and setters
}
public static void main(String[] args) {
Animal a = getSomeAnimal();
a.doSomething();
// how do I check if a is horned or tailed?
}
My interface has getters and setters. Is there any way to avoid this? Assuming that there is currently no way to abstract the behaviour of Tails and Horns, and they're are being used mainly as data holders. How do I determine if my Animal is Horned or Tailed?
I'd suggest strategy pattern here. In short:
interface TailedAnimal {
void moveTail();
}
interface HornedAnimal {
void hitWithHorn();
}
class Rhinoceros() implements TailedAnimal, HornedAnimal {
private TailedAnimal tail; //Instantiate it somehow e.g. constructor, setter
private HornedAnimal horn; //Instantiate it somehow e.g. constructor, setter
public void moveTail() {
tail.moveTail();
}
public void hitWithHorn() {
horn.hitWithHorn();
}
}
By using this you encapsulate behavior in a concrete implementation of the interfaces, and may easily share exactly the same behavior for a few animals, as well as change it at run-time.
I think you must avoid setters in general. If you can, use immutable objects, and initialize its private data into its constructor.
To distinguish animals, I used another pattern, the visitor one. It's verbose, but you don't have to test directly what animal you're processing.
public class Animals {
private Animals() {
}
interface Animal {
void accept(final AnimalProcessor visitor);
}
interface AnimalProcessor {
void visitTailed(final TailedAnimal tailedAnimal);
void visitHorned(final HornedAnimal hornedAnimal);
}
interface TailedAnimal extends Animal {
void moveTail();
}
interface HornedAnimal extends Animal {
void hitWithHorns();
}
static class Dog implements TailedAnimal {
public void moveTail() {
//To change body of implemented methods use File | Settings | File Templates.
}
public void accept(final AnimalProcessor visitor) {
visitor.visitTailed(this);
}
}
static class Cat implements TailedAnimal {
public void moveTail() {
//To change body of implemented methods use File | Settings | File Templates.
}
public void accept(final AnimalProcessor visitor) {
visitor.visitTailed(this);
}
}
static class Ram implements HornedAnimal {
public void hitWithHorns() {
//To change body of implemented methods use File | Settings | File Templates.
}
public void accept(final AnimalProcessor visitor) {
visitor.visitHorned(this);
}
}
static class Rhinoceros implements HornedAnimal, TailedAnimal {
public void hitWithHorns() {
//To change body of implemented methods use File | Settings | File Templates.
}
public void moveTail() {
//To change body of implemented methods use File | Settings | File Templates.
}
public void accept(final AnimalProcessor visitor) {
visitor.visitTailed(this);
visitor.visitHorned(this);
}
}
public static void main(String[] args) {
Collection<Animal> animals = new ArrayList<Animal>(Arrays.asList(new Dog(), new Cat(), new Rhinoceros()));
for (final Animal animal : animals) {
animal.accept(new AnimalProcessor() {
public void visitTailed(final TailedAnimal tailedAnimal) {
// you do what you want when it's a tailed animal
}
public void visitHorned(final HornedAnimal hornedAnimal) {
// you do what you want when it's a horned animal
}
});
}
}
}
I've edited out my previous answer. I thought of something much better. See the revision for this post if you're curious.
Make use of the Specification pattern. It very much fits the bill here - way more than Decorator. You asked to "check" if an Animal was horned. Decorator pattern delivers transparency, while in this situation you appear to be asking for discrimination.
The Specification pattern encapsulates knowledge of how to evaluate some criteria. In our case, we'd want something like:
public interface Specification {
public boolean isSatisfiedBy(Animal aCriteria);
}
public class HornedAnimalSpecification implements Specification {
#Override
public boolean isSatisfiedBy(Animal aCriteria) {
//Right here is where the heart of your problem
//can be solved.
//
//Reserved conquering grounds.
}
}
Now you can define your Animal hierarchy however you want. The only thing you now need to do is figure out what makes an animal horned. Your answer to that question goes into the Specification class. Then your main function is easy as pie.
public class Zoo {
public static void main(String[] args) {
Animal ram = getHornedAnimal(); //Instantiate however you'd like.
Specification specification = new HornedAnimalSpecification();
if (specification.isSatisfiedBy(ram)) {
//Bingo, it's horned.
} else {
//Not horned!
}
}
}