ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग की खामियाँ (2009) [pdf]
Object-oriented programming की जाँच एक conceptual model और performance trade-off, दोनों रूपों में की जाती है, और कई लोग तर्क देते हैं कि identity, mutable state, और inheritance पर इसका ज़ोर अक्सर सरल data-oriented या functional designs की तुलना में बिना स्पष्ट लाभ के जटिलता बढ़ाता है। Commenters Alan Kay की मूल message-passing vision of objects की तुलना Java और C++ जैसे mainstream OO के आज के अभ्यास से करते हैं, और cache-unfriendly object graphs, brittle inheritance hierarchies, तथा “everything is an object” सोच के अति-प्रयोग जैसी समस्याएँ उजागर करते हैं। एक recurring theme यह है कि कोई एक paradigm पर्याप्त नहीं होता: प्रभावी systems objects, functions, और relational या set-based models को मिलाकर बनती हैं, और OO का उपयोग वहीं करना चाहिए जहाँ encapsulated state और polymorphic behavior वास्तव में सहायक हों, जैसे UI code के कुछ हिस्सों में।
OO “असल में” क्या है
- कई टिप्पणियाँ Wikipedia की “data + methods together” वाली परिभाषा को भ्रामक बताती हैं।
- एक पक्ष कहता है कि इसका सार identity plus mutable state है: दो objects अलग-अलग fields होने पर भी “एक ही” हो सकते हैं।
- दूसरा पक्ष message sending + dynamic dispatch पर ज़ोर देता है: अलग-अलग objects एक ही message का अलग तरह से जवाब देते हैं; mutability और identity आम हैं, लेकिन अनिवार्य नहीं।
- दोनों दृष्टिकोण इस बात पर सहमत हैं कि memory layout गौण है, परिभाषित करने वाला नहीं।
OO बनाम अन्य paradigms (identity, sets, relations)
- एक बार-बार उभरने वाला विषय: OO “intentional identity” को प्रोत्साहित करता है (आप objects/services गढ़ते हैं और data/behavior को उनमें धकेलते हैं), जिससे system complexity बढ़ सकती है।
- इसके विपरीत, relational/logic approaches “extensional identity” पर ज़ोर देती हैं (entities values/tuples से परिभाषित होती हैं; identity attributes से उभरती है)।
- कुछ लोग ध्यान दिलाते हैं कि कई developers OO में इतने डूबे होते हैं कि उन्हें वही स्वाभाविक लगता है, और फिर relational/functional/logic systems को awkward तरीके से OO abstractions के भीतर लपेटते हैं।
Inheritance, composition, interfaces
- class inheritance को primary design tool मानने की कड़ी आलोचना की गई है; composition, interfaces/traits/typeclasses, और delegation को अक्सर बेहतर माना जाता है।
- कुछ लोग inheritance का बचाव करते हैं, इसे extensibility और UI customization के लिए एक शक्तिशाली, सुविधाजनक mechanism बताते हैं, खासकर जब इसे सावधानी से सीमित रखा जाए (final classes/methods, स्पष्ट extension points)।
- इस पर बहस है कि delegation + generics, inheritance की expressiveness और ergonomics के बराबर हैं या नहीं; सहमति यह है कि inheritance का गलत उपयोग आसानी से fragile designs की ओर ले जाता है।
GUIs बनाम backends में OO
- कई लोगों को traditional GUI toolkits के लिए OO उपयुक्त लगता है (state और behavior वाले widgets, hierarchical structure)।
- आधुनिक UI frameworks (React, Elm, Compose, SwiftUI) declarative/functional या reactive styles की ओर झुकते हैं, हालांकि आलोचक कहते हैं कि इनके नीचे फिर भी hidden, OO-like state काम करती है।
- React hooks पर चर्चा: ऊपर से ये functional लगते हैं, लेकिन pure FP rules तोड़ते हैं और unusual semantics पर निर्भर करते हैं।
Performance और data-oriented design
- slides को इस तरह देखा गया कि OO-centric object graphs, data-oriented layouts (जैसे arrays/vectors) की तुलना में cache locality और prefetching को नुकसान पहुँचाते हैं।
- कुछ लोग इसे व्यापक रूप में देखते हैं: modularity और abstraction अक्सर raw performance से trade off करती हैं; performance-critical code में data-oriented design इसका प्रतिरोध करती है।
Pragmatism और multi-paradigm use
- कई commenters multi-paradigm practice का समर्थन करते हैं: कुछ हिस्सों में OO, और कहीं FP/relational/logic।
- चरम विचार (“everything is an object,” “everything is immutable”) को प्रतिकूल माना जाता है; problem को paradigm तय करना चाहिए।