Transactional outbox pattern vs Event Sourcing

What is the exact difference between transactional outbox and event sourcing patterns? Both are competitive pattern and can be used for same purpose. Is there any example through which I can understand when to use what?

How to write a wrapper around a templated class that modifies the template parameters in C++?

template<typename T> class A {
};
template<typename T> class A1: public A<T>{
};
template<typename T> class A2: public A<T>{
};

We have a templated class A and derived classes A1 and A2.

Now I need a wrapper that accepts any class of type A* i.e any derived type of A, as a template parameter and modify its template parameter

template<typename T, typename Atype> class WrapperA {
   Atype<pair<T, int>> atypeobj;
};

Hoping to be used as follows

WrapperA<int, A1<int>> w1;
WrapperB<int, A2<int>> w2;

The WrapperA needs to work only with derived classes of A

Why send messages from the superclass to get specialisations in the template method pattern?

I've been reading Sandi Metz's book on OOP in Ruby. In the chapter on inheritance there is a section on the template method pattern.

It talks about having a base class with common behaviour, then subclasses that inherit this behaviour and implement their own specialised interfaces as needed.

The book goes on to discuss how to send messages from the base class to the subclass methods to get the specific behaviour and override defaults, like so:

class Bicycle
  attr_reader :size, :chain, :tire_size

  def initialize(**opts)
    @size = opts[:size]
    @chain = opts[:chain] || default_chain
    @tire_size = opts[:tire_size] || default_tire_size
  end

  def default_chain
    "11-speed"
  end

  def default_tire_size
    raise NotImplementedError
  end
end

class RoadBike < Bicycle
  def default_tire_size
    "23"
  end
end

What is the benefit of getting the base class to make this call to a method in a sub class, if the method can be defined in the subclass itself?

Decorator Design Pattern in C++

I have found this decorator design pattern on the internet here :

// CPP program to demonstrate
// Decorator pattern
#include <iostream>
#include <string>
using namespace std;

// Component
class MilkShake
{
public:
    virtual string Serve() = 0;
    virtual float price() = 0;
};


// Concrete Component
class BaseMilkShake : public MilkShake
{
public:
    string Serve()
    {
        return "MilkShake";
    }

    float price()
    {
        return 30;
    }
};

// Decorator
class MilkShakeDecorator: public MilkShake
{
protected:
    MilkShake *m_MilkShake;
public:

    MilkShakeDecorator(MilkShake *baseMilkShake): m_MilkShake(baseMilkShake){}

    string Serve()
    {
        return m_MilkShake->Serve();
    }

    float price()
    {
        return m_MilkShake->price();
    }
};


// Concrete Decorator
class MangoMilkShake: public MilkShakeDecorator
{
public:
    MangoMilkShake(MilkShake *baseMilkShake): MilkShakeDecorator(baseMilkShake){}

    string Serve()
    {
        return m_MilkShake->Serve() + " decorated with Mango ";
    }
    float price()
    {
        return m_MilkShake->price() + 40;
    }
};


class VanillaMilkShake: public MilkShakeDecorator
{
public:
    VanillaMilkShake(MilkShake *baseMilkShake): MilkShakeDecorator(baseMilkShake){}

    string Serve()
    {
        return m_MilkShake->Serve() + " decorated with Vanilla ";
    }
    float price()
    {
        return m_MilkShake->price() + 80;
    }
};

int main()
{
MilkShake *baseMilkShake = new BaseMilkShake();
cout << "Basic Milk shake \n";
cout << baseMilkShake -> Serve() << endl;
cout << baseMilkShake -> price() << endl;

MilkShake *decoratedMilkShake = new MangoMilkShake(baseMilkShake);
cout << "Mango decorated Milk shake \n";
cout << decoratedMilkShake -> Serve() << endl;
cout << decoratedMilkShake -> price() << endl;
    
delete decoratedMilkShake;

decoratedMilkShake = new VanillaMilkShake(baseMilkShake);
cout << "Vanilla decorated Milk shake \n";
cout << decoratedMilkShake -> Serve() << endl;
cout << decoratedMilkShake -> price() << endl;

delete decoratedMilkShake;
delete baseMilkShake;
return 0;
}

But I am wondering: why should the decorator class exist? If I delete it and use only the concrete decorators than everything still works as before. The only downside I see is the fact that I have to use a private pointer to MilkShake in the concrete decorators.

// CPP program to demonstrate
// Decorator pattern
#include <iostream>
#include <string>
using namespace std;
 
// Component
class MilkShake
{
public:
    virtual string Serve() = 0;
    virtual float price() = 0;
};
 
 
// Concrete Component 
class BaseMilkShake : public MilkShake
{
public:
    string Serve()
    {
        return "MilkShake";
    }
 
    float price()
    {
        return 30;
    }
};
 
class MangoMilkShake: public MilkShake
{
private:
    MilkShake *m_MilkShake;
public:
    MangoMilkShake(MilkShake *baseMilkShake): m_MilkShake(baseMilkShake){}
 
    string Serve()
    {
        return m_MilkShake->Serve() + " decorated with Mango ";
    }
    float price()
    {
        return m_MilkShake->price() + 40;
    }
};
 
 
class VanillaMilkShake: public MilkShake
{
private:
    MilkShake *m_MilkShake;
public:
    VanillaMilkShake(MilkShake *baseMilkShake): m_MilkShake(baseMilkShake){}
 
    string Serve()
    {
        return m_MilkShake->Serve() + " decorated with Vanilla ";
    }
    float price()
    {
        return m_MilkShake->price() + 80;
    }
};
 
 
int main()
{
  MilkShake *baseMilkShake = new BaseMilkShake();
  cout << "Basic Milk shake \n";
  cout << baseMilkShake -> Serve() << endl;
  cout << baseMilkShake -> price() << endl;   
 
  MilkShake *decoratedMilkShake = new MangoMilkShake(baseMilkShake);
  cout << "Mango decorated Milk shake \n";
  cout << decoratedMilkShake -> Serve() << endl;
  cout << decoratedMilkShake -> price() << endl;   
     
  delete decoratedMilkShake;
 
  decoratedMilkShake = new VanillaMilkShake(baseMilkShake);
  cout << "Vanilla decorated Milk shake \n";
  cout << decoratedMilkShake -> Serve() << endl;
  cout << decoratedMilkShake -> price() << endl;   
 
 delete decoratedMilkShake;
 delete baseMilkShake;
 return 0;
}

How to implement relationships between classes in a pacman game? (java)

So, I had this work at college in an object oriented programming subject where I was supposed to implement and improve some functions associated to a Pacman Game. I developed a solution, but I got so confused with the associations between the classes and some just didn't seem right. So, I would like to know what would be a better approach for this case.

The first thing to say is that there is a class called Element, which basically corresponds to all elements that the game contains. So, the walls, the pacdots, the power pellets, the pacman and the ghots are all Element. But I also created two interfaces: the MovableElement, which has the move() method, and EatableElement, which has the eaten() method.

Because of that, there are three others classes that extend the Element class and implements these interfaces: the AbstractEatableElement, which corresponds to the pacdots and power pellets for example, the AbstractMovableElement, which corresponds to the Pacman for example, and the AbstractMovableEatableElement, which corresponds to Ghosts, because they can be eaten in some circumstances (when a power pellet is eaten by the pacman) and they are movable objects.

I decided to use polymorphism by this method eaten() so the behavior that is supposed to happen when an eatable element is eaten is implemented in the concrete class. It's kind a Strategy Pattern, since we don't need to make a lot of conditionals to verify which type of class is so we can implement the behavior, this way we just implement the behavior inside each class, for example, the PacDot class will have its eaten() method and the PowerPellet and Ghost as well. But here is where things get kinda weird for me.

When a PacDot, a PowerPellet or a Ghost is eaten, the game is supposed to increase the points gotten by the Pacman, an integer attribute called "score" inside the Pacman class. But how exactly would the relationships would work here between the classes? Does that mean that I have to pass a reference of pacman every time I call the eaten() method, like pacdot.eaten(pacman)? This way just dont seem right, because the eaten() method could be able to interfere in others objects in the game, like the power pellet, which turns the ghosts into blue.

So, this was the first solution that I thought, but just seemed weird for me. So, I thought in another approach: each class of PacDot, PowerPellet and Ghost should have a reference to the pacman in their instance variable, and for the case of the PowerPellet (which turns the ghosts into blue when it's eaten), it should have a List of references of Ghosts of the game, so it can turn each one into the blue when the eaten() method of PowerPellet is called. But this solution also kinda sounded weird for me, because it kinda sounds like I'm making a composition between PacDot and Pacman, or between PowerPellet and Ghosts, which doesn't correspond to the real relationship between them.

Said that, I would like to know your opinions about that case. What would be the best way to implement a behavior when an Element is eaten by the Pacman? Is polymorphism in this case useful or is it just making things more messy?

public abstract class Element {
   protected Position pos;
   protected boolean isTransposable;
   /* constructor and others methods here */
}

public interface EatableElement {
   public void eaten();
}

public interface MovableElement {
   public void move();
}

public abstract class AbstractEatableElement extends Element implements EatableElement{
   //...
}

public class PacDots extends AbstractEatableElement{
        
   public PacDots() {
      // constructor
   }
   public void eaten() {
      pacman.increaseScore(this.numberPoints); // but how get pacman reference??
   }  
}

public class Pacman extends AbstractMovableElement {
    /* ... */
    public void eat(EatableElement e){
       e.eaten()
    }
}

Design pattern to make dependencies interchangeable

In the application I work on, we have a function called makeRequest. This function takes some parameters and then executes network calls to other systems. The beauty of this design is, if we wanted, we could switch our request library and the code would only need to be changed in one place. We currently use axios, but we could switch that out for superagent or native fetch and none of the external code would need to be changed. The interface decouples the inner workings of the function by creating an agnostic interface used by the rest of the application.

I know this is a design pattern. My question is what is its name? Is this the adapter pattern? The facade pattern?

Should developers add new methods in abstract implementations of interfaces?

Today, I noticed something about my OOP style.

Say I have an interface:

public interface Property<T> {

  String getName();

  String getValue(T target);

  void setValue(T target, String value);
}

I may create an abstract class:

public abstract class AbstractProperty<T> implements Property<T> {

  protected(final String name) {
    if(name == null) throw new IllegalArgumentException();

    this.name = name;
  }

  protected abstract T getValueSafe(T target);

  protected abstract T setValueSafe(T target, String value);

  private final String name;

  @Override
  public String getName() {
    return name;
  }

  @Override
  public String getValue(final T target) {
    if(target == null) throw new IllegalArgumentException();

    return getValueSafe(target);
  }

  @Override
  public void setValue(final T target, final String value) {
    if(target == null) throw new IllegalArgumentException();

    return setValueSafe(target, value);
  }

}

My question is, was it poor design to implement getValue and setValue in an abstract class implemented an interface, especially considering they are not field accessors?

From a OOP-in-Java perspective, would it make more sense to have an abstract class implementing only field accessors,

public abstract class AbstractProperty<T> implements Property<T> {

  protected(final String name) {
    if(name == null) throw new IllegalArgumentException();

    this.name = name;
  }

  private final String name;

  @Override
  public String getName() {
    return name;
  }

}

and another abstract class with added functionality:

public abstract class SimpleProperty<T> extends AbstractProperty<T> {

  protected(final String name) {
    super(name)
  }

  protected abstract T getValueSafe(T target);

  protected abstract T setValueSafe(T target, String value);

  @Override
  public String getValue(final T target) {
    if(target == null) throw new IllegalArgumentException();

    return getValueSafe(target);
  }

  @Override
  public void setValue(final T target, final String value) {
    if(target == null) throw new IllegalArgumentException();

    return setValueSafe(target, value);
  }

}

I can envision how the latter could offer more extensibility, but would love to hear thoughts from those more experiences.