Java: аннотация, ограничивающая вызов метода

Можно попробовать перегруженный sealed

Я не ооп-Java-гуру, но разве private на методе setup не поможет?

Суть в том, что его нужно вызывать не только из базового класса, но и из потомков.

Мои поверхностные познания Java застряли на восьмой версии.

Если ты такой извращенец, то есть 2 варианта.

1. Из метода сетап раскрутить стек вызовов и кинуть ошибку.

2. Вынеси метод сетап в нестед протектед класс и требуй инстанс этого класса в конструкторе базового класса.

sealed ввели в 15 чтобы указывать кому именно можно наследоваться, но я им сам пока не пользовался

В Error Prone есть @RestrictedApi, подойдёт?

Хотелось бы проверку времени компиляции, а не выполнения. То есть в обработчике аннотации глянуть откуда метод вызывается и в случае чего кинуть ошибку. Метод protected, из сторонних классов недоступен.

С вложенным классом немного непонятно. Если его передавать в super, то это мало чем поможет – на момент вызова конструктора базового класса часть данных еще не вычислена.

Похоже то, что доктор прописал, спасибо.

Это XY-problem.

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

Я не буду говорить, что за такое бил бы по рукам. Просто пролистай какую-нибудь древнюю EJ или GoF.

Первый способ не гарантирует переносимости, т. к. на разных JVM (HotSpot, J9,..) стек вызовов, в общем случае, будет разный.

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

XY проблема выглядит так. Для описания траектории на двухмерной плоскости есть несколько классов, в том числе AbstractElement как базовый класс для элементов траектории, таких как линия или дуга. Этот базовый класс включает данные о начальной и конечной точках и границы элемента. И если для линии границы вычисляются очень просто, то для дуги это довольно трудоемко и прямо в вызове super() не реализовать.

Можно сделать ленивую инициализацию границ в методе getBound(), но мне такое не нравится. Другой вариант – вызов метода setup() из конструктора линии или дуги.

Пишу с мобилки так что может быть криво.

final class Calculator {
    Object initData;
    Calculator (Object initData) {
        this.initData = initData;
    } 
    Object calc() {
        //your logic here
    } 
} 

class SuperPuperBasicClass {
    SuperPuperBasicClass(Calculator calc) {
    Object data = calc.calc();
    //do that you need
} 

class MyClass extends SuperPuperBasicClass {
    MyClass() {
        super(new Calculator(new Object())) ;
} 

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

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

Ну а разве потомки не должны вызвать родительский конструктор?

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

хмм, ты же видел, что в джаве появились sealed classes? :) Это ужасно, создатели языка не правы?

создатели языкаэффектиные манагеры из оракла не правы?

Поправил

У тебя кривой код, думай, как переделать, а не как навесить ещё больше костылей. Скорей всего тебе надо выкинуть все эти наследования и использовать factory method для создания экземпляров.

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

тогда protected?

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

Если ты совсем упоротый и чувствуешь в себе святые силы, то можешь написать для Maven плагин с помощью javaparser или чего-то такого, который будет отлавливать все вызовы «запретного» метода и фейлить компиляцию в конце

Я не вижу здесь никакого противоречия.

Sealed-классы позволяют создавать ограниченные иерархии наследования. Всё.

Все остальные принципы и требования ООП (включая здравый смысл) остаются в силе.

Искусство писать хороший код определяется, в первую очередь, умением выражать идеи (которым, если говорить про ООП, уже полвека), а вовсе не наличием в языке X синтаксического сахара Y. Typesafe Enum как подход описан у Блоха в EJ задолго до того, как Java 1.5 выразила эту идею на уровне «сахара».

И да, sealed-классы — они только в Java относительно недавно. В Scala и Kotlin они уже сто лет как.

Основной смысл sealed классов чтобы исчерпывающий паттерн-матчинг сделать. Это один из кирпичей для алгебраических типов данных.

Да, я в курсе, спасибо =)

Буду переделывать базовый класс, скорее всего часть методов сделаю абстрактными. Или что-то вроде такого

public final Bound getBound() {
    if (bound == null) {
        bound = calculateBound();
    }

    return bound;
}

protected abstract Bound calculateBound();

Bass, vbr спасибо за критику и предложения.