JAVA - extends vs interface - Strategy design pattern

psvaibhav

I have a scenario where multiple concrete classes extends multiple Abstract classes. I am at a loss to come up with a clean structure, reduce the number of files and avoid code repetition.

The ask is to display various sensor values in different ways based on some criteria. Sensor values like temperature, voltage, current etc can have an anlaog widget, a numeric label or a combination of both. I have 3 Abstract classes for the 3 different kind of views. These 3 Abstract classes implement a method that defines how the view is to be drawn. Each sensor view extends the 3 Abstract classes and implements methods to read the sensor, perform some engineering conversion and display the sensor value. The problem here is that the code implemented by the concrete classes is the same no matter what Abstract class it extends. CAnalogTempView, CDigitalTempView and CCustomTempView all have the same implementation but extend different classes.

This seems awkward. The code is repeated and the number of source files increases by a factor of 3. Am I missing something simple here? Is there a pattern for a problem like this? Can I extends the sensor view classes at run time? The actual code is more complicated. I have over simplified the problem statement for clarity.

EDIT: There are several sensor views which implement the Abstract view classes. The calculate() method for each sensor is different. I have just listed 3 concrete classes for simplicity. In the same vein, you would have CAnalogVoltageView, CDigitalVoltageView, CCustomVoltageView and CAnalogCurrentView, CDigitalCurrentView, CCustomCurrentView and so on

public abstract class CView
{
    public abstract void draw();
    public abstract void calculate();
}

public abstract class CAnalogView extends CView
{
    public void draw()
    {
         // draw specific to analog view
    }
}

public abstract class CDigitalView extends CView
{
    public void draw()
    {
        // draw specific to digital view
    }
}

public abstract class CCustomView extends CView
{
    public void draw()
    {
        // draw specific to custom view
    }
}

// concrete implementations
public class CAnalogTempView extends CAnalogView
{
    public void calculate()
    {
        // read and calculate sensor value here
    }
}

public class CDigitalTempView extends CDigitalView
{
    public void calculate()
    {
        // calculate here. same as CAnalogTempView::calculate()
    }
}

public class CCustomTempView extends CCustomView
{
    public void calculate()
    {
        // calculate here. same as CAnalogTempView::calculate()
    }
}
Junaid

Strategy design pattern will help you. Well One thing that you should kept in mind.

Use as less extends keyword as possible, better to use Interfaces or composition.

Solution:

Encapsulate the calculate() because calculate() may change in future and it has different implementations.

Process:

1) Make an interface CalcInterface that has calculate().

2) Implement CalcInterface by 3 different classes say CAnalogTempCalc, CDigitalTempCalc and CCustomTempCalc. Then implement calculate() in each class.

3) Now its time for composition. Say you have Sensor class (main class) ... then make the object of type CalcInterface. PS: it will has display() that is common for all.

4) And now make 3 different classes that extends Sensor say AnalogSensor, TempSensor and CustomSensor ...

5) Now at runtime you will make any of type's ( CAnalogTempCalc, CDigitalTempCalc and CCustomTempCalc ) object.

EDIT :

Following is the Class Diagram, I am not good with art ... but this diagram will give you some idea about classes and interfaces and how to use them efficiently.

enter image description here

Now you will be able to implement as many CustomCalcuations as you want by just implementing the CalcInterface ...

This is the POWER to accommodate change without changing current implementation you have by following Strategy design pattern.

Collected from the Internet

Please contact [email protected] to delete if infringement.

edited at
0

Comments

0 comments
Login to comment

Related

From Dev

The Strategy design pattern vs simple Interface abstraction?

From Java

Java - Using "<? extends Interface>" vs Interface only

From Dev

Rust equivalent of Java Consumer interface for Strategy pattern

From Dev

Strategy Design Pattern

From Dev

Is this following the strategy design pattern

From Java

Polymorphism vs Strategy pattern

From Dev

Extends an abstract class to an enum - Strategy Pattern

From Java

Confused about strategy design pattern

From Dev

Strategy design pattern - stopping the method

From Dev

Strategy Design Pattern for handling requests

From Dev

strategy pattern and number of methods in the strategy Interface

From Dev

Head First Design Pattern: When to not use Interface (specifically in Java 'interface')

From Java

Design pattern - Strategy and Bridge (Overlap in design)

From Java

Which design pattern to use strategy or factory design?

From Java

Design pattern for retrofit interface

From Java

extends class and implements interface in java

From Dev

Component/Strategy Pattern in C++, Design and Implementation

From Dev

Question on diamond operator for design pattern strategy

From Dev

many dependencies in switch context in strategy design pattern

From Dev

How to correctly implement strategy design pattern

From Java

Using strategy design pattern with an abstract parameter

From Dev

Caching Strategy/Design Pattern for complex queries

From Dev

What is the difference between Strategy and Factory design pattern?

From Dev

is Context in Android an implementation of a complex Strategy design pattern?

From Dev

Test Automation - Page Object - Strategy Design Pattern

From Dev

Avoid Service locator in strategy design pattern

From Java

Decorator pattern implementations - extends vs implements

From Java

hibernate - Persisting a composition interface of strategy pattern

From Java

Java's "Scanner" Method vs. Facade GoF Design Pattern

Related Related

  1. 1

    The Strategy design pattern vs simple Interface abstraction?

  2. 2

    Java - Using "<? extends Interface>" vs Interface only

  3. 3

    Rust equivalent of Java Consumer interface for Strategy pattern

  4. 4

    Strategy Design Pattern

  5. 5

    Is this following the strategy design pattern

  6. 6

    Polymorphism vs Strategy pattern

  7. 7

    Extends an abstract class to an enum - Strategy Pattern

  8. 8

    Confused about strategy design pattern

  9. 9

    Strategy design pattern - stopping the method

  10. 10

    Strategy Design Pattern for handling requests

  11. 11

    strategy pattern and number of methods in the strategy Interface

  12. 12

    Head First Design Pattern: When to not use Interface (specifically in Java 'interface')

  13. 13

    Design pattern - Strategy and Bridge (Overlap in design)

  14. 14

    Which design pattern to use strategy or factory design?

  15. 15

    Design pattern for retrofit interface

  16. 16

    extends class and implements interface in java

  17. 17

    Component/Strategy Pattern in C++, Design and Implementation

  18. 18

    Question on diamond operator for design pattern strategy

  19. 19

    many dependencies in switch context in strategy design pattern

  20. 20

    How to correctly implement strategy design pattern

  21. 21

    Using strategy design pattern with an abstract parameter

  22. 22

    Caching Strategy/Design Pattern for complex queries

  23. 23

    What is the difference between Strategy and Factory design pattern?

  24. 24

    is Context in Android an implementation of a complex Strategy design pattern?

  25. 25

    Test Automation - Page Object - Strategy Design Pattern

  26. 26

    Avoid Service locator in strategy design pattern

  27. 27

    Decorator pattern implementations - extends vs implements

  28. 28

    hibernate - Persisting a composition interface of strategy pattern

  29. 29

    Java's "Scanner" Method vs. Facade GoF Design Pattern

HotTag

Archive