We Keep Coding

What pattern should be used, strategy?

I do have a service which needs to handle two types of meal.
#Service
class MealService {
private final List<MealStrategy> strategies;
MealService(…) {
this.strategies = strategies;
}
void handle() {
var foo = …;
var bar = …;
strategies.forEach(s -> s.remove(foo, bar));
}
}
There are two strategies, ‘BurgerStrategy’ and ‘PastaStrategy’. Both implements Strategy interface with one method called remove which takes two parameters.
BurgerStrategy class retrieves meals of enum type burger from the database and iterate over them and perform some operations. Similar stuff does the PastaStrategy.
The question is, does it make sense to call it Strategy and implement it this way or not?
Also, how to handle duplications of the code in those two services, let’s say both share the same private methods. Does it make sense to create a Helper class or something?

does it make sense to call it Strategy and implement it this way or not
I think these classes ‘BurgerStrategy’ and ‘PastaStrategy’ have common behaviour. Strategy pattern is used when you want to inject one strategy and use it. However, you are iterating through all behaviors. You did not set behaviour by getting one strategy and stick with it. So, in my honour opinion, I think it is better to avoid Strategy word here.
So strategy pattern would look like this. I am sorry, I am not Java guy. Let me show via C#. But I've provided comments of how code could look in Java.
This is our abstraction of strategy:
public interface ISoundBehaviour
{
void Make();
}
and its concrete implementation:
public class DogSound : ISoundBehaviour // implements in Java
{
public void Make()
{
Console.WriteLine("Woof");
}
}
public class CatSound : ISoundBehaviour
{
public void Make()
{
Console.WriteLine("Meow");
}
}
And then we stick with one behaviour that can also be replaced:
public class Dog
{
ISoundBehaviour _soundBehaviour;
public Dog(ISoundBehaviour soundBehaviour)
{
_soundBehaviour = soundBehaviour;
}
public void Bark()
{
_soundBehaviour.Make();
}
public void SetAnotherSound(ISoundBehaviour anotherSoundBehaviour)
{
_soundBehaviour = anotherSoundBehaviour;
}
}
how to handle duplications of the code in those two services, let’s say both share the same private methods.
You can create one base, abstract class. So basic idea is to put common logic into some base common class. Then we should create abstract method in abstract class. Why? By doing this, subclasses will have particular logic for concrete case. Let me show an example.
An abstract class which has common behaviour:
public abstract class BaseMeal
{
// I am not Java guy, but if I am not mistaken, in Java,
// if you do not want method to be overriden, you shoud use `final` keyword
public void CommonBehaviourHere()
{
// put here code that can be shared among subclasses to avoid code duplication
}
public abstract void UnCommonBehaviourShouldBeImplementedBySubclass();
}
And its concrete implementations:
public class BurgerSubclass : BaseMeal // extends in Java
{
public override void UnCommonBehaviourShouldBeImplementedBySubclass()
{
throw new NotImplementedException();
}
}
public class PastaSubclass : BaseMeal // extends in Java
{
public override void UnCommonBehaviourShouldBeImplementedBySubclass()
{
throw new NotImplementedException();
}
}

Run same Junit Test with multiple objects derived from same interface

I am trying to improve my knowledge about testing I'm trying to achieve running the same JUnit test class with different objects derived from the same interface.
so we can assume the following:
interface Base {
void sort();
}
class A implements Base {
#Override
public void sort() {
//sort naively
}
}
class B implements Base {
#Override
public void sort() {
//sort using another better approach
}
}
class C implements Base {
#Override
public void sort() {
//sort using optimized approach
}
}
class Test {
#Test
void test1() {
Base obj = new A();
obj.sort();
obj.otherStuff();
}
}
class SecondTest {
//trying to avoid making multiple test classes that has only one line in difference
#Test
void test1() {
var obj = new B();
obj.sort();
obj.otherStuff();
}
So my question is how to run the test class with the objects from A,B,C without falling into the trap of duplicate code and redundancy?
Please note that I wrote this example just to illustrate my point, and the sort() doStuff() methods are just placeholders but when you have over ~70 line of code duplication in each test class it starts to look ugly and redundant.
*I have looked at #beforeEach, #Before, #After and I don't think I see a way where those might help me.

You can write a parameterized test with a MethodSource.
#ParameterizedTest
#MethodSource("bases")
void test1(Base obj) {
obj.sort();
obj.otherStuff();
}
static Stream<String> bases() {
return Stream.of(new A(), new B(), new C());
}

A way to fix it is the following, you create a method within your test class that takes as input the Base obj and contains all the duplicate lines. What you'll do then is to initialize the obj in different tests, then pass it to the method.
Here is a code that would do the job:
class Test {
#Test
void test1() {
Base obj = new A();
wrapperMethod(obj);
}
#Test
void test2() {
var obj = new B();
wrapperMethod(obj);
}
public static void wrapperMethod(Base obj){
obj.sort();
obj.otherStuff();
}
}
As a rule of thumb, testing can be much like normal programming where redundancy is avoided with methods to guarantee reusability.
Cheers,
D

First of all you have to fix your understanding of what UnitTesting is about.
UnitTesting is not about code (coverage).
UnitTesing is about verifying desired public behavior where "public behavior means return values and/or communication with dependencies.
Each test method should verify a single atomic assumption of the tested units desired behavior.
From this point of view it does not make sense to pass a bunch of objects sharing the same interface trough the same test method since these different interface implementations exist to implements the interfaces methods with their own unique behavior. In turn the assumption how the objects behave differ uniquely.
If all the objects where expected to behave identically (which is the only assumption a single test method could verify) there where no different objects (i.e. implementations) in the first place.

How to mocking the implemented methods of a class under test in Spring Boot with Mockito

I am unsure after much reading how to test the class below.
I have given a basic example...but assuming the class/implemented method could produce a more complex object (not just a String as below), how can I mock the interface so I can inject a mock in to the class to test various class behaviours?
For example, in the oversimplified below...if the length of the 'sayHello' was more than 500chars when calling the class 'getSayHelloLength()', I may want to Assert a 'HelloTooLongException' is thrown.
/**
* MyClass implements MyInterface.
*/
public class MyClass implements MyInterface {
public int getSayHelloLength() {
return sayHello().length();
}
//I want to change/Mock the return of the implemented interface.
#Override
public String sayHello() {
//Do some magic and some code an eventually return something based upon 'input'
// Magic
// More magic.
return "My Class to Test Says Hello!";
}
}
The interface:
public interface MyInterface {
String sayHello();
}
I am using JUnit5:
class MyClassTest {
#InjectMocks
private MyClass myClass;
#BeforeEach
void setUp() {
}
#Test
void getSayHelloLength() {
//Mock the interface 'myClass' implements as to test various "hellos" outputs.
}
}

Since you're not testing the interface (no code to test in there) but the implementation. There is no need to mock the interface. You don't want to mock the code you're testing in any case. You want to mock everything the code you're testing uses.
So supposed the 'Magic' part is in another class, you want to mock this one. If it isn't you might want to refactor your class until it is because then it's violating the Single-Responsibility-Principle since doing magic and saying hello seem to be very different concerns.

Thinking in Java 4th Edition - is it necessary to make a factory for isolating the code from implementation?

I am currently reading "Thinking in Java 4th edition". In the Chapter "Interface" and the sub-chapter "Interfaces and factories", it states the following
An interface is intended to be a gateway to multiple implementations,
and a typical way to produce objects that fit the interface is the
Factory Method design pattern. Instead of calling a constructor
directly, you call a creation method on a factory object which
produces an implementation of the interface—this way, in theory, your
code is completely isolated from the implementation of the interface,
thus making it possible to transparently swap one implementation for
another. Here’s a demonstration showing the structure of the Factory
Method:
(for easy reference, the example codes quoted after my question)
My question is that why don't we just make the "serviceConsumer" method to be like
public static void serviceConsumer(Service s) {
s.method1();
s.method2();
}
In this case, the code depends on the interface "Service" but not the implementation. (It can also "swap" transparently, isn't it?). So, I don't really get to the point of using "factory" here and what it states at start.
-----------------------------below quoted from "Thinking in Java"------------------------------
//: interfaces/Factories.java
import static net.mindview.util.Print.*;
interface Service {
void method1();
void method2();
}
interface ServiceFactory {
Service getService();
}
class Implementation1 implements Service {
Implementation1() {} // Package access
public void method1() {
print("Implementation1 method1");
}
public void method2() {
print("Implementation1 method2");
}
}
class Implementation1Factory implements ServiceFactory {
public Service getService() {
return new Implementation1();
}
}
class Implementation2 implements Service {
Implementation2() {} // Package access
public void method1() {
print("Implementation2 method1");
}
public void method2() {
print("Implementation2 method2");
}
}
class Implementation2Factory implements ServiceFactory {
public Service getService() {
return new Implementation2();
}
}
public class Factories {
public static void serviceConsumer(ServiceFactory fact) {
Service s = fact.getService();
s.method1();
s.method2();
}
public static void main(String[] args) {
serviceConsumer(new Implementation1Factory());
// Implementations are completely interchangeable:
serviceConsumer(new Implementation2Factory());
}
}
/* Output:
Implementation1 method1
Implementation1 method2
Implementation2 method1
Implementation2 method2
*/ //:~

Well nothing prevents you from writing such method, the quoted statement is about creation of the object itself.
In this case, the code depends on the interface "Service" but not the implementation
In both cases the code depends on the interface, the difference is, that in your implementation the Service is created outside the method serviceConsumer

Maybe it will be clearer if you see a real use of Factory Method. The TIJ example is without any context.
My favorite example is Collection.iterator(), where Collection is the ServiceFactory and Iterator is the Service. You can see the calls in the serviceConsumer() but think of the following:
Collection c = new ArrayList(); // ArrayList is a Factory for its iterator
Iterator i = c.iterator(); // getService()
if (i.hasNext()) { ...}
If serviceConsumer were a method to print the collection (instead of something without context), you could see how passing an ServiceFactory (ArrayList) is better than passing the Service (Iterator). There is more encapsulation using that (the details of the Service are hidden in the method).
Here are some UML diagrams to help understand the similarities:
Factory method pattern
TIJ Example
Collection.iterator()
Note: The pink classes are actually anonymous classes that implement the Iterator interface type that corresponds to the Collection. They're not normally classes a client will instantiate any other way (hidden).

Java instancing an interface results Odd behavior

I am just wandering if following is an odd behaviour.
public interface TestInterfaceTwo {
public void sayBye();
}
public interface TestInterfaceOne {
public void sayHI();
}
public abstract class TestIntefaceClass implements TestInterfaceOne, TestInterfaceTwo {
#Override
public void sayHI() {
System.out.println("HI");
}
#Override
public void sayBye() {
System.out.println("Bye");
}
}
public class InterfaceImplementer extends TestIntefaceClass{
#Override
public void sayHI() {
System.out.println("SAY HI");
}
}
public static void main(String[] args) {
InterfaceImplementer impl = new InterfaceImplementer();
TestInterfaceOne impl1 = new InterfaceImplementer();
TestInterfaceTwo impl2 = new InterfaceImplementer();
TestIntefaceClass impl3 = new InterfaceImplementer();
impl.sayHI();
impl.sayBye();
impl1.sayHI();
impl2.sayBye();
impl.sayBye();
impl3.sayBye();
impl3.sayHI();
}
These calls result the following
SAY HI
Bye
SAY HI
Bye
Bye
Bye
SAY HI
I needed to know if interface instances inherit only the expected behavior from the interface or if it inherits the abstract class. It seems it does the latter and I would like to know an explanation for this and if it is bug Or a feature. :)

This works as expected. I am not entirely sure what is that confuses you.
I needed to know if interface instances inherit only the expected behavior from the interface or if it inherits the abstract class. It seems it does the latter and I would like to know an explanation for this and if it is bug Or a feature. :)
Interfaces don't implement any 'behaviour' (although Java 8 provides default methods) and you can't instantiate one. All those instances you're creating are class instances - in your case, instances of InterfaceImplementer. So let's look at this class and its parent:
TestIntefaceClass implements two interfaces and their methods. Nothing special here.
InterfaceImplementer extends TestIntefaceClass class, it inherits the implementation of sayBye() but it provides its own implementation of sayHi().
Now the following (and the other similar examples from your code)
TestInterfaceOne impl = new InterfaceImplementer();
creates an instance of InterfaceImplementer, as you can see on the right hand side. Thus the implementations that will be used when calling sayHi() and sayBye() will be the ones that Interfaceimplementer overrides / inherits.
LE: This link will probably be useful to you. It discusses using interfaces as types, which is what you're doing.

the "new InterfaceImplementer()" is giving you exactly that ... its just you are decalring them as the various ways .... it's working as expected