এটি কীভাবে অ-ও-তে প্রোগ্রাম করা হবে? [বন্ধ]


11

অন্য কিছু দৃষ্টান্তের পক্ষে ওওপির ডাউনসাইডগুলির পক্ষে একটি নিদারুণ নিবন্ধটি পড়ে আমি এমন একটি উদাহরণ পেয়েছি যা আমি খুব বেশি দোষ খুঁজে পাচ্ছি না।

আমি লেখকের যুক্তিগুলির জন্য উন্মুক্ত হতে চাই, এবং যদিও আমি তাদের বিষয়গুলি তাত্ত্বিকভাবে বুঝতে পারি, বিশেষত একটি উদাহরণ আমি এফপি ভাষায় এটি কীভাবে আরও ভালভাবে প্রয়োগ করা যায় তা কল্পনা করার চেষ্টা করতে খুব কষ্ট পাচ্ছি।

থেকে: http://www.smashcompany.com/technology/object-oriented-programming-is-an-expense-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 টি আচরণকে ডেটা স্তরক্রমের সাথে যুক্ত করার কোনও যুক্তিসঙ্গত কারণ আছে কি?" এই লেখকের যুক্তির পক্ষে বা বিপক্ষে আমি খোঁজ করছি না। "

আমি বিশেষত যা জিজ্ঞাসা করছি তা হল এই উদাহরণটি কীভাবে কোনও এফপি ভাষায় মডেলিং / প্রোগ্রামিং করা হবে (প্রকৃত কোড, তাত্ত্বিকভাবে নয়)?


44
আপনি যেমন সংক্ষিপ্ত এবং স্বীকৃত উদাহরণগুলির সাথে কোনও প্রোগ্রামিং দৃষ্টান্ত তুলনা করার পক্ষে যুক্তিযুক্তভাবে আশা করতে পারবেন না। এখানে যে কেউ কোড প্রয়োজনীয়তা নিয়ে আসতে পারেন যা তাদের নিজস্ব পছন্দসই দৃষ্টান্ত বিশ্রামের চেয়ে আরও ভাল দেখায়, বিশেষত যদি তারা অন্যায়ভাবে প্রয়োগ করে। যখন আপনার বাস্তব, বড়, পরিবর্তিত প্রকল্প হয় কেবল তখনই আপনি বিভিন্ন দৃষ্টান্তগুলির শক্তি এবং দুর্বলতাগুলির অন্তর্দৃষ্টি অর্জন করতে পারেন।
ইউফোরিক

20
ওও প্রোগ্রামিং সম্পর্কে কিছুই নেই যা আদেশ দেয় যে 3 টি পদ্ধতি একই ক্লাসে একসাথে যেতে হবে; একইভাবে ওও প্রোগ্রামিং সম্পর্কে কিছুই নেই যা আদেশ দেয় যে আচরণের একই শ্রেণীর ডেটা হিসাবে উপস্থিত থাকা উচিত। এর অর্থ, ওও প্রোগ্রামিংয়ের সাহায্যে আপনি আচরণ হিসাবে একই শ্রেণিতে ডেটা রাখতে পারেন, বা আপনি এটি আলাদা আলাদা সত্তা / মডেলে ভাগ করতে পারেন। উভয় উপায়েই, ওওর কোনও তথ্য কীভাবে কোনও বিষয়ের সাথে সম্পর্কিত হওয়া উচিত সে সম্পর্কে সত্যই বলার কিছুই নেই, যেহেতু কোনও বস্তুর ধারণাটি মৌলিকভাবে মডেলিং আচরণের সাথে ক্লাসে যুক্তিযুক্ত-সম্পর্কিত পদ্ধতিগুলিকে গ্রুপিং করে সম্পর্কিত।
বেন কটরেল

20
আমি একটি নিবন্ধের ছদ্মবেশে 10 টি বাক্য পেয়েছি এবং ছেড়ে দিয়েছি। সেই পর্দার পিছনে লোকটির দিকে মনোযোগ দিন না। অন্যান্য খবরে, আমার কোনও ধারণা ছিল না যে ট্রু স্কটসম্যানরা মূলত ওওপি প্রোগ্রামার ছিল।
রবার্ট হার্ভে

11
যে কেউ ওও ভাষায় প্রসেসরাল কোড লেখেন এমন কারও কাছ থেকে পাওয়া অন্য মন্তব্য, তাহলে কেন ওও তার পক্ষে কাজ করছে না তা অবাক করে দেয়।
দ্যাটিক্যাটহিস্পেরার 21

11
যদিও এটি নিঃসন্দেহে সত্য যে ওওপি হ'ল ডিজাইন মিসটপের একটি বিপর্যয় শুরু থেকে শেষ পর্যন্ত - এবং আমি এর একটি অংশ হতে পেরে আমি গর্বিত! - এই নিবন্ধটি অপঠনযোগ্য এবং আপনি যে উদাহরণটি দিয়েছেন তা মূলত যুক্তি তৈরি করছে যে একটি খারাপভাবে ডিজাইন করা শ্রেণি শ্রেণিবিন্যাসটি খারাপভাবে ডিজাইন করা হয়েছে।
এরিক লিপার্ট

উত্তর:


42

এফপি শৈলীতে, Productএকটি অপরিবর্তনীয় শ্রেণি হবে, product.setPriceকোনও Productবস্তুকে রূপান্তরিত করবে না বরং পরিবর্তে একটি নতুন অবজেক্ট ফিরিয়ে দেবে, এবং increasePriceফাংশনটি "একক" ফাংশন হবে। আপনার মতো একটি অনুরূপ দেখতে সিনট্যাক্স ব্যবহার করা (সি # / জাভা মত), একটি সমতুল্য ফাংশনটি এর মতো দেখতে পারে:

 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;
}

যেমন আপনি দেখতে পাচ্ছেন, কনট্রিভড ওওপি উদাহরণ থেকে "বয়লারপ্লেট" কোড বাদ দিলে মূলটি এখানে সত্যিই আলাদা নয়। যাইহোক, আমি এটিকে প্রমাণ হিসাবে দেখছি না যে ওওপি ফোলা কোডের দিকে নিয়ে যায়, কেবলমাত্র তার প্রমাণ হিসাবে যদি কেউ এমন একটি কোড উদাহরণ তৈরি করে যা যথেষ্ট পরিমাণে কৃত্রিম, তবে কিছু প্রমাণ করা সম্ভব।


7
এই "আরও এফপি" তৈরির উপায়: ১) আংশিক ফাংশনের পরিবর্তে মোট ফাংশনগুলি লেখার পক্ষে সহজ করার জন্য অযোগ্যতার পরিবর্তে সম্ভবত / ptionচ্ছিক প্রকারগুলি ব্যবহার করুন এবং "যদি (এক্স! = নাল)" বিমূর্ত করতে উচ্চতর-আদেশ সহায়ক ফাংশনগুলি ব্যবহার করুন যুক্তি। ২) পণ্যের দামের উপর কোনও লেন্সের প্রসঙ্গে শতকরা এক ভাগ বৃদ্ধির প্রয়োগের ক্ষেত্রে একক পণ্যের ক্রমবর্ধমান দাম নির্ধারণ করতে লেন্স ব্যবহার করুন। 3) মানচিত্র / নির্বাচন কলের জন্য একটি সুস্পষ্ট ল্যাম্বদা এড়ানোর জন্য আংশিক প্রয়োগ / রচনা / কার্য়িং ব্যবহার করুন।
জ্যাক

6
Gotta বলতে আমি ঘৃণা করি কোনও সংগ্রহের ধারণাটি ডিজাইনের দ্বারা খালি হওয়ার পরিবর্তে বাতিল হতে পারে। নেটিভ টুপল / সংগ্রহ সমর্থন সহ কার্যকরী ভাষা সেভাবে পরিচালিত হয়। এমনকি ওওপি-তেও আমি প্রত্যাবর্তন ঘৃণা করি nullযেখানে কোনও সংগ্রহ ফেরতের ধরণ। / রেন্ট শেষ
বেরিন লরিটস

তবে এটি জাভা বা সি # এর মতো ওওপি ভাষায় কোনও ইউটিলিটি ক্লাসের মতো একটি স্ট্যাটিক পদ্ধতি হতে পারে। এই কোডটি আংশিকভাবে সংক্ষিপ্ত কারণ আপনি তালিকায় পাস করতে এবং এটি নিজেকে ধরে না রাখার জন্য বলেছেন। মূল কোডটি একটি ডেটা স্ট্রাকচারও ধারণ করে এবং এটিকে সরিয়ে নিয়ে গেলে ধারণাগুলি পরিবর্তন না করে মূল কোডটি আরও খাটো করা যায়।
চিহ্নিত করুন

@ মার্ক: অবশ্যই, এবং আমি মনে করি ওপি এটি ইতিমধ্যে জানে। আমি প্রশ্নটিকে "কীভাবে এটি একটি কার্যকরী উপায়ে প্রকাশ করব" হিসাবে বুঝেছি, অ-ওওপি ভাষায় বাধ্যতামূলক নয়।
ডক ব্রাউন

@ মার্ক এফপি এবং ওও প্রত্যেকে বাদ দিবেন না।
পিটার বি

17

আমি বিশেষত যা জিজ্ঞাসা করছি তা হল এই উদাহরণটি কীভাবে কোনও এফপি ভাষায় মডেলিং / প্রোগ্রামিং করা হবে (প্রকৃত কোড, তাত্ত্বিকভাবে নয়)?

"এ" এফপি ভাষায়? যদি কোনও সমস্যা হয় তবে আমি ইমাস লিসপ বাছাই করব। এটির ধরণের ধারণা (ধরণের, ধরণের) রয়েছে তবে কেবল বিল্ট-ইনগুলি রয়েছে। সুতরাং আপনার উদাহরণ হ্রাস করে "কীভাবে আপনি কোনও তালিকার প্রতিটি আইটেমকে কোনও কিছুর দ্বারা গুণিত করেন এবং একটি নতুন তালিকা ফিরিয়ে দেন"।

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

এই নাও. অন্যান্য ভাষাগুলি একই রকম হবে, এই পার্থক্যের সাথে যে আপনি স্বাভাবিক ক্রিয়ামূলক "ম্যাচিং" শব্দার্থবিজ্ঞানের সাথে সুস্পষ্ট প্রকারের সুবিধা পাবেন। হাস্কেল দেখুন:

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

(বা এরকম কিছু, এটি যুগ যুগ হয়েছে ...)

আমি লেখকের যুক্তিগুলিতে উন্মুক্ত থাকতে চাই,

কেন? আমি নিবন্ধটি পড়ার চেষ্টা করেছি; আমাকে একটি পৃষ্ঠার পরে ছেড়ে দিতে হয়েছিল এবং কেবলমাত্র বাকীটি স্ক্যান করে।

নিবন্ধের সমস্যাটি এটি ওওপির বিরুদ্ধে নয়। আমিও অন্ধভাবে "প্রো ওওপি" নই। আমি যুক্তিযুক্ত, কার্যকরী এবং ওওপি দৃষ্টান্তের সাথে প্রোগ্রাম করেছি, প্রায়শই একই ভাষায় যখন সম্ভব হয় এবং প্রায়শই তিনটি কারও ছাড়াই নিখুঁতভাবে আবশ্যকীয় এমনকি এসেম্বলারের পর্যায়েও থাকে। আমি কখনই বলব না যে those দৃষ্টান্তগুলির কোনওটিই প্রতিটি দিক থেকে একে অপরের পক্ষে যথেষ্ট উচ্চতর। আমি কি যুক্তি দেব যে আমি এক্স এর চেয়ে আরও ভাল ভাষা Y পছন্দ করি? অবশ্যই আমি করব! কিন্তু যে নিবন্ধটি সম্পর্কে হয় না।

নিবন্ধটির সমস্যাটি হ'ল তিনি প্রথম থেকে শেষ বাক্য পর্যন্ত প্রচুর বাকবিতণ্ডার সরঞ্জাম (ভ্রান্তি) ব্যবহার করেন। এমনকি এতে থাকা সমস্ত ত্রুটিগুলি বর্ণনা করা এমনকি সম্পূর্ণরূপে নিরর্থক। লেখক এটিকে স্পষ্ট করে জানিয়ে দিয়েছেন যে আলোচনায় তাঁর শূন্য আগ্রহ আছে, তিনি ক্রুসেডে রয়েছেন। তাহলে কেন বিরক্ত করবেন?

দিনের শেষে এই সমস্ত জিনিস একটি কাজ করার জন্য কেবল সরঞ্জাম। OOP ভাল যেখানে কাজ থাকতে পারে, এবং অন্যান্য কাজও থাকতে পারে যেখানে FP ভাল, বা যেখানে উভয়ই overkill হয়। গুরুত্বপূর্ণ জিনিসটি কাজের জন্য সঠিক সরঞ্জামটি বেছে নেওয়া এবং এটি সম্পন্ন করা।


4
"প্রচুর পরিমাণে স্পষ্ট যে তাঁর আলোচনায় শূন্য আগ্রহ রয়েছে, তিনি ক্রুসেডে রয়েছেন" এই রত্নটির প্রতি লক্ষ্য রাখুন Have
ইউফোরিক

আপনার হাস্কেল কোডে কোনও সংখ্যক সীমাবদ্ধতার দরকার নেই? অন্যথায় আপনি কীভাবে (*) কল করতে পারেন?
জে কে।

@ জে কে।, আমি যুগে যুগে হাস্কেলকে করেছি, সে কেবল উত্তরটির সন্ধানের জন্য ওপি'র সীমাবদ্ধতা পূরণ করেছিল। ;) যদি কেউ আমার কোড ঠিক করতে চান তবে নির্দ্বিধায়। তবে নিশ্চিত, আমি এটিকে নমে স্যুইচ করব।
AnoE

7

লেখক একটি খুব ভাল পয়েন্ট তৈরি করেছেন তারপরে ব্যাক আপ করার চেষ্টা করার জন্য একটি অনুপযুক্ত উদাহরণ বেছে নিয়েছে। অভিযোগটি ক্লাস বাস্তবায়নের সাথে নয়, এটি এই ধারণার সাথে যে ডেটা হায়ারার্কি ফাংশন হায়ারার্কির সাথে মিলিয়ে অবিচ্ছেদ্যভাবে তৈরি করা হয়েছে।

এটি তারপরে অনুসরণ করে, লেখকের বক্তব্য বোঝার জন্য, তিনি কেবলমাত্র এই একক শ্রেণিকে কীভাবে কার্যকরী শৈলীতে বাস্তবায়ন করবেন তা দেখতে সহায়তা করবে না। আপনাকে দেখতে হবে যে কীভাবে তিনি এই শ্রেণীর চারপাশে ডেটা এবং ফাংশনগুলির পুরো প্রসঙ্গটি কার্যকরী শৈলীতে ডিজাইন করবেন।

পণ্য এবং মূল্যের সাথে জড়িত সম্ভাব্য ডেটা ধরণের সম্পর্কে চিন্তা করুন। কয়েকটি বুদ্ধিমানের জন্য: নাম, upc কোড, বিভাগ, শিপিং ওজন, দাম, মুদ্রা, ছাড় কোড, ছাড়ের নিয়ম।

এটি অবজেক্ট-ওরিয়েন্টেড ডিজাইনের সহজ অংশ। উপরের সমস্ত "অবজেক্ট" এর জন্য আমরা কেবল একটি ক্লাস তৈরি করি এবং আমরা ভাল, তাই না? Productতাদের কয়েকটিকে একত্রিত করার জন্য একটি বর্গ তৈরি করবেন?

তবে অপেক্ষা করুন, আপনার এই ধরণের কয়েকটি সংগ্রহ এবং সমষ্টি হতে পারে: সেট [বিভাগ], (ছাড় কোড -> মূল্য), (পরিমাণ -> ছাড়ের পরিমাণ) এবং আরও অনেক কিছু। তারা কোথায় ফিট? আমরা CategoryManagerকি বিভিন্ন ধরণের ক্যাটাগরির ট্র্যাক রাখতে আলাদা তৈরি করি , বা সেই দায়িত্বটি কি Categoryআমরা ইতিমধ্যে তৈরি করা শ্রেণীর অন্তর্ভুক্ত?

এখন আপনার কাছে দুটি আলাদা বিভাগ থেকে নির্দিষ্ট পরিমাণের আইটেম রয়েছে তবে এমন ফাংশনগুলি কীভাবে আপনাকে মূল্য ছাড় দেয়? এটি কি Productক্লাসে, Categoryক্লাসে, DiscountRuleক্লাসে, CategoryManagerক্লাসে যায় বা আমাদের নতুন কিছু দরকার হয়? আমরা এভাবেই শেষ করি DiscountRuleProductCategoryFactoryBuilder

ফাংশনাল কোডে, আপনার ডেটা শ্রেণিবদ্ধতা আপনার ফাংশনগুলির সাথে সম্পূর্ণ orthogonal। আপনি যেকোন উপায়ে শব্দকর্মটি বোধগম্য করে আপনার ফাংশনগুলি সাজিয়ে রাখতে পারেন। উদাহরণস্বরূপ, আপনি সমস্ত ফাংশনগুলিকে গ্রুপবদ্ধ করতে পারেন যা পণ্যগুলির দামগুলি একসাথে পরিবর্তিত করে, 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, ওওপি সংস্করণে সেই সংগ্রহটি পরিচালনা করার জন্য পদ্ধতিগুলি অন্তর্ভুক্ত করা দরকার, তবে আপনি এই মডিউলটি পণ্য নির্বাচনের বিষয়ে থাকতে চান না, আপনি চেয়েছিলেন এটি দামের বিষয়ে হোক। ফাংশন-ডেটা কাপলিং আপনাকে সেখানে সংগ্রহের পরিচালনা বয়লারপ্লেট নিক্ষেপ করতে বাধ্য করেছিল।

আপনি সদস্যটিকে productsএকটি পৃথক শ্রেণিতে রেখে সমাধান করার চেষ্টা করতে পারেন তবে তারপরে আপনি খুব দৃ tight়-সংযুক্ত ক্লাস দিয়ে শেষ করেন। ওও প্রোগ্রামাররা ফাংশন-ডেটা সংযোগকে খুব প্রাকৃতিক এবং এমনকি উপকারী হিসাবে ভাবেন তবে নমনীয়তার ক্ষতিতে এর সাথে একটি উচ্চ ব্যয় যুক্ত হয়। যে কোনও সময় আপনি কোনও ফাংশন তৈরি করার সময়, আপনাকে অবশ্যই এটি এক এবং কেবলমাত্র একটি শ্রেণিতে অর্পণ করতে হবে। আপনি যে কোনও সময় কোনও ফাংশন ব্যবহার করতে চান, আপনাকে অবশ্যই এর দম্পতিযুক্ত ডেটা ব্যবহারের স্থানে পৌঁছানোর কোনও উপায় খুঁজে বের করতে হবে। সেই সীমাবদ্ধতা বিশাল


2

লেখক এফ # ("একটি এফপি ভাষা") এ দেখতে এটির ইঙ্গিত দিচ্ছিল কেবল তথ্য এবং ফাংশনকে আলাদা করে দেওয়া।

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)

দ্রষ্টব্য: আপনি যদি এফপির সাথে পরিচিত না হন তবে প্রতিটি ফাংশন একটি মান দেয়। সি-এর মতো ভাষা থেকে আসা, আপনি কোনও ফাংশনে সর্বশেষ বিবৃতিটি এমনভাবে আচরণ করতে পারেন যেমন এটির returnসামনে রয়েছে।

আমি কিছু ধরণের টীকাগুলি অন্তর্ভুক্ত করেছি তবে সেগুলি অপ্রয়োজনীয় হওয়া উচিত। গিটার / সেটারটি এখানে অপ্রয়োজনীয় যেহেতু মডিউলটি ডেটার মালিক নয়। এটি ডেটা এবং উপলব্ধ ক্রিয়াকলাপের কাঠামোর মালিক। এটি Listপাশাপাশি দেখা যায় , যা mapতালিকার প্রতিটি উপাদানগুলিতে একটি ক্রিয়াকলাপ চালিয়ে দেয় এবং ফলাফলটি একটি নতুন তালিকায় ফেরত দেয় returns

লক্ষ্য করুন যে পণ্য মডিউলটি লুপিং সম্পর্কে কিছু জানতে হবে না, কারণ সেই দায়িত্ব তালিকা মডিউলটির সাথে থাকে (যারা লুপিংয়ের প্রয়োজনীয়তা তৈরি করেছিলেন)।


1

আমি এটিকে এই উপস্থাপনা করি যে আমি কার্যকরী প্রোগ্রামিংয়ের কোনও বিশেষজ্ঞ নই। আমি আরও একজন ওওপি ব্যক্তি। সুতরাং আমি যখন নিশ্চিত হলাম নীচে আপনি এফপির সাথে একই ধরণের কার্যকারিতা কীভাবে সম্পাদন করবেন তবে আমি ভুল হতে পারি।

এটি টাইপস্ক্রিপ্টে রয়েছে (সুতরাং সমস্ত ধরণের টীকা)। টাইপস্ক্রিপ্ট (জাভাস্ক্রিপ্টের মতো) একটি বহু-ডোমেন ভাষা।

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 );

বিশদে বিশদভাবে (এবং আবারও, কোনও এফপি বিশেষজ্ঞ নয়), বোঝার বিষয়টি হল যে পূর্বনির্ধারিত আচরণের খুব বেশি কিছু নেই। কোনও "বর্ধিত মূল্য" পদ্ধতি নেই যা পুরো তালিকা জুড়ে দাম বৃদ্ধির প্রয়োগ করে, কারণ অবশ্যই এটি ওওপি নয়: এমন আচরণের সংজ্ঞা দেওয়ার কোনও শ্রেণি নেই। পণ্যগুলির তালিকা সঞ্চয় করে এমন কোনও বস্তু তৈরির পরিবর্তে আপনি কেবল পণ্যের একটি অ্যারে তৈরি করুন। তারপরে আপনি এই অ্যারেটি যেভাবে চান তা কাজে লাগাতে স্ট্যান্ডার্ড এফপি পদ্ধতি ব্যবহার করতে পারেন: নির্দিষ্ট আইটেম নির্বাচন করতে ফিল্টার করুন, ইন্টার্নালগুলি সমন্বিত করার জন্য মানচিত্র ইত্যাদি ... আপনি সীমাবদ্ধ না রেখে আপনার পণ্যের তালিকার উপর আরও বিস্তারিত নিয়ন্ত্রণের সাথে শেষ করুন সিম্পল প্রোডাক্ট ম্যানেজার আপনাকে দেয় এমন এপিআই। এটি কারও দ্বারা একটি সুবিধা হিসাবে বিবেচিত হতে পারে। এটাও সত্য যে আপনি ডন ' প্রোডাক্ট ম্যানেজার ক্লাসের সাথে সম্পর্কিত কোনও লাগেজ সম্পর্কে চিন্তা করতে হবে না। অবশেষে, "সেটপ্রোডাক্টস" বা "গেটপ্রডাক্টস" নিয়ে কোনও উদ্বেগ নেই, কারণ আপনার পণ্যগুলি আড়াল করে রাখার মতো কোনও বিষয় নেই: পরিবর্তে, আপনি যে পণ্যগুলির সাথে কাজ করছেন তার তালিকা আপনার কাছে রয়েছে। আবার, আপনি যে পরিস্থিতিতে / ব্যক্তির সাথে কথা বলছেন তার উপর নির্ভর করে এটি কোনও সুবিধা বা অসুবিধা হতে পারে। এছাড়াও, স্পষ্টত কোনও শ্রেণিবদ্ধতা নেই (যা তিনিই অভিযোগ করেছিলেন) কারণ সেখানে প্রথম স্থান নেই। আপনি যে পরিস্থিতিতে / ব্যক্তির সাথে কথা বলছেন তার উপর নির্ভর করে এটি কোনও সুবিধা বা অসুবিধা হতে পারে। এছাড়াও, স্পষ্টত কোনও শ্রেণিবদ্ধতা নেই (যা তিনিই অভিযোগ করেছিলেন) কারণ সেখানে প্রথম স্থান নেই। আপনি যে পরিস্থিতিতে / ব্যক্তির সাথে কথা বলছেন তার উপর নির্ভর করে এটি কোনও সুবিধা বা অসুবিধা হতে পারে। এছাড়াও, স্পষ্টত কোনও শ্রেণিবদ্ধতা নেই (যা তিনিই অভিযোগ করেছিলেন) কারণ সেখানে প্রথম স্থান নেই।

আমি তার পুরো রেন্ট পড়তে সময় নিই নি। সুবিধাজনক হলে আমি এফপি অনুশীলনগুলি ব্যবহার করি, তবে আমি অবশ্যই ওওপি ধরণের লোকের চেয়ে বেশি। আমি আপনার প্রশ্নের উত্তর দেওয়ার পরে আমি বুঝতে পেরেছিলাম, আমি তার মতামত সম্পর্কে কিছু সংক্ষিপ্ত মন্তব্যও করব। আমি মনে করি এটি একটি অত্যন্ত স্বতঃস্ফূর্ত উদাহরণ যা ওওপির "ডাউনসাইড" হাইলাইট করে। এই বিশেষ ক্ষেত্রে, প্রদর্শিত কার্যকারিতাটির জন্য, ওওপি সম্ভবত ওভার-কিল, এবং সম্ভবত এফপি আরও ভাল ফিট হবে। তারপরে আবার, যদি এটি কোনও শপিং কার্টের মতো হয়ে থাকে, আপনার পণ্যগুলির তালিকা রক্ষা করা এবং এতে অ্যাক্সেস সীমাবদ্ধ করা (আমি মনে করি) প্রোগ্রামটির একটি অত্যন্ত গুরুত্বপূর্ণ লক্ষ্য এবং এফপির কাছে এগুলি কার্যকর করার কোনও উপায় নেই। আবার, এটি কেবল এটি হতে পারে যে আমি কোনও এফপি বিশেষজ্ঞ নই, তবে ই-কমার্স সিস্টেমের জন্য শপিং কার্টগুলি প্রয়োগ করে আমি এফপির চেয়ে ওওপি ব্যবহার করব।

ব্যক্তিগতভাবে আমার যে কাউকে গুরুত্ব সহকারে নিতে কঠোর সময় হচ্ছে যা "এক্স মাত্র ভয়ঙ্কর Always সর্বদা ওয়াই" ব্যবহার করুন for প্রোগ্রামিংয়ে বিভিন্ন ধরণের সরঞ্জাম এবং দৃষ্টান্ত রয়েছে কারণ সমাধানের জন্য বিভিন্ন ধরণের সমস্যা রয়েছে। এফপির তার স্থান রয়েছে, ওওপি এর জায়গা আছে এবং যদি তারা আমাদের সমস্ত সরঞ্জামের ত্রুটিগুলি এবং সুবিধা বুঝতে না পারে এবং সেগুলি কখন ব্যবহার করতে পারে তবে কেউ দুর্দান্ত প্রোগ্রামার হতে চলেছে না to

** দ্রষ্টব্য: অবশ্যই আমার উদাহরণে একটি শ্রেণি রয়েছে: পণ্য শ্রেণি। এই ক্ষেত্রে যদিও এটি কেবল বোবা ডেটা ধারক: আমি মনে করি না যে এটির আমার ব্যবহার এফপির নীতিগুলি লঙ্ঘন করে। এটি টাইপ চেকিংয়ের জন্য আরও সহায়ক।

** দ্রষ্টব্য: আমি আমার মাথার উপরের অংশটি মনে রাখছি না এবং আমি মানচিত্রের ফাংশনটি যেভাবে ব্যবহার করেছি তাতে জায়গাগুলি পণ্যগুলি সংশোধন করা হবে কিনা তা যাচাই করে নি, অর্থাৎ আমি কি অজান্তেই মূল পণ্যগুলিতে পণ্যের দাম দ্বিগুণ করেছি? অ্যারে। স্পষ্টতই এফপি যে ধরণের পার্শ্ব প্রতিক্রিয়া এড়াতে চেষ্টা করেছে এবং এর চেয়ে আরও কিছু কোডের সাথে আমি অবশ্যই নিশ্চিত করতে পারি যে এটি ঘটেছিল না।


2
এটি শাস্ত্রীয় অর্থে সত্যই কোনও ওওপি উদাহরণ নয়। সত্য ওওপিতে, ডেটা ব্যবহারের সাথে একত্রিত হবে; এখানে, আপনি দুজনকে আলাদা করেছেন। এটি অগত্যা কোনও খারাপ জিনিস নয় (আমি আসলে এটি ক্লিনার বলে মনে করি) তবে এটি এমন নয় যা আমি ক্লাসিকাল ওওপি বলব।
রবার্ট হার্ভে

0

সিম্পল প্রোডাক্ট ম্যানেজারটি কোনও কিছুর (প্রসারিত বা উত্তরাধিকারসূত্রে) শিশু বলে মনে হয় না।

প্রোডাক্ট ম্যানেজার ইন্টারফেসের এটি কেবল বাস্তবায়ন যা মূলত একটি চুক্তি যা অবজেক্টটির কী কর্ম (আচরণ) করে তা নির্ধারণ করে।

যদি এটি শিশু হয় (বা আরও ভালভাবে বলা হয়েছে, উত্তীর্ণ শ্রেণি বা শ্রেণি অন্য শ্রেণীর কার্যকারিতা প্রসারিত করে) তবে এটি লিখিত হবে:

class SimpleProductManager extends ProductManager {
    ...
}

সুতরাং মূলত, লেখক বলেছেন:

Whe এর কিছু অবজেক্ট থাকে যা আচরণ: সেট প্রডাক্ট, বর্ধমান, গেটপ্রডাক্টস। এবং বিষয়টির অন্যরকম আচরণ বা আচরণ কীভাবে প্রয়োগ করা হয় তা আমাদের যত্ন নেই don't

সিম্পলপ্রডাক্টম্যানেজার শ্রেণি এটি প্রয়োগ করে। মূলত, এটি ক্রিয়াগুলি কার্যকর করে।

এটিকে শতাংশ শতাংশের মূল্য বাড়িয়ে তোলার মূল আচরণ হওয়ায় এটিকে শতাংশ শতাংশও বলা যেতে পারে I

তবে আমরা অন্য একটি ক্লাসও প্রয়োগ করতে পারি: মানপ্রিয়াসিঙ্ক্রেসার যা আচরণ করবে:

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

বাহ্যিক দৃষ্টিকোণ থেকে, কিছুই পরিবর্তিত হয়নি, ইন্টারফেস একই, এখনও একই তিনটি পদ্ধতি আছে তবে আচরণটি ভিন্ন।

এফপিতে ইন্টারফেসের মতো কোনও জিনিস নেই বলে এটি কার্যকর করা কঠিন to সিতে, উদাহরণস্বরূপ, আমরা ফাংশনগুলিতে পয়েন্টার ধরে রাখতে পারি এবং আমাদের প্রয়োজনের ভিত্তিতে উপযুক্তটিকে কল করতে পারি। শেষ পর্যন্ত, ওওপিতে এটি খুব অনুরূপভাবে কাজ করে তবে সংকলক দ্বারা এটি "স্বয়ংক্রিয়"।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.