गैर-ऊ में यह कैसे प्रोग्राम किया जाएगा? [बन्द है]

Question

कुछ अन्य प्रतिमानों के पक्ष में OOP के डाउनसाइड्स पर एक स्केथिंग लेख के माध्यम से पढ़ना मैंने एक उदाहरण में चलाया है जिसमें मुझे बहुत अधिक गलती नहीं मिल सकती है।

मैं लेखक के तर्कों के लिए खुला रहना चाहता हूं, और यद्यपि मैं सैद्धांतिक रूप से उनकी बातों को समझ सकता हूं, विशेष रूप से एक उदाहरण मैं यह कल्पना करने की कोशिश कर रहा हूं कि यह कैसे बेहतर होगा, यह कहना है, एक एफपी भाषा।

से: http://www.smashcompany.com/technology/object-oriented-programming-is-an- सस्ती-disaster-which-must-end

// Consider the case where “SimpleProductManager” is a child of
// “ProductManager”:

public class SimpleProductManager implements ProductManager {
    private List products;

    public List getProducts() {
        return products;
    }

    public void increasePrice(int percentage) {
        if (products != null) {
            for (Product product : products) {
                double newPrice = product.getPrice().doubleValue() *
                (100 + percentage)/100;
                product.setPrice(newPrice);
            }
        }
    }

    public void setProducts(List products) {
        this.products = products;
    }
}

// There are 3 behaviors here:

getProducts()

increasePrice()

setProducts()

// Is there any rational reason why these 3 behaviors should be linked to
// the fact that in my data hierarchy I want “SimpleProductManager” to be
// a child of “ProductManager”? I can not think of any. I do not want the
// behavior of my code linked together with my definition of my data-type
// hierarchy, and yet in OOP I have no choice: all methods must go inside
// of a class, and the class declaration is also where I declare my
// data-type hierarchy:

public class SimpleProductManager implements ProductManager

// This is a disaster.

ध्यान दें कि मैं लेखक के तर्कों के खिलाफ या "क्या कोई तर्कसंगत कारण है कि इन 3 व्यवहारों को डेटा पदानुक्रम से जुड़ा होना चाहिए?" के लिए एक खंडन की तलाश नहीं है।

मैं विशेष रूप से पूछ रहा हूं कि यह उदाहरण कैसे एफपी भाषा में मॉडलिंग / प्रोग्राम किया जाएगा (वास्तविक कोड, सैद्धांतिक रूप से नहीं)?

Comments

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

— व्यंग्यात्मक

OO प्रोग्रामिंग के बारे में कुछ भी नहीं है जो यह बताता है कि उन 3 विधियों को एक ही कक्षा में एक साथ जाना चाहिए; इसी तरह OO प्रोग्रामिंग के बारे में कुछ भी नहीं है जो यह बताता है कि व्यवहार डेटा के रूप में उसी कक्षा में मौजूद होना चाहिए। यह कहना है, OO प्रोग्रामिंग के साथ आप डेटा को व्यवहार के समान वर्ग में रख सकते हैं, या आप इसे एक अलग इकाई / मॉडल में विभाजित कर सकते हैं। किसी भी तरह, कुछ भी नहीं OO वास्तव में के बारे में कैसे डेटा, एक वस्तु से संबंधित होना चाहिए के बाद से एक की अवधारणा में क्या कहना है वस्तु मौलिक मॉडलिंग के साथ संबंध है व्यवहार किसी कक्षा के तार्किक-संबंधी तरीकों समूहीकरण।

— बेन कॉटरेल

मुझे एक लेख के उस वाक्य में 10 वाक्य मिले और हार मान ली। उस पर्दे के पीछे आदमी पर कोई ध्यान न दें। अन्य समाचारों में, मुझे नहीं पता था कि ट्रू स्कॉट्समैन मुख्य रूप से ओओपी प्रोग्रामर थे।

— रॉबर्ट हार्वे

फिर भी किसी अन्य व्यक्ति से एक ओओटी भाषा में प्रक्रियात्मक कोड लिखता है, तो आश्चर्य होता है कि ओओ उसके लिए काम क्यों नहीं कर रहा है।

— TheCatWhisperer

हालांकि यह निस्संदेह सच है कि ओओपी शुरू से अंत तक डिजाइन मिसस्टेप्स की एक आपदा है - और मुझे इसका हिस्सा बनने पर गर्व है! - यह लेख अपठनीय है, और आप जो उदाहरण देते हैं, वह मूल रूप से यह तर्क देता है कि एक खराब श्रेणी के पदानुक्रम को खराब तरीके से डिज़ाइन किया गया है।

— एरिक लिपर्ट

Answer 1

एफपी शैली में, Productएक अपरिवर्तनीय वर्ग product.setPriceहोगा , एक Productवस्तु को उत्परिवर्तित नहीं करेगा , बल्कि एक नई वस्तु लौटाएगा, और increasePriceफ़ंक्शन एक "स्टैंडअलोन" फ़ंक्शन होगा। आपके जैसे समान दिखने वाले सिंटैक्स (C # / Java जैसे) का उपयोग करके, एक समान फ़ंक्शन इस तरह दिख सकता है:

 public List increasePrice(List products, int percentage) {
    if (products != null) {
        return products.Select(product => {
                double newPrice = product.getPrice().doubleValue() *
                    (100 + percentage)/100;
                return product.setPrice(newPrice);     
               });
    }
    else return null;
}

जैसा कि आप देखते हैं, कोर वास्तव में यहां अलग नहीं है, सिवाय इसके कि OOP के उदाहरण से "बॉयलरप्लेट" कोड को छोड़ दिया गया है। हालाँकि, मैं इसे सबूत के रूप में नहीं देखता कि OOP फूला हुआ कोड है, केवल इस तथ्य के लिए सबूत के रूप में अगर कोई एक कोड उदाहरण का निर्माण करता है जो पर्याप्त रूप से कृत्रिम है, तो कुछ भी साबित करना संभव है।

Comments

इसे "अधिक एफपी" बनाने के तरीके: 1) आंशिक कार्यों के बजाय कुल कार्यों को लिखना आसान बनाने के लिए अशक्तता के बजाय शायद / वैकल्पिक प्रकारों का उपयोग करें और "अगर (x! Null)" को दूर करने के लिए उच्च-क्रम सहायक कार्यों का उपयोग करें। तर्क। 2) उत्पाद की कीमत पर लेंस के संदर्भ में प्रतिशत वृद्धि को लागू करने के संदर्भ में एकल उत्पाद के लिए बढ़ती कीमत को परिभाषित करने के लिए लेंस का उपयोग करें। 3) मानचित्र / चयन कॉल के लिए एक स्पष्ट लंबोदर से बचने के लिए आंशिक अनुप्रयोग / रचना / करी का उपयोग करें।

— जैक

होगा कहना है कि मैं एक संग्रह के विचार से नफरत है बस डिजाइन द्वारा खाली के बजाय अशक्त हो सकता है। देशी टपल / संग्रह समर्थन के साथ कार्यात्मक भाषाएं इस तरह से काम करती हैं। ओओपी में भी मुझे वापसी से नफरत है nullजहां एक संग्रह वापसी प्रकार है। / रेंट ओवर

— बेरिन लोरिट्सच

लेकिन यह ओओपी भाषाओं जैसे जावा या सी # में एक उपयोगिता वर्ग की तरह एक स्थिर विधि हो सकती है। यह कोड आंशिक रूप से छोटा है क्योंकि आप सूची में पास होने के लिए कहते हैं और इसे स्वयं नहीं पकड़ते हैं। मूल कोड एक डेटा संरचना भी रखता है और बस इसे बाहर ले जाने से मूल कोड अवधारणाओं में बदलाव के बिना कम हो जाएगा।

— मार्क

@ मर्क: यकीन है, और मुझे लगता है कि ओपी यह पहले से ही जानता है। मैं इस सवाल को "एक कार्यात्मक तरीके से व्यक्त करने का तरीका" समझता हूं, गैर-ओओपी भाषा में अनिवार्य नहीं है।

— डॉक ब्राउन

@ मर्क FP और OO प्रत्येक को बाहर नहीं करते हैं।

— पीटर बी

Answer 2

मैं विशेष रूप से पूछ रहा हूं कि यह उदाहरण कैसे एफपी भाषा में मॉडलिंग / प्रोग्राम किया जाएगा (वास्तविक कोड, सैद्धांतिक रूप से नहीं)?

"ए" एफपी भाषा में? अगर किसी को दिक्कत होती है, तो मैं Emacs लिस्प को चुनता हूं। इसमें टाइप्स (तरह तरह के) की अवधारणा है, लेकिन केवल अंतर्निहित हैं। इसलिए आपका उदाहरण "आप किसी सूची में प्रत्येक आइटम को किसी चीज़ से कैसे गुणा करते हैं और एक नई सूची वापस करते हैं" को कम करता है।

(mapcar (lambda (x) (* x 2)) '(1 2 3))

तुम वहाँ जाओ। अन्य भाषाएं समान होंगी, इस अंतर के साथ कि आपको सामान्य कार्यात्मक "मिलान" शब्दार्थ के साथ स्पष्ट प्रकार का लाभ मिलता है। हास्केल देखें:

incPrice :: (Num) -> [Num] -> [Num]  
incPrice _ [] = []  
incPrice percentage (x:xs) = x*percentage : incPrice percentage xs  

(या ऐसा ही कुछ, यह युग रहा है ...)

मैं लेखक के तर्कों के प्रति खुला रहना चाहता हूं,

क्यों? मैंने लेख पढ़ने की कोशिश की; मुझे एक पृष्ठ के बाद हार माननी पड़ी और बस जल्दी से बाकी को स्कैन किया।

लेख की समस्या यह नहीं है कि यह ओओपी के खिलाफ है। न ही मैं आँख बंद करके "प्रो ओओपी" हूं। मैंने तर्क, कार्यात्मक और ओओपी प्रतिमानों के साथ प्रोग्राम किया है, जब संभव हो तो एक ही भाषा में, और अक्सर तीनों में से किसी के बिना, विशुद्ध रूप से अनिवार्य या कोडांतरक स्तर पर भी। मैं यह कभी नहीं कहूंगा कि उनमें से कोई भी प्रतिमान हर सूरत में दूसरे के लिए बहुत बड़ा है। क्या मैं यह तर्क दूंगा कि मुझे भाषा X अच्छी लगती है तो Y? हाँ बिल्कुल! लेकिन उस लेख के बारे में ऐसा नहीं है।

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

दिन के अंत में उन सभी चीजों को काम पाने के लिए सिर्फ उपकरण हैं। ऐसी नौकरियां हो सकती हैं जहां ओओपी बेहतर है, और अन्य नौकरियां भी हो सकती हैं जहां एफपी बेहतर है, या जहां दोनों ओवरकिल हैं। महत्वपूर्ण बात यह है कि काम के लिए सही उपकरण चुनना है, और इसे पूरा करना है।

Comments

"यह स्पष्ट रूप से स्पष्ट है कि चर्चा में उनकी रुचि शून्य है, वह धर्मयुद्ध में हैं" इस मणि के लिए एक उत्थान है।

— व्यंग्यात्मक

क्या आपको अपने हास्केल कोड पर एक संख्या अवरोध की आवश्यकता नहीं है? आप (*) को कैसे कॉल कर सकते हैं?

— जे.के.

@ जेक।, यह युग रहा है कि मैंने हास्केल किया था, वह सिर्फ ओपी की बाधा को संतुष्ट करने के लिए था जिस उत्तर की वह तलाश कर रहा था। ;) अगर कोई मेरे कोड को ठीक करना चाहता है, तो स्वतंत्र महसूस करें। लेकिन यकीन है, मैं इसे Num पर स्विच करूँगा।

— एओई

Answer 3

लेखक ने एक बहुत अच्छा बिंदु बनाया, फिर इसे वापस लेने का प्रयास करने के लिए एक शानदार उदाहरण चुना। शिकायत कक्षा के कार्यान्वयन के साथ नहीं है, यह इस विचार के साथ है कि डेटा पदानुक्रम समारोह के पदानुक्रम के साथ संयुक्त रूप से युग्मित है।

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

उत्पादों और मूल्य निर्धारण में शामिल संभावित डेटा प्रकारों के बारे में सोचें। कुछ मंथन करने के लिए: नाम, upc कोड, श्रेणी, शिपिंग वजन, मूल्य, मुद्रा, डिस्काउंट कोड, छूट नियम।

यह ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का आसान हिस्सा है। हम उपरोक्त सभी "ऑब्जेक्ट्स" के लिए सिर्फ एक क्लास बनाते हैं और हम अच्छे हैं, है ना? Productउनमें से कुछ को एक साथ संयोजित करने के लिए एक वर्ग बनाएं ?

लेकिन रुकिए, आपके पास उन कुछ प्रकारों के संग्रह और समुच्चय हो सकते हैं: सेट [श्रेणी], (डिस्काउंट कोड -> मूल्य), (मात्रा -> छूट राशि), और इसके आगे। वो कहां फिट होते हैं? क्या हम CategoryManagerसभी अलग-अलग प्रकार की श्रेणियों पर नज़र रखने के लिए एक अलग बनाते हैं , या क्या यह जिम्मेदारी उस Categoryवर्ग की है जो हमने पहले ही बनाई थी?

अब उन फ़ंक्शंस के बारे में क्या है जो आपको दो अलग-अलग श्रेणियों से निश्चित मात्रा में आइटम होने पर कीमत में छूट देते हैं? क्या वह Productक्लास, Categoryक्लास, DiscountRuleक्लास, CategoryManagerक्लास में जाता है या हमें कुछ नया चाहिए? इस तरह हम चीजों को समाप्त करते हैं DiscountRuleProductCategoryFactoryBuilder।

कार्यात्मक कोड में, आपका डेटा पदानुक्रम आपके कार्यों के लिए पूरी तरह से रूढ़िवादी है। आप अपने कार्यों को जिस भी तरीके से शब्दार्थ समझ सकते हैं, कर सकते हैं। उदाहरण के लिए, आप उन सभी कार्यों को समूहीकृत कर सकते हैं जो उत्पादों की कीमतों को एक साथ बदल देते हैं, इस स्थिति में यह mapPricesनिम्न स्कैला उदाहरण की तरह सामान्य कार्यक्षमता को प्रभावित करता है:

def mapPrices(f: Int => Int)(products: Traversable[Product]): Traversable[Product] =
  products map {x => x.copy(price = f(x.price))}

def increasePrice(percentage: Int)(price: Int): Int =
  price * (percentage + 100) / 100

mapPrices(increasePrice(25))(products)

मैं शायद अन्य मूल्य-संबंधित कार्यों को यहां जोड़ सकता हूं decreasePrice, जैसे applyBulkDiscount, आदि।

क्योंकि हम भी एक संग्रह का उपयोग करते हैं Products, OOP संस्करण को उस संग्रह को प्रबंधित करने के तरीकों को शामिल करने की आवश्यकता है, लेकिन आप इस मॉड्यूल को उत्पाद चयन के बारे में नहीं चाहते थे, आप चाहते थे कि यह कीमतों के बारे में हो। फ़ंक्शन-डेटा युग्मन ने आपको संग्रह प्रबंधन बॉयलरप्लेट को वहां भी फेंकने के लिए मजबूर किया।

आप productsसदस्य को एक अलग वर्ग में रखकर इसे हल करने का प्रयास कर सकते हैं , लेकिन फिर आप बहुत ही कसकर-युग्मित कक्षाओं के साथ समाप्त होते हैं। OO प्रोग्रामर फंक्शन-डेटा कपलिंग को बहुत स्वाभाविक और फायदेमंद मानते हैं, लेकिन लचीलेपन के नुकसान में इससे जुड़ी एक उच्च लागत है। जब भी आप कोई फ़ंक्शन बनाते हैं, तो आपको इसे केवल एक और केवल एक वर्ग को निर्दिष्ट करना होगा। जब भी आप किसी फ़ंक्शन का उपयोग करना चाहते हैं, तो आपको इसके युग्मित डेटा को उपयोग के बिंदु तक लाने का एक तरीका खोजना होगा। वे प्रतिबंध बहुत बड़े हैं।

Answer 4

बस डेटा और फ़ंक्शन को अलग करना क्योंकि लेखक एफ # ("एफपी भाषा") में इस तरह दिख सकता था।

module Product =

    type Product = {
        Price : decimal
        ... // other properties not mentioned
    }

    let increasePrice ( percentage : int ) ( product : Product ) : Product =
        let newPrice = ... // calculate

        { product with Price = newPrice }

आप इस तरह से उत्पादों की सूची पर मूल्य वृद्धि कर सकते हैं।

let percentage = 10
let products : Product list = ...  // load?

products
|> List.map (Product.increasePrice percentage)

नोट: यदि आप FP से परिचित नहीं हैं, तो प्रत्येक फ़ंक्शन एक मान देता है। सी-लाइक लैंग्वेज से आने पर, आप एक स्टेटमेंट में आखिरी स्टेटमेंट को मान सकते हैं, जैसे कि यह उसके returnसामने था ।

मैंने कुछ प्रकार के एनोटेशन शामिल किए, लेकिन उन्हें अनावश्यक होना चाहिए। मॉड्यूल के डेटा के न होने से यहां गेटटर / सेटर अनावश्यक हैं। यह डेटा की संरचना और उपलब्ध संचालन का मालिक है। यह साथ Listही देखा जा सकता है , जो mapसूची में प्रत्येक तत्व पर एक फ़ंक्शन को चलाने के लिए उजागर करता है, और परिणाम को एक नई सूची में वापस करता है।

ध्यान दें कि उत्पाद मॉड्यूल को लूपिंग के बारे में कुछ भी जानना नहीं है, क्योंकि यह जिम्मेदारी सूची मॉड्यूल (जिन्होंने लूपिंग की आवश्यकता पैदा की है) के साथ रहती है।

Answer 5

मुझे इस तथ्य के साथ प्रस्तावना दें कि मैं कार्यात्मक प्रोग्रामिंग का विशेषज्ञ नहीं हूं। मैं एक OOP व्यक्ति हूं। इसलिए जब मुझे पूरा यकीन है कि नीचे यह है कि आप एफपी के साथ एक ही तरह की कार्यक्षमता कैसे पूरा करेंगे, तो मैं गलत हो सकता हूं।

यह टाइपस्क्रिप्ट (इसलिए सभी प्रकार के एनोटेशन) में है। टाइपस्क्रिप्ट (जैसे जावास्क्रिप्ट) एक बहु-डोमेन भाषा है।

export class Product extends Object {
    name: string;
    price: number;
    category: string;
}

products: Product[] = [
    new Product( { name: "Tablet", "price": 20.99, category: 'Electronics' } ),
    new Product( { name: "Phone", "price": 500.00, category: 'Electronics' } ),
    new Product( { name: "Car", "price": 13500.00, category: 'Auto' } )
];

// find all electronics and double their price
let newProducts = products
    .filter( ( product: Product ) => product.category === 'Electronics' )
    .map( ( product: Product ) => {
        product.price *= 2;
        return product;
    } );

console.log( newProducts );

विस्तार से (और फिर से, एक एफपी विशेषज्ञ नहीं), समझने की बात यह है कि बहुत पहले से परिभाषित व्यवहार नहीं है। एक "वृद्धि मूल्य" विधि नहीं है जो पूरी सूची में एक मूल्य वृद्धि लागू करती है, क्योंकि निश्चित रूप से यह OOP नहीं है: इस तरह के व्यवहार को परिभाषित करने के लिए कोई वर्ग नहीं है। उत्पादों की सूची संग्रहीत करने वाली एक वस्तु बनाने के बजाय, आप सिर्फ उत्पादों की एक सरणी बनाते हैं। फिर आप इस सरणी में हेरफेर करने के लिए मानक एफपी प्रक्रियाओं का उपयोग कर सकते हैं जो भी आप चाहते हैं: विशेष आइटम का चयन करने के लिए फ़िल्टर, आंतरिक को समायोजित करने के लिए मानचित्र, आदि ... आप उत्पादों की अपनी सूची पर अधिक विस्तृत नियंत्रण के साथ समाप्त होते हैं बिना सीमित किए बिना। API जो कि SimpleProductManager आपको देता है। इसे कुछ लोगों द्वारा एक फायदा माना जा सकता है। यह भी सच है कि आप डॉन ' टी को ProductManager वर्ग के साथ जुड़े किसी भी सामान के बारे में चिंता करनी होगी। अंत में, "सेटप्रोडक्ट्स" या "गेटप्रोडक्ट्स" के बारे में कोई चिंता नहीं है, क्योंकि कोई भी वस्तु नहीं है जो आपके उत्पादों को छिपा रही है: इसके बजाय, आपके पास केवल उन उत्पादों की सूची है जिनके साथ आप काम कर रहे हैं। फिर, यह उन परिस्थितियों / व्यक्ति के आधार पर एक फायदा या नुकसान हो सकता है, जिनसे आप बात कर रहे हैं। इसके अलावा, स्पष्ट रूप से कोई वर्ग पदानुक्रम नहीं है (जो वह शिकायत कर रहा था) क्योंकि पहली जगह में कोई कक्षाएं नहीं हैं। यह उन परिस्थितियों / व्यक्ति के आधार पर एक फायदा या नुकसान हो सकता है जिनसे आप बात कर रहे हैं। इसके अलावा, स्पष्ट रूप से कोई वर्ग पदानुक्रम नहीं है (जो वह शिकायत कर रहा था) क्योंकि पहली जगह में कोई कक्षाएं नहीं हैं। यह उन परिस्थितियों / व्यक्ति के आधार पर एक फायदा या नुकसान हो सकता है जिनसे आप बात कर रहे हैं। इसके अलावा, स्पष्ट रूप से कोई वर्ग पदानुक्रम नहीं है (जो वह शिकायत कर रहा था) क्योंकि पहली जगह में कोई कक्षाएं नहीं हैं।

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

व्यक्तिगत रूप से मेरे पास किसी को भी गंभीरता से लेने का कठिन समय है जो "एक्स सिर्फ भयानक है। हमेशा वाई का उपयोग करें" के लिए ऐसा मजबूत तर्क देता है। प्रोग्रामिंग में विभिन्न प्रकार के उपकरण और प्रतिमान हैं क्योंकि हल करने के लिए विभिन्न प्रकार की समस्याएं हैं। एफपी की अपनी जगह है, ओओपी की अपनी जगह है, और कोई भी एक शानदार प्रोग्रामर बनने वाला नहीं है, अगर वे हमारे सभी टूल्स की कमियों और फायदों को समझ नहीं सकते हैं और उन्हें कब इस्तेमाल करना है।

** नोट: जाहिर है मेरे उदाहरण में एक वर्ग है: उत्पाद वर्ग। इस मामले में हालांकि यह केवल एक गूंगा डेटा कंटेनर है: मुझे नहीं लगता कि इसका मेरा उपयोग एफपी के सिद्धांतों का उल्लंघन करता है। यह अधिक प्रकार की जाँच के लिए सहायक है।

** ध्यान दें: मुझे अपने सिर के ऊपर से याद नहीं है और यह नहीं जांचा कि क्या मैंने मैप फ़ंक्शन का उपयोग किया है, जिससे उत्पादों को जगह में संशोधित किया जाएगा, यानी मैंने अनजाने में मूल उत्पादों में उत्पादों की कीमत दोगुनी कर दी है सरणी। यह स्पष्ट रूप से एफपी से बचने की कोशिश करता है कि साइड इफेक्ट की तरह है, और थोड़ा और कोड के साथ मैं निश्चित रूप से यह सुनिश्चित कर सकता है कि ऐसा नहीं होता है।

Comments

यह वास्तव में एक OOP उदाहरण नहीं है, शास्त्रीय अर्थ में। सही OOP में, डेटा को व्यवहार के साथ जोड़ा जाएगा; यहां, आप दोनों को अलग कर चुके हैं। जरूरी नहीं कि यह बुरी चीज हो (मुझे वास्तव में यह क्लीनर लगता है), लेकिन यह वह नहीं है जिसे मैं शास्त्रीय ओओपी कहूंगा।

— रॉबर्ट हार्वे

Answer 6

यह मुझे नहीं लगता है कि SimpleProductManager किसी चीज़ का बच्चा (फैली हुई या विरासत) है।

ProductManager इंटरफ़ेस का इसका कार्यान्वयन जो मूल रूप से एक अनुबंध है जो यह बताता है कि ऑब्जेक्ट को किन क्रियाओं (व्यवहारों) को करना है।

यदि यह एक बच्चा होगा (या बेहतर कहा जाए तो iherited class या क्लास एक और क्लास फंक्शनलिटी का विस्तार करता है) इसे इस प्रकार लिखा जाएगा:

class SimpleProductManager extends ProductManager {
    ...
}

तो मूल रूप से, लेखक कहते हैं:

मट्ठा में कुछ वस्तु होती है जो व्यवहार है: setProducts, increasePrice, getProducts। और हमें परवाह नहीं है कि वस्तु का एक और व्यवहार भी है या व्यवहार कैसे लागू किया गया है।

SimpleProductManager वर्ग इसे लागू करता है। असल में, यह क्रियाओं को अंजाम देता है।

इसे PercentagePriceIncreaser भी कहा जा सकता है क्योंकि इसका मुख्य व्यवहार कुछ प्रतिशत मूल्य से कीमत बढ़ाना है।

लेकिन हम एक अन्य वर्ग भी लागू कर सकते हैं: ValuePriceIncreaser जो व्यवहार होगा:

public void increasePrice(int number) {
    if (products != null) {
        for (Product product : products) {
            double newPrice = product.getPrice() + number;
            product.setPrice(newPrice);
        }
    }
}

बाहरी दृष्टिकोण से, कुछ भी नहीं बदला है, इंटरफ़ेस समान है, अभी भी एक ही तीन तरीके हैं लेकिन व्यवहार अलग है।

चूंकि एफपी में इंटरफेस जैसी कोई चीज नहीं है इसलिए इसे लागू करना कठिन होगा। सी में, उदाहरण के लिए, हम कार्यों को इंगित कर सकते हैं और हमारी आवश्यकताओं के आधार पर उपयुक्त कॉल कर सकते हैं। अंत में, ओओपी में यह बहुत ही समान तरीके से काम करता है, लेकिन संकलक द्वारा इसका "स्वचालित"।