Каков будет подход ООП? (или ВАШ подход?)

Ответ в том, что это зависит от обстоятельств.

Если P, Q и R имеют сильную значимую связь с экземпляром A, вы можете рассмотреть возможность добавления их в качестве членов класса A.

public class A {

  private P p;
  private Q q;
  private R r;

  public A(P p, Q q, R r) {
    this.p = p;
    this.q = q;
    this.r = r;
  }

  public void x() {
    p.doSomething();
    q.doSomething();
    r.doSomething();
  }

}

Если P, Q и R не являются, а являются просто «некоторыми значениями» "которые помогают действию X выполнить свою задачу, тогда вы можете захотеть использовать их в качестве параметров

public class A {

  public void x(P p, Q q, R r) {
    p.doSomething();
    q.doSomething();
    r.doSomething();
  }

}

Вторая версия не поддерживает никакого состояния, поэтому по определению является поточно-ориентированной

Передайте P, Q и R в A каким-либо образом, либо установив их как свойства A, либо передав их в X (в зависимости от того, являются ли PQR специфичными для X или они могут понадобиться A и в других ситуациях).

Это слишком общий вопрос для конкретного ответа. В определенных ситуациях может быть хорош любой из подходов. Некоторые факторы:

• передача P, Q и R в качестве параметров облегчает повторное использование и тестирование A (см. Dependency Injection)
• если P, Q и R больше нигде не используются вне A, их можно сделать локальными методами
• если P, Q и R также используются в других методах A, их можно сделать членами

Если значения можно использовать повторно, передайте их (или часть) в качестве параметров. В противном случае создайте их как локальные переменные внутри X.

Подход 1

class A{
  ctor(P, Q, R)
  {
  }
  void X()
  {
    P.SomeMethod();
    Q.SomeMethod();
    R.SomeMethod();
  }
}

Подход 2

class A{
  void X(P, Q, R)
  {
    P.SomeMethod();
    Q.SomeMethod();
    R.SomeMethod();
  }
}

Дизайн классов - это подмножество дизайна программного обеспечения: так что все зависит.

Поскольку вопрос немного субъективен (у всех свой подход), я скажу только, что использую этот метод, не говоря, что он лучший. Наверное, есть много разных способов.

public interface FuncX {

    public void actionX(FuncP p, FuncQ q, FuncR r);

}

И пусть классы реализуют этот интерфейс. Если два класса небольшие, но связаны, я разрешаю им реализовать оба интерфейса.

Это упрощает тестирование каждой реализации. Для начальной загрузки системы основной метод должен создавать экземпляры определенных классов. Например, это можно настроить.

public class MyFuncX implements FuncX, FuncP {

    public void actionX(FuncP p, FuncQ q, FuncR r) {
        ...
    }

    public void actionP(...) {
        ...
    }

}

// the caller:
FuncX x = new MyFuncX(); // dependency
FuncQ q = ...;
FuncR r = ...;

x.actionX(x, q, r);

По-моему, это похоже на работу по Композитному паттерну.

В основном вы передаете объекты P, Q и R в A, а затем выполняете определенный метод внутри каждого из них. Этот паттерн используется, когда вам нужно, чтобы несколько объектов выполняли одно и то же действие. Так, в примере, приведенном в Вики, вы, в основном, делаете что-то вроде этого:

graphic1.add(ellipse1);
graphic1.add(ellipse2);
graphic1.add(ellipse3);

graphic.print();

и graphic.print(); вызываете метод print внутри каждого из объектов эллипса.

В вашем проекте, если время жизни объектов P, Q, R лежит в пределах действия X, тогда создайте объекты внутри самого действия. Вместо этого, если время жизни не зависит от действия X, передайте его в качестве аргумента. Также позаботьтесь о размахе объектов P, Q, R. Я рекомендую вам изучить такие концепции, как ассоциация, агрегация, композиция и зависимость, прежде чем создавать класс. После того, как вы поймете эти концепции, позвоните в зависимости от объема и срока службы объектов.

Сделать это наиболее удобным способом?

Вы можете написать функцию/метод, принимающий 18+ аргументов, но это не совсем удобно.

Если метод, который собирается выполнить действие A, всегда получает одни и те же аргументы (и вы очень уверены, что это не изменится), я не вижу, зачем вам нужно передавать их по аргументам.

С другой стороны, я обычно не придерживаюсь стандартов и не знаю, как бы поступили в этой ситуации другие фундаменталисты ООП (гуру хайпа).