java - एओपी क्या कर सकता है कि ओओपी नहीं कर सकता है?




oop design (5)

आम तौर पर, फॉर्म के सभी प्रश्न "वह क्या कर सकता है?" अर्थहीन हैं सभी सामान्य प्रयोजन भाषाएं समान रूप से शक्तिशाली हैं (देखें: चर्च की थीसिस )।

इसलिए, भाषाओं के बीच का अंतर यह नहीं है कि वे क्या कर सकते हैं बल्कि यह कैसे करते हैं। दूसरे शब्दों में, आपको एक भाषा में कुछ व्यवहार करने के लिए कितना काम करना है, बनाम। किसी अन्य भाषा में वही व्यवहार करने के लिए कितना काम करना है।

मैं मुख्य रूप से जावा डेवलपर हूं। मैंने कुछ जावा देवों से मुलाकात की है जो एओपी से प्यार करते हैं। मैं हाल ही में उभरते हुए अधिक से अधिक एओपी "डिजाइन पैटर्न" देख रहा हूं जो काफी व्यापक रूप से अपनाया जाता है। फिर भी, मुझे अभी भी विश्वास नहीं है कि कुछ कारणों से ओओ कोड में एओपी सामान्य रूप से एक अच्छा विचार है।

  1. यह अपारदर्शी जटिलता के रूप में कोड में "जादू" जोड़ता है जो डीबग करना बेहद मुश्किल हो सकता है, और यह ऑब्जेक्ट उन्मुख कोड को डीबग करना बेहद मुश्किल बना सकता है जो इसे प्रभावित करता है।

  2. ऐसा लगता है कि मुझे अधिकतर अनावश्यक होना चाहिए, और (बदतर) अक्सर अच्छी तरह से डिजाइन करने से बचने के लिए या पिछले खराब डिजाइन की क्षतिपूर्ति करने के लिए उपयोग किया जाता है।

यहां एक उदाहरण दिया गया है कि पिछले कुछ सालों में मैं अपने प्रश्न के लिए पृष्ठभूमि के रूप में बहुत कुछ देख रहा हूं।

एओपी से पहले (हाइबरनेट डॉक्स से)

public void saveMyEntityToTheDatabase(MyEntity entity) {
    EntityTransaction tx = null;
    try {
        tx = entityManager.getTransaction();
        tx.begin();
        entityManager.persist(entity);
        tx.commit();
    } catch (RuntimeException e) {
        if(tx != null && tx.isActive()) {
            tx.rollback();
        }
        throw e;
    }
}

एओपी के बाद

@Transactional
public void saveMyEntityToTheDatabase(MyEntity entity) {
    entityManager.persist(entity);
}

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

एक ओओ समाधान

public void saveMyEntityToTheDatabase(MyEntity entity) {
    database.performInTransaction(new Save(entity));
}

यह समाधान मानता है कि database ऑब्जेक्ट में एक ही प्रकार का लेनदेन संबंधी तर्क होता है जो उस पहलू को जिम्मेदार @Transactional जो @Transactional विधियों का प्रबंधन करता है। यह मेरी चिंताओं को इस बात से अधिक स्पष्ट करता है कि EntityManager साथ बातचीत का प्रबंधन कुछ और प्रोग्रामिंग प्रतिमान को पेश नहीं करता है।

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


एओपी ओओ है; पहलू वस्तुएं हैं।

मुझे समझ में नहीं आता क्यों या तो मानसिकता।

एओपी जंजीर, क्रॉस-कटिंग चिंताओं (जैसे लॉगिंग, सुरक्षा, लेनदेन, रिमोट प्रॉक्सीइंग इत्यादि) के लिए सही विकल्प है।

अद्यतन करें:

मुझे लगता है कि ओपी द्वारा दी गई आलोचनाएं व्यक्तिपरक हैं और जैसा कि बताया गया है सार्वभौमिक रूप से व्यापक नहीं है। सबूत के बिना कहा गया दावा सबूत के बिना खारिज कर दिया जा सकता है।

मैं जादू का उपयोग करने में विश्वास नहीं करता, लेकिन अगर आप इसे समझते हैं तो एओपी जादू नहीं है। मैं यह समझता हूँ। शायद ओपी नहीं करता है। यदि ऐसा है, और ओपी ओओ समाधान के साथ अधिक आरामदायक है, तो मैं कहूंगा कि इसके लिए जाना है।

"मुझे अनावश्यक होने लगता है" एक मात्र राय है, सबूत के बिना पेशकश की। "मैं असहमत हूं" को छोड़कर इसका कोई जवाब नहीं है।

मुझे लगता है कि एओपी उन मामलों के लिए बिल्कुल सही है क्योंकि मैं इसे घोषणात्मक तरीके से लागू कर सकता हूं। मैं एक पहलू वर्ग को एक बार लिख सकता हूं और इसे कई जगहों पर ठीक-ठीक नियंत्रण के साथ लागू कर सकता हूं, इसे कोड के बजाय कॉन्फ़िगरेशन में बदल रहा हूं। मैं चुन सकता हूं कि कौन सी विधियों, कक्षाओं और संकुलों में कॉन्फ़िगरेशन में उनके लिए एक पहलू लागू होता है।

एक हाथ से लिखित ओओ दृष्टिकोण के साथ कोशिश करें।

इसके अलावा, एओपी ऑब्जेक्ट उन्मुख है। आप इसे एक स्मार्ट व्यक्ति के रूप में देख सकते हैं जो आपको हाथ से करना चाहते हैं के लिए एक डोमेन-विशिष्ट भाषा या ढांचा प्रदान करता है। सामान्य विशेषताओं को कुछ और सामान्य में समझाया गया है। कोई उस पर क्यों ऑब्जेक्ट करेगा?


मेरे लिए अब तक, एकमात्र उपयोग केस, जिसके लिए एओपी निश्चित रूप से ओओपी से बेहतर है विधि कॉल ट्रेसिंग है।


मेरे लिए एओपी इंटरसेप्टर पैटर्न का एक लघुरूप है। और इंटरसेप्टर पैटर्न स्वयं टेम्पलेट विधि , AFAICS से व्युत्पन्न (या प्रभावित या प्राप्त किया गया) है।

Interceptor का एक लोकप्रिय उदाहरण Servlet Filter । और हम जानते हैं कि कई मामलों में वे बहुत उपयोगी हैं।

चूंकि, ये सभी पैटर्न उपयोगी हैं, इसलिए एओपी, जो इनसे व्युत्पन्न है, भी उपयोगी है। और जैसा कि आपने स्वयं अपने कुछ उपयोगों को बताया है।






aop