Który sposób walidacji parametru polecacie?

Załóżmy, że mamy metodę:

ObjectTwo doSomething(ObjectOne o);

Metoda ta nie jest bezstanowa. Czasami może prawidłowo zwrócić instancję ObjectTwo, a czasami nie i do takiej sytuacji nie chcemy dopuścić. Stan klasy jest niedostępny z zewnątrz. Oba flow funkcji są 'oczekiwane', tzn. całkiem normalne, że dla danego parametru i stanu będziemy chcieli powiadomić użytkownika naszego API, że nie można wykonać akcji. Wielowątkowość odstawmy na bok. Pomińmy, proszę, sprawę frameworków. Wiadomo, że fajnie łapie się Runtime w interceptory, ale załóżmy, że jest to aplikacja konsolowa.

Pytanie, w jaki sposób zaprojektować API, żeby dla klienta było bezpieczne i przyjemne?

1. Dodać w API metodę sprawdzającą czy wszystko gra i można wywołać metodę doSomething

boolean isAbleToDoSomething(ObjectOne o);

? Każde wywołanie będzie musiało poprzedzać sprawdzenie czy takie wywołanie ma sens, co już samo w sobie jest słabe.

2. Rzucać RuntimeException.

3. Rzucać CheckedException.

4. Zmienić sygnaturę na Optionala?

5. Wasze propozycje.

1 - jest głupie bo masz klasyczny problem check-then-act z tego co rozumiem, bo mozliwość wykonania akcji może ulegać zmianie w czasie, więc co mi po takim sprawdzeniu skoro za chwile kiedy wywołam akcje już nie będę jednak mógł jej wykonać?
2 - bez senesu bo RuntimeException sygnalizuje "błąd", coś poszło nie tak, a u ciebie to jest sytuacja zupełnie normalna, a sterowanie przepływem za pomocą wyjątków to słaby pomysł, szczególnie że RuntimeException są "niewidzialne", więc zwykle handler który je łapie jest gdzieś "wysoko"
3 - trochę lepiej niż 2) bo przynajmniej user wie że coś może się dziwnego stać, ale znów exception to jest sygnalizacja jakiegoś "problemu" a u ciebie to jest w miare normalna sytuacja.

Moja sugestia: zwracać Optional<T>

Zwracać Optional od tego jest monadą, żeby z niego korzystać. Choć nie jest on najlepszym wyborem. Znacznie lepiej dołożyć sobie Javaslang i użyć Either. Wtedy mamy dostęp do informacji co jest nie tak (w ramach projekcji Left), albo rezultatu (projekcja Right).

Swoją drogą funkcja, której wynik zależy od stanu to zło w czystej postaci. Mamy tu specyficzny przypadek efektu ubocznego, a z nimi należy obchodzić się na przykład tak http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html - do pogooglania tematy side effect, monad, pure functions.

wg mnie po co robić taką funkcję która zwraca parametr w zależności od jakiegoś pola? to co napisał @Koziołek

zrób sobie if(objecta condition) { tutaj to co trzeba zrobić}

albo jeszcze lepiej jeżeli to możliwe to funkcję zwracającą objetcTwo wrąbać do środka objectOne, i wsio

Wystawiam interfejs - fasadę pewnej części aplikacji. Metoda ma wybrać coś z a'la cache, jeśli coś tam faktycznie jest.

No to ewidentnie Optional ;] Potem możesz w kodzie zrobić po prostu T x = cache.get(param).orElse(calculateNewValue());