सभी कंक्रीट विधियों के साथ सार कक्षा

Question

क्या किसी के लिए क्लास अमूर्त घोषित करने के लिए कुछ व्यावहारिक प्रोग्रामिंग स्थितियां हैं जब इसमें सभी विधियां ठोस हैं?

Answer 1

ठीक है आप एक टेम्पलेट विधि पैटर्न का उपयोग कर सकते हैं जहां कई ओवरराइड पॉइंट हैं जिनमें सभी के पास डिफ़ॉल्ट कार्यान्वयन हैं लेकिन जहां स्वयं द्वारा संयुक्त डिफ़ॉल्ट कार्यान्वयन कानूनी नहीं हैं - किसी भी कार्यात्मक कार्यान्वयन को उप-वर्ग होना चाहिए।

(और हाँ, मैं टेम्पलेट विधि पैटर्न नापसंद;))

Answer 2

एक अमूर्त वर्ग एक वर्ग है जिसे सार घोषित किया जाता है - इसमें अमूर्त विधियां शामिल हो सकती हैं या नहीं भी हो सकती हैं। उन्हें तत्काल नहीं किया जा सकता है, इसलिए यदि आपके पास कंक्रीट विधियों के साथ एक अमूर्त वर्ग है तो इसे उप-वर्गीकृत किया जा सकता है और उप-वर्ग को तत्काल चालू किया जा सकता है।

Answer 3

अच्छा सवाल :)

एक बात निश्चित है ... यह निश्चित रूप से संभव है। क्रोसेंवॉल्ड द्वारा टेम्पलेट सुझाव यह करने का एक अच्छा कारण है।

मैं सिर्फ यह कहना चाहता हूं कि किसी वर्ग को इसके तत्कालता को रोकने के लिए abstract घोषित नहीं किया जाना चाहिए।

यह जावा भाषा विशिष्टता Section 8.1.1.1

Answer 4

Immagine एक अंतरफलक जिसका घोषित तरीकों जब लागू किया आमतौर पर एक ही डिफ़ॉल्ट व्यवहार दिखाने में जाना जाता है। एक वर्ग लिखते समय जिसे इंटरफ़ेस का समर्थन करने की आवश्यकता होती है, आपको डिफ़ॉल्ट व्यवहार को परिभाषित करना होता है।

अपने ठोस वर्गों के कार्यान्वयन की सुविधा के लिए आप प्रत्येक विधि के लिए डिफ़ॉल्ट व्यवहार प्रदान करने के लिए एक अमूर्त वर्ग प्रदान करना चाहेंगे। एक ठोस वर्ग में इंटरफ़ेस का समर्थन करने के लिए आप मानक व्यवहार से विचलित होने पर अमूर्त वर्ग और ओवरराइड विधियों से प्राप्त कर सकते हैं। इस तरह आप एक ही (अनावश्यक) डिफ़ॉल्ट व्यवहार के बार-बार कार्यान्वयन से बचेंगे।

Answer 5

आप एक महत्वपूर्ण वर्ग है, लेकिन प्रणाली इस वर्ग के लिए एक उदाहरण नहीं बना सकते, क्योंकि

• इस वर्ग प्रणाली की कक्षाओं का एक बहुत की मूल है जब;
• डोमेन की आवश्यकता के लिए इसमें बहुत सारी उत्तरदायित्व (कई कक्षाओं द्वारा उपयोग की जाने वाली विधियां) हैं;
• यह कक्षा एक ठोस वस्तु का प्रतिनिधित्व नहीं करती है;

Answer 6

एक और संभावित उपयोग केस एक सजावट है जो सभी कॉल को लपेटा हुआ उदाहरण प्रस्तुत करता है। एक ठोस डेकोरेटर कार्यान्वयन केवल उन तरीकों को ओवरराइड कर सकते हैं जहां कार्यक्षमता जोड़ा जाता है:

public interface Foo { 
    public void bar(); 
} 
public abstract class FooDecorator implements Foo { 
    private final Foo wrapped; 
    public FooDecorator(Foo wrapped) { this.wrapped = wrapped; } 
    public void bar() { wrapped.bar(); } 
} 
public class TracingFoo extends FooDecorator { 
    //Omitting constructor code... 
    public void bar() { 
     log("Entering bar()"); 
     super.bar(); 
     log("Exiting bar()"); 
    } 
} 

हालांकि मैं वास्तव में necessarity सार (गैर सार उदाहरण: HttpServletRequestWrapper) के रूप में FooDecorator घोषित करने के लिए नहीं दिख रहा।

Answer 7

पिछला जवाब पहले से ही मुख्य मुद्दों पर आ गया है, लेकिन एक मामूली जानकारी है जो उल्लेखनीय हो सकती है।

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

Answer 8

सोच क्यों कोई भी MouseAdapter के व्यावहारिक उदाहरण की ओर इशारा किया गया है:

http://docs.oracle.com/javase/6/docs/api/java/awt/event/MouseAdapter.html

माउस घटनाओं प्राप्त करने के लिए एक सार एडाप्टर वर्ग। में विधियां इस कक्षा खाली हैं। यह वर्ग श्रोता ऑब्जेक्ट्स बनाने के लिए सुविधा के रूप में मौजूद है।