Можно ли увидеть, через какой дочерний класс был вызван статический метод родителя в Java?

Вы не можете переопределить статические методы в Java, поэтому любые вызовы статического метода через подкласс будут привязаны к базовому классу во время компиляции. Таким образом, вызов B.testMethod() будет привязан к A.testMethod еще до запуска приложения.

Поскольку вы ищете информацию во время выполнения, она не будет доступна при обычных операциях Java.

Как отмечали другие, я не думаю, что проблема разрешима в Java, как вы ее ставите. Статический метод на самом деле не наследуется так же, как нестатический метод. (Извините, если я не совсем правильно использую терминологию.)

Тем не менее, мне кажется, есть много способов добиться желаемого результата, если вы готовы немного изменить свой интерфейс.

Наиболее очевидным было бы просто сделать вызов, используя родительский класс. Что плохого в написании

Person person=(Person)ActiveRecord.find(Person.class, "name", "Mike");

?

В качестве альтернативы вы можете сначала создать экземпляр типа записи, а затем выполнить поиск, чтобы заполнить его. Например

Person person=new Person();
person.find("name", "Mike");

В этот момент у вас есть объект Person, и если вам нужно узнать его класс из функции в супертипе, вы просто делаете "this.getClass()".

В качестве альтернативы вы можете создать фиктивный объект Person для выполнения вызовов, просто чтобы позволить вам выполнять getClass() при необходимости. Тогда ваша находка будет выглядеть примерно так:

Person dummyPerson=new Person();
Person realPerson=dummyPerson.find("name", "Mike");

Кстати, мне кажется, что любая попытка создать общий класс ActiveRecord будет означать, что возвращаемый тип find должен быть ActiveRecord, а не конкретный тип записи, поэтому вам, вероятно, придется привести его к правильному типу при возврат со звонка. Единственный способ победить это — иметь явное переопределение find в каждом объекте записи.

Я много раз писал общий код для обработки записей, но я всегда избегал создания объектов Java для каждого типа записей, потому что это неизменно оборачивалось написанием целой кучи кода. Я предпочитаю, чтобы объект Record был полностью универсальным и имел имена полей, индексы, что бы ни были внутренние данные и имена. Если я хочу получить поле «foo» из записи «bar», мой интерфейс будет выглядеть примерно так:

Record bar=Record.get(key);
String foo=bar.get("foo");

Скорее, чем:

BarRecord bar=BarRecord.get(key);
String foo=bar.getFoo();

Не так красиво, и это ограничивает проверку ошибок во время компиляции, но для реализации требуется меньше кода.

Вы бы не сделали этого в Java. Вы, вероятно, сделали бы что-то более похожее на:

public interface Finder<T, RT, CT>
{
    T find(RT colName, CT value);
}

public class PersonFinder
    implements Finder<Person, String, String>   
{
    public Person find(String nameCol, String name)
    {
        // code to find a person
    }
}

public class CarFinder
    implements Finder<Car, String, int>   
{
    public Person find(String yearCol, int year)
    {
        // code to find a car
    }
}

Это возможно, но это дорого.

Если вы можете найти способ вызвать его только один раз, тогда все готово.

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

Например, с этим ответ можно создать такой регистратор:

 class MyClass {
      private static final SomeLogger logger = SomeLogger.getLogger();
      ....
  }

И пусть этот регистратор создаст другой экземпляр в зависимости от того, кто его вызвал.

Итак, таким же образом у вас может быть что-то вроде:

 class A  {
      public static void myStatic() {
          // find out who call it
          String calledFrom = new RuntimeException()
                              .getStackTrace()[1].getClassName();
      }
 }

Это нормально для одноразовой инициализации. Но не на 1000 звонков. Хотя я не знаю, может ли хорошая виртуальная машина встроить это для вас.

Я бы пошел по пути AspectJ.

Моя теория по этому поводу, создав нечто подобное, заключается в использовании стратегии генерации кода для создания делегата для каждого класса, содержащего метод. У вас не может быть столько скрытого кода в Java, это, вероятно, не стоит усилий, пока вы генерируете что-то разумное. Если вы действительно хотите скрыть это, вы можете сделать что-то вроде...

public class Person extends PersonActiveRecord
{

}

//generated class, do not touch
public class PersonActiveRecord extends ActiveRecord
{
   public Person find(Map params)
   {
      ActiveRecord.find(Person.class, params);
   }
}

Но это имеет тенденцию слишком сильно портить вашу иерархию наследования. Я говорю, просто сгенерируйте классы и покончим с этим. Не стоит скрывать метод find.

Вы можете сделать это очень вручную, создав хакерский конструктор.

A example = new B(B.class);

И пусть конструктор суперкласса хранит переданный ему класс.

Я не думаю, что созданное выше исключение сработает, но если вы когда-нибудь захотите сделать что-то подобное, не создавая исключения...

Thread.currentThread().getStackTrace()

Возможно, вам удастся сделать это намного проще с помощью метапрограммирования и javassist.