delegate

|

https://stackoverflow.com/questions/44912/java-delegates

 

Depending precisely what you mean, you can achieve a similar effect (passing around a method) using the Strategy Pattern.

Instead of a line like this declaring a named method signature:

// C#
public delegate void SomeFunction();

declare an interface:

// Java
public interface ISomeBehaviour {
   void SomeFunction();
}

For concrete implementations of the method, define a class that implements the behaviour:

// Java
public class TypeABehaviour implements ISomeBehaviour {
   public void SomeFunction() {
      // TypeA behaviour
   }
}

public class TypeBBehaviour implements ISomeBehaviour {
   public void SomeFunction() {
      // TypeB behaviour
   }
}

Then wherever you would have had a SomeFunction delegate in C#, use an ISomeBehaviour reference instead:

// C#
SomeFunction doSomething = someMethod;
doSomething();
doSomething = someOtherMethod;
doSomething();

// Java
ISomeBehaviour someBehaviour = new TypeABehaviour();
someBehaviour.SomeFunction();
someBehaviour = new TypeBBehaviour();
someBehaviour.SomeFunction();

With anonymous inner classes, you can even avoid declaring separate named classes and almost treat them like real delegate functions.

// Java
public void SomeMethod(ISomeBehaviour pSomeBehaviour) {
   ...
}

...

SomeMethod(new ISomeBehaviour() { 
   @Override
   public void SomeFunction() {
      // your implementation
   }
});

This should probably only be used when the implementation is very specific to the current context and wouldn't benefit from being reused.

And then of course in Java 8, these do become basically lambda expressions:

// Java 8
SomeMethod(() -> { /* your implementation */ });

-------------------------------

 

No, but they're fakeable using proxies and reflection:

  public static class TestClass {
      public String knockKnock() {
          return "who's there?";
      }
  }

  private final TestClass testInstance = new TestClass();

  @Test public void
  can_delegate_a_single_method_interface_to_an_instance() throws Exception {
      Delegator<TestClass, Callable<String>> knockKnockDelegator = Delegator.ofMethod("knockKnock")
                                                                   .of(TestClass.class)
                                                                   .to(Callable.class);
      Callable<String> callable = knockKnockDelegator.delegateTo(testInstance);
      assertThat(callable.call(), is("who's there?"));
  }

The nice thing about this idiom is that you can verify that the delegated-to method exists, and has the required signature, at the point where you create the delegator (although not at compile-time, unfortunately, although a FindBugs plug-in might help here), then use it safely to delegate to various instances.

See the karg code on github for more tests and implementation.

 

--------------------------------

 

I have implemented callback/delegate support in Java using reflection. Details and working source are available on my website.

How It Works

There is a principle class named Callback with a nested class named WithParms. The API which needs the callback will take a Callback object as a parameter and, if neccessary, create a Callback.WithParms as a method variable. Since a great many of the applications of this object will be recursive, this works very cleanly.

With performance still a high priority to me, I didn't want to be required to create a throwaway object array to hold the parameters for every invocation - after all in a large data structure there could be thousands of elements, and in a message processing scenario we could end up processing thousands of data structures a second.

In order to be threadsafe the parameter array needs to exist uniquely for each invocation of the API method, and for efficiency the same one should be used for every invocation of the callback; I needed a second object which would be cheap to create in order to bind the callback with a parameter array for invocation. But, in some scenarios, the invoker would already have a the parameter array for other reasons. For these two reasons, the parameter array does not belong in the Callback object. Also the choice of invocation (passing the parameters as an array or as individual objects) belongs in the hands of the API using the callback enabling it to use whichever invocation is best suited to its inner workings.

The WithParms nested class, then, is optional and serves two purposes, it contains the parameter object array needed for the callback invocations, and it provides 10 overloaded invoke() methods (with from 1 to 10 parameters) which load the parameter array and then invoke the callback target.

What follows is an example using a callback to process the files in a directory tree. This is an initial validation pass which just counts the files to process and ensure none exceed a predetermined maximum size. In this case we just create the callback inline with the API invocation. However, we reflect the target method out as a static value so that the reflection is not done every time.

static private final Method             COUNT =Callback.getMethod(Xxx.class,"callback_count",true,File.class,File.class);

...

IoUtil.processDirectory(root,new Callback(this,COUNT),selector);

...

private void callback_count(File dir, File fil) {
    if(fil!=null) {                                                                             // file is null for processing a directory
        fileTotal++;
        if(fil.length()>fileSizeLimit) {
            throw new Abort("Failed","File size exceeds maximum of "+TextUtil.formatNumber(fileSizeLimit)+" bytes: "+fil);
            }
        }
    progress("Counting",dir,fileTotal);
    }

IoUtil.processDirectory():

/**
 * Process a directory using callbacks.  To interrupt, the callback must throw an (unchecked) exception.
 * Subdirectories are processed only if the selector is null or selects the directories, and are done
 * after the files in any given directory.  When the callback is invoked for a directory, the file
 * argument is null;
 * <p>
 * The callback signature is:
 * <pre>    void callback(File dir, File ent);</pre>
 * <p>
 * @return          The number of files processed.
 */
static public int processDirectory(File dir, Callback cbk, FileSelector sel) {
    return _processDirectory(dir,new Callback.WithParms(cbk,2),sel);
    }

static private int _processDirectory(File dir, Callback.WithParms cbk, FileSelector sel) {
    int                                 cnt=0;

    if(!dir.isDirectory()) {
        if(sel==null || sel.accept(dir)) { cbk.invoke(dir.getParent(),dir); cnt++; }
        }
    else {
        cbk.invoke(dir,(Object[])null);

        File[] lst=(sel==null ? dir.listFiles() : dir.listFiles(sel));
        if(lst!=null) {
            for(int xa=0; xa<lst.length; xa++) {
                File ent=lst[xa];
                if(!ent.isDirectory()) {
                    cbk.invoke(dir,ent);
                    lst[xa]=null;
                    cnt++;
                    }
                }
            for(int xa=0; xa<lst.length; xa++) {
                File ent=lst[xa];
                if(ent!=null) { cnt+=_processDirectory(ent,cbk,sel); }
                }
            }
        }
    return cnt;
    }

This example illustrates the beauty of this approach - the application specific logic is abstracted into the callback, and the drudgery of recursively walking a directory tree is tucked nicely away in a completely reusable static utility method. And we don't have to repeatedly pay the price of defining and implementing an interface for every new use. Of course, the argument for an interface is that it is far more explicit about what to implement (it's enforced, not simply documented) - but in practice I have not found it to be a problem to get the callback definition right.

Defining and implementing an interface is not really so bad (unless you're distributing applets, as I am, where avoiding creating extra classes actually matters), but where this really shines is when you have multiple callbacks in a single class. Not only is being forced to push them each into a separate inner class added overhead in the deployed application, but it's downright tedious to program and all that boiler-plate code is really just "noise".

 

-----------------------------------

 

http://www.javacamp.org/javavscsharp/delegate.html

 

Java
 
There is no delegate concept in Java
The right-side C# program may be mimiced 
with reflection technology.
====================================
import java.lang.reflect.*;
import java.io.*;
public class Test
{
    public static void main(String[] args) throws Exception
    {
        String[] list= {"to","be","or","not","to","be"};
        Method m1 = Test.class.getMethod("toConsole", 
                           new Class[] {String.class});
        Display(m1, list);
        Method m2 = Test.class.getMethod("toFile", 
                           new Class[] {String.class});
        Display (m2, list);
    }
    public static void toConsole (String str)
    {
        System.out.print(str+" ");
    }
    public static void toFile (String s)
    {
        File f = new File("delegate.txt");
        try{
            PrintWriter fileOut = 
               new PrintWriter(new FileOutputStream(f));
            fileOut.write(s);
            fileOut.flush();
            fileOut.close();
        }catch(IOException ioe) {}
    }
    public static void display(Method m, String[] list)
    {
        for(int k = 0; k < list.length; k++) {
            try {
                Object[] args = {new String(list[k])};
                m.invoke(null, args);
            }catch(Exception e) {}
        }
    }
}
 

C#
 
Delegates are reference types which allow 
indirect calls to methods. There are single and multicast
delegates.
============================================
 using System;
 using System.IO;
 public class DelegateTest
 {
     public delegate void Print (String s);
     public static void Main()
     {
         Print s = new Print (toConsole);
         Print v = new Print (toFile);
         Display (s);
         Display (v);
     }
     public static void toConsole (String str)
     {
         Console.WriteLine(str);
     }
     public static void toFile (String s)
     {
         File f = new File("delegate.txt");
         StreamWriter fileOut = f.CreateText();
         fileOut.WriteLine(s);
         fileOut.Flush();
         fileOut.Close();
     }
     public static void Display(Print pMethod)
     {
         pMethod("This should be displayed in the console");
     }
 }
 A delegate instance encapsulates one or more methods, 
 each of which is referred to as a callable entity. 
 To add or reduce a list of calls
 by using operators += or -=.
 for example
 Print p = s + v;
 s += v;
 

-------------------------------------------

 

In C# you can define delegates anonymously (even though they are nothing more than syntactic sugar). For example, I can do this:

public string DoSomething(Func<string, string> someDelegate)
{
     // Do something involving someDelegate(string s)
} 

DoSomething(delegate(string s){ return s += "asd"; });
DoSomething(delegate(string s){ return s.Reverse(); });

Is it possible to pass code like this in Java? I'm using the processing framework, which has a quite old version of Java (it doesn't have generics).

 

Pre Java 8:

The closest Java has to delegates are single method interfaces. You could use an anonymous inner class.

interface StringFunc {
   String func(String s);
}

void doSomething(StringFunc funk) {
   System.out.println(funk.func("whatever"));
}

doSomething(new StringFunc() {
      public String func(String s) {
           return s + "asd";
      }
   });


doSomething(new StringFunc() {
      public String func(String s) {
           return new StringBuffer(s).reverse().toString();
      }
   });

Java 8 and above:

Java 8 adds lambda expressions to the language.

    doSomething((t) -> t + "asd");
    doSomething((t) -> new StringBuilder(t).reverse().toString());

---------------------------------------------------

 

Your example would look like this in Java, using anomymous inner classes:

interface Func {
    String execute(String s);
}

public String doSomething(Func someDelegate) {
    // Do something involving someDelegate.execute(String s)
}

doSomething(new Func() { public String execute(String s) { return s + "asd"; } });
doSomething(new Func() { public String execute(String s) { return new StringBuilder(s).reverse().toString(); } } });

 

---------------------------------------------------------

 

 

 

----------------------------------------------------------

 

 

 

----------------------------------------------------------

 

 

---------------------------------------------

 

https://github.com/tim-group/karg/blob/master/src/main/java/com/timgroup/karg/reflection/Delegator.java

https://github.com/tim-group/karg/blob/master/src/test/java/com/timgroup/karg/reflection/DelegatorTest.java

 

------------------------------------------

 

Java Proxy class

http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/Proxy.html

 

-------------------------------------------

 

State of the Lambda

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html

 

-----------------------------------------------

 

 

 

 

저작자 표시 비영리 변경 금지
신고

'개발/활용정보' 카테고리의 다른 글

delegate  (0) 2017.07.07
Oauth  (0) 2013.07.18
UML 기본편  (0) 2011.12.05
ClearCase  (0) 2011.08.11
blotware, crapware  (0) 2011.05.27
구글맵 api 를 이용한 map service  (0) 2011.05.20
Trackback 0 And Comment 0
prev | 1 | 2 | 3 | 4 | 5 | 6 | ··· | 246 | next

티스토리 툴바