Mam klasę, w której każda metoda zaczyna się tak samo:

class Foo {
  public void bar() {
    if (!fooIsEnabled) return;
    //...
  }
  public void baz() {
    if (!fooIsEnabled) return;
    //...
  }
  public void bat() {
    if (!fooIsEnabled) return;
    //...
  }
}

Czy istnieje dobry sposób na wymaganie (i miejmy nadzieję, że nie pisanie za każdym razem) fooIsEnabledczęści dla każdej metody publicznej w klasie?

Nie wiem o eleganckim, ale oto działająca implementacja wykorzystująca wbudowaną Javę, java.lang.reflect.Proxyktóra wymusza, że wszystkie wywołania metodFoo rozpoczynały się od sprawdzenia enabledstanu.

main metoda:

public static void main(String[] args) {
    Foo foo = Foo.newFoo();
    foo.setEnabled(false);
    foo.bar(); // won't print anything.
    foo.setEnabled(true);
    foo.bar(); // prints "Executing method bar"
}

Foo berło:

public interface Foo {
    boolean getEnabled();
    void setEnabled(boolean enable);

    void bar();
    void baz();
    void bat();

    // Needs Java 8 to have this convenience method here.
    static Foo newFoo() {
        FooFactory fooFactory = new FooFactory();
        return fooFactory.makeFoo();
    }
}

FooFactory klasa:

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class FooFactory {

    public Foo makeFoo() {
        return (Foo) Proxy.newProxyInstance(
                this.getClass().getClassLoader(),
                new Class[]{Foo.class},
                new FooInvocationHandler(new FooImpl()));
    }

    private static class FooImpl implements Foo {
        private boolean enabled = false;

        @Override
        public boolean getEnabled() {
            return this.enabled;
        }

        @Override
        public void setEnabled(boolean enable) {
            this.enabled = enable;
        }

        @Override
        public void bar() {
            System.out.println("Executing method bar");
        }

        @Override
        public void baz() {
            System.out.println("Executing method baz");
        }

        @Override
        public void bat() {
            System.out.println("Executing method bat");
        }

    }

    private static class FooInvocationHandler implements InvocationHandler {

        private FooImpl fooImpl;

        public FooInvocationHandler(FooImpl fooImpl) {
            this.fooImpl = fooImpl;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            if (method.getDeclaringClass() == Foo.class &&
                !method.getName().equals("getEnabled") &&
                !method.getName().equals("setEnabled")) {

                if (!this.fooImpl.getEnabled()) {
                    return null;
                }
            }

            return method.invoke(this.fooImpl, args);
        }
    }
}

Jak zauważyli inni, wydaje się, że to przesada, jeśli masz tylko kilka metod, o które musisz się martwić.

To powiedziawszy, z pewnością są korzyści:

• Osiągnięto pewien rozdział obaw, ponieważ Fooimplementacje metod nie muszą się martwić o enabledproblem przekrojowy sprawdzania. Zamiast tego kod metody musi tylko martwić się o jej podstawowy cel, nic więcej.
• Niewinny programista nie może dodać nowej metody do Fooklasy i omyłkowo „zapomnieć” o dodaniu enabledczeku. Plikenabled sprawdzania jest automatycznie dziedziczone przez każdą nowo dodaną metodę.
• Jeśli chcesz dodać kolejny problem przekrojowy lub jeśli chcesz ulepszyć enabled kontrolę, bardzo łatwo jest to zrobić bezpiecznie i w jednym miejscu.
• To całkiem fajne, że możesz uzyskać takie zachowanie podobne do AOP dzięki wbudowanej funkcjonalności Java. Nie jesteś zmuszony do integracji innych frameworków Spring, chociaż z pewnością mogą one być również dobrymi opcjami.

Aby być uczciwym, niektóre z wad to:

• Część kodu implementacji obsługującego wywołania proxy jest brzydka. Niektórzy powiedzieliby również, że posiadanie klas wewnętrznych zapobiegających tworzeniu instancji FooImplklasy jest brzydkie.
• Jeśli chcesz dodać nową metodę do Foo , musisz dokonać zmiany w 2 miejscach: klasie implementacji i interfejsie. Nic wielkiego, ale to jeszcze trochę więcej pracy.
• Wywołania proxy nie są bezpłatne. Istnieje pewne obciążenie związane z wydajnością. Jednak w przypadku ogólnego użytku nie będzie to zauważalne. Więcej informacji znajdziesz tutaj .

EDYTOWAĆ:

Komentarz Fabiana Streitela sprawił, że pomyślałem o 2 kłopotach z moim powyższym rozwiązaniem, które, przyznaję, nie jestem zadowolony z siebie:

1. Procedura obsługi wywołań używa magicznych łańcuchów do pominięcia „enabled-check” w metodach „getEnabled” i „setEnabled”. Może to łatwo się zepsuć, jeśli nazwy metod zostaną refaktoryzowane.
2. Jeśli byłby przypadek, w którym trzeba dodać nowe metody, które nie powinny dziedziczyć zachowania „enabled-check”, programista może łatwo popełnić błąd, a przynajmniej oznaczałoby to dodanie większej ilości magii smyczki.

Aby rozwiązać punkt 1 i przynajmniej złagodzić problem z punktem 2, utworzyłbym adnotację BypassCheck(lub coś podobnego), której mógłbym użyć do oznaczenia metod wFoo interfejsie, dla których nie chcę wykonywać polecenia „ włączona kontrola ”. W ten sposób nie potrzebuję w ogóle magicznych ciągów i programiście znacznie łatwiej będzie poprawnie dodać nową metodę w tym szczególnym przypadku.

Korzystając z rozwiązania adnotacji, kod wyglądałby tak:

main metoda:

public static void main(String[] args) {
    Foo foo = Foo.newFoo();
    foo.setEnabled(false);
    foo.bar(); // won't print anything.
    foo.setEnabled(true);
    foo.bar(); // prints "Executing method bar"
}

BypassCheck adnotacja:

import java.lang.annotation.*;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface BypassCheck {
}

Foo berło:

public interface Foo {
    @BypassCheck boolean getEnabled();
    @BypassCheck void setEnabled(boolean enable);

    void bar();
    void baz();
    void bat();

    // Needs Java 8 to have this convenience method here.
    static Foo newFoo() {
        FooFactory fooFactory = new FooFactory();
        return fooFactory.makeFoo();
    }
}

FooFactory klasa:

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class FooFactory {

    public Foo makeFoo() {
        return (Foo) Proxy.newProxyInstance(
                this.getClass().getClassLoader(),
                new Class[]{Foo.class},
                new FooInvocationHandler(new FooImpl()));
    }

    private static class FooImpl implements Foo {

        private boolean enabled = false;

        @Override
        public boolean getEnabled() {
            return this.enabled;
        }

        @Override
        public void setEnabled(boolean enable) {
            this.enabled = enable;
        }

        @Override
        public void bar() {
            System.out.println("Executing method bar");
        }

        @Override
        public void baz() {
            System.out.println("Executing method baz");
        }

        @Override
        public void bat() {
            System.out.println("Executing method bat");
        }

    }

    private static class FooInvocationHandler implements InvocationHandler {

        private FooImpl fooImpl;

        public FooInvocationHandler(FooImpl fooImpl) {
            this.fooImpl = fooImpl;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            if (method.getDeclaringClass() == Foo.class
                    && !method.isAnnotationPresent(BypassCheck.class) // no magic strings
                    && !this.fooImpl.getEnabled()) {

                return null;
            }

            return method.invoke(this.fooImpl, args);
        }
    }
}

Jest wiele dobrych sugestii ... co możesz zrobić, aby rozwiązać swój problem, to przemyśleć Wzorzec Stanu i zaimplementować go.

Spójrz na ten fragment kodu ... być może doprowadzi Cię do pomysłu. W tym scenariuszu wygląda na to, że chcesz zmodyfikować całą implementację metod na podstawie wewnętrznego stanu obiektu. Proszę pamiętać, że suma metod w obiekcie jest określana jako zachowanie.

public class Foo {

      private FooBehaviour currentBehaviour = new FooEnabledBehaviour (); // or disabled, or use a static factory method for getting the default behaviour

      public void bar() {
        currentBehaviour.bar();
      }
      public void baz() {
        currentBehaviour.baz();
      }
      public void bat() {
        currentBehaviour.bat();
      }

      public void setFooEnabled (boolean fooEnabled) { // when you set fooEnabel, you are changing at runtime what implementation will be called.
        if (fooEnabled) {
          currentBehaviour = new FooEnabledBehaviour ();
        } else {
          currentBehaviour = new FooDisabledBehaviour ();
        }
      }

      private interface FooBehaviour {
        public void bar();
        public void baz();
        public void bat();
      }

      // RENEMBER THAT instance method of inner classes can refer directly to instance members defined in its enclosing class
      private class FooEnabledBehaviour implements FooBehaviour {
        public void bar() {
          // do what you want... when is enabled
        }
        public void baz() {}
        public void bat() {}

      }

      private class FooDisabledBehaviour implements FooBehaviour {
        public void bar() {
          // do what you want... when is desibled
        }
        public void baz() {}
        public void bat() {}

      }
}

Mam nadzieję że ci się spodoba!

PD: Jest implementacją Wzorca Stanu (znany również jako Strategia w zależności od kontekstu .. ale zasady są takie same).

Tak, ale to trochę pracy, więc to zależy od tego, jak ważne jest to dla Ciebie.

Możesz zdefiniować klasę jako interfejs, napisać implementację delegata, a następnie użyć java.lang.reflect.Proxydo zaimplementowania interfejsu z metodami, które wykonują część udostępnioną, a następnie warunkowo wywołać delegata.

interface Foo {
    public void bar();
    public void baz();
    public void bat();
}

class FooImpl implements Foo {
    public void bar() {
      //... <-- your logic represented by this notation above
    }

    public void baz() {
      //... <-- your logic represented by this notation above
    }

    // and so forth
}

Foo underlying = new FooImpl();
InvocationHandler handler = new MyInvocationHandler(underlying);
Foo f = (Foo) Proxy.newProxyInstance(Foo.class.getClassLoader(),
     new Class[] { Foo.class },
     handler);

Twój MyInvocationHandlermoże wyglądać mniej więcej tak (pominięto obsługę błędów i tworzenie szkieletów klas, zakładając, że fooIsEnabledjest zdefiniowane w dostępnym miejscu):

public Object invoke(Object proxy, Method method, Object[] args) {
    if (!fooIsEnabled) return null;
    return method.invoke(underlying, args);
}

To nie jest niesamowicie ładne. Ale w przeciwieństwie do różnych komentatorów, zrobiłbym to, ponieważ myślę, że powtarzanie jest ważniejszym ryzykiem niż tego rodzaju gęstość, i będziesz w stanie stworzyć "odczucie" swojej prawdziwej klasy, z tym nieco nieodgadnionym opakowaniem dodanym bardzo lokalnie w zaledwie kilku wierszach kodu.

Zobacz dokumentację Java aby uzyskać szczegółowe informacje na temat dynamicznych klas proxy.

To pytanie jest ściśle związane z programowaniem aspektowym . AspectJ jest rozszerzeniem AOP języka Java i możesz rzucić okiem, aby uzyskać trochę ispiracji.

O ile wiem, nie ma bezpośredniego wsparcia dla AOP w Javie. Jest kilka wzorców GOF, które się z nim wiążą, jak na przykład Template Method i Strategy, ale tak naprawdę nie zaoszczędzą one linii kodu.

W Javie i większości innych języków można zdefiniować powtarzającą się logikę, której potrzebujesz w funkcjach i zastosować tak zwane zdyscyplinowane podejście do kodowania, w którym wywołujesz je we właściwym czasie.

public void checkBalance() {
    checkSomePrecondition();
    ...
    checkSomePostcondition();
}

Jednak to nie pasowałoby do twojego przypadku, ponieważ chciałbyś, aby kod wyodrębniony z faktury mógł powrócić z checkBalance. W językach, które obsługują makra (jak C / C ++), można zdefiniować checkSomePreconditioni checkSomePostconditionjako makra, a zostaną one po prostu zastąpione przez preprocesor, zanim jeszcze zostanie wywołany kompilator:

#define checkSomePrecondition \
    if (!fooIsEnabled) return;

Java nie ma tego po wyjęciu z pudełka. Może to kogoś urazić, ale w przeszłości korzystałem z automatycznego generowania kodu i silników szablonów, aby zautomatyzować powtarzalne zadania związane z kodowaniem. Jeśli przetwarzasz pliki Java przed skompilowaniem ich za pomocą odpowiedniego preprocesora, na przykład Jinja2, możesz zrobić coś podobnego do tego, co jest możliwe w C.

Możliwe podejście w czystej Javie

Jeśli szukasz czystego rozwiązania w języku Java, to, co możesz znaleźć, prawdopodobnie nie będzie zwięzłe. Ale nadal może uwzględniać wspólne części programu i unikać powielania kodu i błędów. Mógłbyś zrobić coś takiego (jest to jakiś wzorzec inspirowany strategią ). Zwróć uwagę, że w C # i Javie 8 oraz w innych językach, w których funkcje są nieco łatwiejsze w obsłudze, takie podejście może faktycznie wyglądać ładnie.

public interface Code {
    void execute();
}

...

public class Foo {
  private bool fooIsEnabled;

  private void protect(Code c) {
      if (!fooIsEnabled) return;
      c.execute();
  }

  public void bar() {
    protect(new Code {
      public void execute() {
        System.out.println("bar");
      }
    });
  }

  public void baz() {
    protect(new Code {
      public void execute() {
        System.out.println("baz");
      }
    });
  }

  public void bat() {
    protect(new Code {
      public void execute() {
        System.out.println("bat");
      }
    });
  }
}

Coś w rodzaju prawdziwego scenariusza

Tworzysz klasę do wysyłania ramek danych do robota przemysłowego. Wykonanie polecenia wymaga czasu. Po wykonaniu polecenia wysyła z powrotem ramkę sterującą. Robot może ulec uszkodzeniu, jeśli otrzyma nowe polecenie, podczas gdy poprzednie jest nadal wykonywane. Twój program używa DataLinkklasy do wysyłania i odbierania ramek do i od robota. Musisz zabezpieczyć dostęp doDataLink instancji.

Połączenia gwintowe interfejs użytkownika RobotController.left, right, uplub downgdy użytkownik kliknie przycisków, ale również wywołuje BaseController.tickw regularnych odstępach czasu, w celu przekazywania poleceń ponownie włączyć do prywatnej DataLinkinstancji.

interface Code {
    void ready(DataLink dataLink);
}

class BaseController {
    private DataLink mDataLink;
    private boolean mReady = false;
    private Queue<Code> mEnqueued = new LinkedList<Code>();

    public BaseController(DataLink dl) {
        mDataLink = dl;
    }

    protected void protect(Code c) {
        if (mReady) {
            mReady = false;
            c.ready(mDataLink);
        }
        else {
            mEnqueue.add(c);
        }
    }

    public void tick() {
        byte[] frame = mDataLink.readWithTimeout(/* Not more than 50 ms */);

        if (frame != null && /* Check that it's an ACK frame */) {
          if (mEnqueued.isEmpty()) {
              mReady = true;
          }
          else {
              Code c = mEnqueued.remove();
              c.ready(mDataLink);
          }
        }
    }
}

class RobotController extends BaseController {
    public void left(float amount) {
        protect(new Code() { public void ready(DataLink dataLink) {
            dataLink.write(/* Create a byte[] that means 'left' by amount */);
        }});
    }

    public void right(float amount) {
        protect(new Code() { public void ready(DataLink dataLink) {
            dataLink.write(/* Create a byte[] that means 'right' by amount */);
        }});
    }

    public void up(float amount) {
        protect(new Code() { public void ready(DataLink dataLink) {
            dataLink.write(/* Create a byte[] that means 'up' by amount */);
        }});
    }

    public void down(float amount) {
        protect(new Code() { public void ready(DataLink dataLink) {
            dataLink.write(/* Create a byte[] that means 'down' by amount */);
        }});
    }
}

Rozważyłbym refaktoryzację. Ten wzór mocno łamie SUCHY wzór (nie powtarzaj tego). Wierzę, że to łamie tę klasową odpowiedzialność. Ale to zależy od twojej kontroli nad kodem. Twoje pytanie jest bardzo otwarte - gdzie dzwonisz do Fooinstancji?

Przypuszczam, że masz taki kod

foo.bar(); // does nothing if !fooEnabled
foo.baz(); // does also nothing
foo.bat(); // also

może powinieneś to nazwać mniej więcej tak:

if (fooEnabled) {
   foo.bat();
   foo.baz();
   ...
}

I utrzymuj to w czystości. Na przykład rejestrowanie:

this.logger.debug(createResourceExpensiveDump())

a logger nie zadaje sobie pytania , czy debugowanie jest włączone. Po prostu rejestruje.

Zamiast tego dzwoniąc do klasy, musisz to sprawdzić:

if (this.logger.isDebugEnabled()) {
   this.logger.debug(createResourceExpensiveDump())
}

Jeśli to jest biblioteka i nie możesz kontrolować wywoływania tej klasy, wyrzuć, IllegalStateExceptionco wyjaśnia dlaczego, jeśli to wywołanie jest nielegalne i powoduje problemy.

IMHO najbardziej eleganckim i najskuteczniejszym rozwiązaniem tego problemu jest posiadanie więcej niż jednej implementacji Foo, wraz z fabryczną metodą jej tworzenia:

class Foo {
  protected Foo() {
    // Prevent direct instantiation
  }

  public void bar() {
    // Do something
  }

  public static void getFoo() {
    return fooEnabled ? new Foo() : new NopFoo();
  }
}

class NopFoo extends Foo {
  public void bar() {
    // Do nothing
  }
}

Lub odmiana:

class Foo {
  protected Foo() {
    // Prevent direct instantiation
  }

  public void bar() {
    // Do something
  }

  public static void getFoo() {
    return fooEnabled ? new Foo() : NOP_FOO;
  }

  private static Foo NOP_FOO = new Foo() {
    public void bar() {
      // Do nothing
    }
  };
}

Jak wskazuje sstan, jeszcze lepiej byłoby użyć interfejsu:

public interface Foo {
  void bar();

  static Foo getFoo() {
    return fooEnabled ? new FooImpl() : new NopFoo();
  }
}

class FooImpl implements Foo {
  FooImpl() {
    // Prevent direct instantiation
  }

  public void bar() {
    // Do something
  }
}

class NopFoo implements Foo {
  NopFoo() {
    // Prevent direct instantiation
  }

  public void bar() {
    // Do nothing
  }
}

Dostosuj to do reszty swoich okoliczności (czy za każdym razem tworzysz nowe Foo, czy ponownie używasz tej samej instancji itp.)

Mam inne podejście: mam

interface Foo {
  public void bar();
  public void baz();
  public void bat();
}

class FooImpl implements Foo {
  public void bar() {
    //...
  }
  public void baz() {
    //...
  }
  public void bat() {
    //...
  }
}

class NullFoo implements Foo {
  static NullFoo DEFAULT = new NullFoo();
  public void bar() {}
  public void baz() {}
  public void bat() {}
}

}

i wtedy możesz to zrobić

(isFooEnabled ? foo : NullFoo.DEFAULT).bar();

Być może można nawet zastąpić isFooEnabledo Foozmiennej które albo przytrzymuje FooImplbyć używany lub NullFoo.DEFAULT. Wtedy połączenie jest znowu prostsze:

Foo toBeUsed = isFooEnabled ? foo : NullFoo.DEFAULT;
toBeUsed.bar();
toBeUsed.baz();
toBeUsed.bat();

BTW, nazywa się to „wzorcem zerowym”.

W podobnym funkcjonalnym podejściu do odpowiedzi @ Colina, z funkcjami lambda Java 8 , możliwe jest zawinięcie warunkowego przełączania funkcji włączania / wyłączania kodu do metody guard ( executeIfEnabled), która akceptuje lambdę akcji, do której kod może być warunkowo wykonany przeszedł.

Chociaż w twoim przypadku to podejście nie zapisuje żadnych wierszy kodu, poprzez suszenie tego, masz teraz możliwość scentralizowania innych problemów związanych z przełączaniem funkcji, a także problemów z AOP lub debugowaniem, takich jak logowanie, diagnostyka, profilowanie i in.

Jedną korzyścią z używania tutaj lambd jest to, że można użyć zamknięć, aby uniknąć konieczności przeciążania executeIfEnabled metody.

Na przykład:

class Foo {
    private Boolean _fooIsEnabled;

    public Foo(Boolean isEnabled) {
        _fooIsEnabled = isEnabled;
    }

    private void executeIfEnabled(java.util.function.Consumer someAction) {
        // Conditional toggle short circuit
        if (!_fooIsEnabled) return;

        // Invoke action
        someAction.accept(null);
    }

    // Wrap the conditionally executed code in a lambda
    public void bar() {
        executeIfEnabled((x) -> {
            System.out.println("Bar invoked");
        });
    }

    // Demo with closure arguments and locals
    public void baz(int y) {
        executeIfEnabled((x) -> {
            System.out.printf("Baz invoked %d \n", y);
        });
    }

    public void bat() {
        int z = 5;
        executeIfEnabled((x) -> {
            System.out.printf("Bat invoked %d \n", z);
        });
    }

Z testem:

public static void main(String args[]){
    Foo enabledFoo = new Foo(true);
    enabledFoo.bar();
    enabledFoo.baz(33);
    enabledFoo.bat();

    Foo disabledFoo = new Foo(false);
    disabledFoo.bar();
    disabledFoo.baz(66);
    disabledFoo.bat();
}

Jak wskazano w innych odpowiedziach, wzorzec projektowania strategii jest odpowiednim wzorcem projektowym, aby uprościć ten kod. Zilustrowałem to tutaj za pomocą wywołania metody poprzez odbicie, ale istnieje wiele mechanizmów, których można użyć, aby uzyskać ten sam efekt.

class Foo {

  public static void main(String[] args) {
      Foo foo = new Foo();
      foo.fooIsEnabled = false;
      foo.execute("bar");
      foo.fooIsEnabled = true;
      foo.execute("baz");
  }

  boolean fooIsEnabled;

  public void execute(String method) {
    if(!fooIsEnabled) {return;}
    try {
       this.getClass().getDeclaredMethod(method, (Class<?>[])null).invoke(this, (Object[])null);
    }
    catch(Exception e) {
       // best to handle each exception type separately
       e.printStackTrace();
    }
  }

  // Changed methods to private to reinforce usage of execute method
  private void bar() {
    System.out.println("bar called");
    // bar stuff here...
  }
  private void baz() {
    System.out.println("baz called");
    // baz stuff here...
  }
  private void bat() {
    System.out.println("bat called");
    // bat stuff here...
  }
}

Gdyby tylko java była trochę lepsza w działaniu. Uważa się, że najlepszym rozwiązaniem OOO jest utworzenie klasy, która opakowuje pojedynczą funkcję, więc jest wywoływana tylko wtedy, gdy włączone jest foo.

abstract class FunctionWrapper {
    Foo owner;

    public FunctionWrapper(Foo f){
        this.owner = f;
    }

    public final void call(){
        if (!owner.isEnabled()){
            return;
        }
        innerCall();
    }

    protected abstract void innerCall();
}

a następnie wdrożenie bar, bazi batjak anonimowych klas, które rozciągają się FunctionWrapper.

class Foo {
    public boolean fooIsEnabled;

    public boolean isEnabled(){
        return fooIsEnabled;
    }

    public final FunctionWrapper bar = new FunctionWrapper(this){
        @Override
        protected void innerCall() {
            // do whatever
        }
    };

    public final FunctionWrapper baz = new FunctionWrapper(this){
        @Override
        protected void innerCall() {
            // do whatever
        }
    };

    // you can pass in parms like so 
    public final FunctionWrapper bat = new FunctionWrapper(this){
        // some parms:
        int x,y;
        // a way to set them
        public void setParms(int x,int y){
            this.x=x;
            this.y=y;
        }

        @Override
        protected void innerCall() {
            // do whatever using x and y
        }
    };
}

Inny pomysł

Użyj rozwiązania glglgl dopuszczającego wartość null, ale make FooImpli NullFooklasy wewnętrzne (z prywatnymi konstruktorami) poniższej klasy:

class FooGateKeeper {

    public boolean enabled;

    private Foo myFooImpl;
    private Foo myNullFoo;

    public FooGateKeeper(){
        myFooImpl= new FooImpl();
        myNullFoo= new NullFoo();
    }

    public Foo getFoo(){
        if (enabled){
            return myFooImpl;
        }
        return myNullFoo;
    }  
}

w ten sposób nie musisz martwić się o pamiętanie o użyciu (isFooEnabled ? foo : NullFoo.DEFAULT).

Wygląda na to, że klasa nic nie robi, gdy Foo nie jest włączone, więc dlaczego nie wyrazić tego na wyższym poziomie, na którym tworzysz lub pobierasz instancję Foo?

class FooFactory
{
 static public Foo getFoo()
 {
   return isFooEnabled ? new Foo() : null;
 }
}
 ...
 Foo foo = FooFactory.getFoo();
 if(foo!=null)
 {
   foo.bar();
   ....
 }     

Działa to tylko wtedy, gdy isFooEnabled jest stałą. W ogólnym przypadku możesz utworzyć własną adnotację.

Nie znam składni języka Java. Założenie, że w Javie istnieje polimorfizm, własność statyczna, abstrakcyjna klasa i metoda:

    public static void main(String[] args) {
    Foo.fooIsEnabled = true; // static property, not particular to a specific instance  

    Foo foo = new bar();
    foo.mainMethod();

    foo = new baz();
    foo.mainMethod();

    foo = new bat();
    foo.mainMethod();
}

    public abstract class Foo{
      static boolean fooIsEnabled;

      public void mainMethod()
      {
          if(!fooIsEnabled)
              return;

          baMethod();
      }     
      protected abstract void baMethod();
    }
    public class bar extends Foo {
        protected override baMethod()
        {
            // bar implementation
        }
    }
    public class bat extends Foo {
        protected override baMethod()
        {
            // bat implementation
        }
    }
    public class baz extends Foo {
        protected override baMethod()
        {
            // baz implementation
        }
    }

Zasadniczo masz flagę, że jeśli jest ustawiona, wywołanie funkcji powinno zostać pominięte. Więc myślę, że moje rozwiązanie byłoby głupie, ale oto ono.

Foo foo = new Foo();

if (foo.isEnabled())
{
    foo.doSomething();
}

Oto implementacja prostego serwera proxy, na wypadek gdybyś chciał wykonać jakiś kod przed wykonaniem jakiejkolwiek funkcji.

class Proxy<T>
{
    private T obj;
    private Method<T> proxy;

    Proxy(Method<T> proxy)
    {
        this.ojb = new T();
        this.proxy = proxy;
    }

    Proxy(T obj, Method<T> proxy)
    {
        this.obj = obj;
        this.proxy = proxy;
    }

    public T object ()
    {
        this.proxy(this.obj);
        return this.obj;
    }
}

class Test
{
    public static void func (Foo foo)
    {
        // ..
    }

    public static void main (String [] args)
    {
        Proxy<Foo> p = new Proxy(Test.func);

        // how to use
        p.object().doSomething();
    }
}

class Foo
{
    public void doSomething ()
    {
        // ..
    }
}

Istnieje inne rozwiązanie, wykorzystujące delegata (wskaźnik do funkcji). Możesz mieć unikalną metodę, która najpierw przeprowadza walidację, a następnie wywołuje odpowiednią metodę zgodnie z wywoływaną funkcją (parametrem). Kod C #:

internal delegate void InvokeBaxxxDelegate();

class Test
{
    private bool fooIsEnabled;

    public Test(bool fooIsEnabled)
    {
        this.fooIsEnabled = fooIsEnabled;
    }

    public void Bar()
    {
        InvokeBaxxx(InvokeBar);
    }

    public void Baz()
    {
        InvokeBaxxx(InvokeBaz);
    }

    public void Bat()
    {
        InvokeBaxxx(InvokeBat);
    }

    private void InvokeBaxxx(InvokeBaxxxDelegate invoker)
    {
        if (!fooIsEnabled) return;
        invoker();
    }

    private void InvokeBar()
    {
        // do Invoke bar stuff
        Console.WriteLine("I am Bar");
    }

    private void InvokeBaz()
    {
        // do Invoke bar stuff
        Console.WriteLine("I am Baz");
    }

    private void InvokeBat()
    {
        // do Invoke bar stuff
        Console.WriteLine("I am Bat");
    }
}