कार्यात्मक इंटरफेस के रूप में सार वर्ग

Question

जावा 8 में, केवल एक सार विधि वाला एक सार वर्ग एक कार्यात्मक इंटरफ़ेस नहीं है (JSR 335)।

यह interface एक कार्यात्मक इंटरफ़ेस है:

public interface MyFunctionalInterface { 
    public abstract void myAbstractMethod(); 
    public default void method() { 
     myAbstractMethod(); 
    } 
} 

लेकिन इस abstract class नहीं है:

public abstract class MyFunctionalAbstractClass { 
    public abstract void myAbstractMethod(); 
    public void method() { 
     myAbstractMethod(); 
    } 
} 

तो मैं एक लैम्ब्डा अभिव्यक्ति और विधि संदर्भ के लिए एक लक्ष्य के रूप सार वर्ग उपयोग नहीं कर सकते ।

public class Lambdas { 
    public static void main(String[] args) { 
     MyFunctionalAbstractClass functionalAbstractClass =() -> {}; 
    } 
} 

संकलन त्रुटि है: The target type of this expression must be a functional interface।

भाषा डिजाइनरों ने इस प्रतिबंध को क्यों लगाया?

Answer 1

यह लैम्ब्डा प्रोजेक्ट की शुरुआत के बाद से एक महत्वपूर्ण विषय रहा है और बहुत सारे विचार प्राप्त हुए हैं। मुख्य जावा भाषा वास्तुकार ब्रायन गोएट्ज, फ़ंक्शन के रूप में लैम्ब्डा के दृश्य का दृढ़ समर्थन करता है, ऑब्जेक्ट नहीं। उद्धरण:

यह मेरा विश्वास है कि जावा विकसित करने के लिए सबसे अच्छी दिशा प्रोग्रामिंग की एक और कार्यात्मक शैली को प्रोत्साहित करती है। लैम्ब्डा की भूमिका मुख्य रूप से विकास और अधिक कार्यात्मक की तरह पुस्तकालयों

मैं जावा के भविष्य के बारे में आशावादी हूँ की खपत का समर्थन करने के लिए, लेकिन आगे बढ़ने के लिए कभी-कभी हम कुछ आरामदायक विचारों जाने के लिए है है। Lambdas-Are-functions दरवाजे खुलता है। Lambdas- वस्तुओं को बंद कर देता है। हम उन दरवाजों को देखना पसंद करते हैं खुला छोड़ दिया।

बनाना मॉडल सरल करने के लिए दरवाजे खोलता है:

Here बोली के स्रोत और here के लिए एक लिंक ब्रायन की और अधिक हाल के पोस्ट जो एक ही phylosophical अंक दोहराती है और उन्हें अतिरिक्त, और अधिक व्यावहारिक तर्क के साथ की पुष्टि करता है है वीएम अनुकूलन के सभी प्रकार। (जेटीसनिंग पहचान यहां महत्वपूर्ण है।) कार्य मान हैं। वस्तुओं के रूप में उन्हें मॉडलिंग करने से उन्हें भारी, और अधिक जटिल, होने की आवश्यकता होती है।

बस के तहत इस उपयोग के मामले को फेंकने से पहले, हमने कुछ कॉर्पस विश्लेषण किया ताकि यह पाया जा सके कि इंटरफ़ेस एसएएम की तुलना में कितनी बार सार वर्ग एसएएम का उपयोग किया जाता है। हमने पाया कि उस कॉर्पस में, लैम्ब्डा उम्मीदवार के केवल 3% आंतरिक वर्ग के उदाहरणों में उनके लक्ष्य के रूप में अमूर्त वर्ग थे। और उनमें से अधिकांश सरल रिफैक्टरिंग के लिए सक्षम थे जहां आपने कन्स्ट्रक्टर/फैक्ट्री जोड़ा जो इंटरफ़ेस-लक्षित था जो लैम्ब्डा स्वीकार करता था।