কোনও ইন্টারফেসের সিওম্যান্টিক চুক্তি (ওওপি) কোনও ফাংশন সিগনেচার (এফপি) এর চেয়ে বেশি তথ্যপূর্ণ?

16

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

নিবন্ধ থেকে:

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

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

public interface IMessageQuery
{
    string Read(int id);
}

যদি আমি কোনওটির উপর নির্ভরতা নিই IMessageQueryতবে অন্তর্ভুক্ত চুক্তির অংশটি হ'ল কলিং Read(id)প্রদত্ত আইডি সহ একটি বার্তা সন্ধান করে এবং ফিরে আসবে।

এটির সমতুল্য কার্যক্ষম স্বাক্ষরের উপর নির্ভরতা নেওয়ার সাথে তুলনা করুন int -> string। কোনও অতিরিক্ত সংকেত ছাড়াই, এই ফাংশনটি একটি সহজ হতে পারে ToString()। আপনি যদি IMessageQuery.Read(int id)একটি প্রয়োগ করে থাকেন তবে ToString()আমি আপনাকে ইচ্ছাকৃতভাবে ধ্বংসাত্মক বলে অভিযুক্ত করতে পারি!

সুতরাং, একটি নামক ইন্টারফেসের শব্দার্থক সংরক্ষণের জন্য ক্রিয়ামূলক প্রোগ্রামাররা কী করতে পারে? উদাহরণস্বরূপ, এটি কি কোনও একক সদস্যের সাথে রেকর্ড টাইপ তৈরি করা প্রচলিত?

type MessageQuery = {
    Read: int -> string
}

object-oriented functional-programming solid

— AlexFoxGill
সূত্র

5

একটি ওওপি ইন্টারফেসটি আরও একটি এফপি টাইপক্লাসের মতো , একক ফাংশন নয়।

— 9:19

2

আপনার খুব ভাল জিনিস থাকতে পারে, আইএসপি প্রয়োগ 'কঠোরভাবে' ইন্টারফেস প্রতি 1 পদ্ধতি দিয়ে শেষ করতে খুব দূরে যাচ্ছে।

— gbjbaanb

3

@gbjbaanb আসলে আমার ইন্টারফেসের বেশিরভাগেরই অনেকগুলি বাস্তবায়ন সহ একটি পদ্ধতি রয়েছে। আপনি যতটা সলিড নীতি প্রয়োগ করেন তত বেশি সুবিধা আপনি দেখতে পাবেন। তবে এটি এই প্রশ্নের অফ-টপিক

— অ্যালেক্সফক্সগিল

1

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

— 9000

2

Without any additional clues... সম্ভবত ডকুমেন্টেশন কেন চুক্তির অংশ ?

— এসজুয়ান 76

8

যেমন টেলাস্টিন বলেছেন, ফাংশনগুলির স্থির সংজ্ঞা তুলনা:

public string Read(int id) { /*...*/ }

প্রতি

let read (id:int) = //...

আপনি ওওপি থেকে এফপিতে যেতে সত্যিই কিছু হারান নি।

তবে এটি কেবল গল্পেরই অংশ, কারণ ফাংশন এবং ইন্টারফেসগুলি কেবল তাদের স্থির সংজ্ঞাগুলিতে উল্লেখ করা হয় না। তারাও প্রায় পার হয়ে গেছে । সুতরাং আসুন আমরা আমাদের MessageQueryকোডের আরও একটি টুকরো দ্বারা পড়েছিলাম বলি MessageProcessor। তারপর আমাদের আছে:

public void ProcessMessage(int messageId, IMessageQuery messageReader) { /*...*/ }

এখন আমরা সরাসরি পদ্ধতির নাম IMessageQuery.Readবা এর প্যারামিটার দেখতে পাচ্ছি না int idতবে আমরা আমাদের আইডিই এর মাধ্যমে খুব সহজেই সেখানে যেতে পারি। আরও সাধারণভাবে, আমরা IMessageQueryকোনও পদ্ধতির সাথে কেবল কোনও ইন্টারফেসের চেয়ে একটি প্রান্ত থেকে স্ট্রিং পর্যন্ত ফাংশনটি অতিক্রম করি তা হ'ল আমরা idএই ফাংশনের সাথে যুক্ত পরামিতিটির নাম মেটাডেটা রাখছি ।

অন্যদিকে, আমাদের কার্যকরী সংস্করণের জন্য আমাদের কাছে রয়েছে:

let read (id:int) (messageReader : int -> string) = // ...

তাহলে আমরা কী রেখেছি এবং হারিয়ে ফেলেছি? ঠিক আছে, আমাদের এখনও প্যারামিটারের নাম রয়েছে messageReaderযা সম্ভবত টাইপের নামটিকে (সমতুল্য IMessageQuery) অপ্রয়োজনীয় করে তোলে । তবে এখন আমরা idআমাদের ফাংশনে প্যারামিটারের নামটি হারিয়ে ফেলেছি ।

এর চারপাশে দুটি প্রধান উপায় রয়েছে:

প্রথমত, সেই স্বাক্ষরটি পড়া থেকে আপনি ইতিমধ্যে খুব ভাল অনুমান করতে পারেন যে কী চলছে। ফাংশনগুলি সংক্ষিপ্ত, সহজ এবং সংযুক্ত করে এবং ভাল নামকরণ ব্যবহার করে আপনি এই তথ্যটি অন্তর্নিহিত করা বা এটি সন্ধান করা অনেক সহজ করে তুলেছেন। একবার আমরা আসল ফাংশনটি নিজেই পড়তে শুরু করি, এটি আরও সহজ হবে।
দ্বিতীয়ত, আদিমাগুলি মোড়ানোর জন্য ছোট ধরনের তৈরি করতে এটি অনেকগুলি কার্যকরী ভাষায় আইডোমেটিক ডিজাইন হিসাবে বিবেচিত হয় । এই ক্ষেত্রে, বিপরীতটি ঘটছে- একটি পরামিতি নামের ( IMessageQueryটু messageReader) সাথে কোনও প্রকারের নাম প্রতিস্থাপনের পরিবর্তে আমরা কোনও পরামিতিটির নাম একটি প্রকারের নামের সাথে প্রতিস্থাপন করতে পারি। উদাহরণস্বরূপ, intএকটি প্রকারের মধ্যে মোড়ানো হতে পারে Id:
```
type Id = Id of int
```
এখন আমাদের readস্বাক্ষর হয়ে যায়:
```
let read (id:int) (messageReader : Id -> string) = // ...
```
যা আমাদের আগের মতো ঠিক তথ্যপূর্ণ informa

পার্শ্ব নোট হিসাবে, এটি আমাদের ওওপিতে সংকলক সুরক্ষাও সরবরাহ করে। যদিও ওওপি সংস্করণটি নিশ্চিত করেছে যে আমরা IMessageQueryকেবল কোনও পুরানো int -> stringফাংশন না দিয়ে বিশেষত একটি গ্রহণ করেছি, এখানে আমাদের একটি অনুরূপ (তবে আলাদা) সুরক্ষা রয়েছে যা আমরা কোনও Id -> stringপুরানোের চেয়ে বরং গ্রহণ করছি int -> string।

আমি ১০০% আত্মবিশ্বাসের সাথে বলতে অনিচ্ছুক যে এই কৌশলগুলি সর্বদা একটি ইন্টারফেসে সম্পূর্ণ তথ্য প্রাপ্তির মতোই ভাল এবং তথ্যবহুল হবে, তবে আমি উপরের উদাহরণগুলি থেকে মনে করি, আপনি বলতে পারেন যে বেশিরভাগ সময় আমরা, সম্ভবত ঠিক একটি কাজ হিসাবে ভাল করতে পারেন।

— বেন অ্যারনসন
সূত্র

1

এটি আমার প্রিয় উত্তর - এফপি

— সিমেটিক

10

এফপি করার সময় আমি আরও নির্দিষ্ট সিমেন্টিক টাইপ ব্যবহার করার ঝোঁক করি।

উদাহরণস্বরূপ, আপনার জন্য আমার পদ্ধতিটি এমন কিছু হয়ে উঠবে:

read: MessageId -> Message

এটি ওও (/ জাভা) স্টাইল ThingDoer.doThing()স্টাইলের চেয়ে অনেক বেশি যোগাযোগ করে

— Daenyth
সূত্র

2

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

— জ্যাক

1

আমি কেন এই আদানপ্রদান করবে ঠিক স্পষ্ট নই আরো জাভা শৈলীর চেয়ে। আপনি কি না read: MessageId -> Messageযে string MessageReader.GetMessage(int messageId)না?

— বেন অ্যারনসন

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

— দেনিথ

9

সুতরাং, একটি নামক ইন্টারফেসের শব্দার্থক সংরক্ষণের জন্য ক্রিয়ামূলক প্রোগ্রামাররা কী করতে পারে?

নামযুক্ত ফাংশন ব্যবহার করুন।

IMessageQuery::Read: int -> stringকেবল হয়ে যায় ReadMessageQuery: int -> stringবা অনুরূপ কিছু।

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

কোনও ইন্টারফেসের সিওম্যান্টিক চুক্তি (ওওপি) কোনও ফাংশন সিগনেচার (এফপি) এর চেয়ে বেশি তথ্যপূর্ণ?

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

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

ব্যক্তিগতভাবে, আমি ভাবি না যে ওও আরও জটিল তথ্য উদাহরণস্বরূপ, আরও তথ্যবহুল।

— Telastyn
সূত্র

2

প্যারামিটারের নাম কী?

— বেন অ্যারনসন

@ বেআনারসন - তাদের কী হবে? ওও এবং ক্রিয়ামূলক উভয় ভাষাই আপনাকে প্যারামিটারের নাম নির্দিষ্ট করতে দেয়, যাতে এটি একটি চাপ। প্রশ্নের সাথে সামঞ্জস্য রাখতে আমি এখানে স্বাক্ষর শর্টহ্যান্ড টাইপটি ব্যবহার করছি। আসল ভাষায় এটি দেখতে কিছুটা এমন দেখাবেReadMessageQuery id = <code to go fetch based on id>

— টেলাস্টিন

1

ঠিক আছে যদি কোনও ফাংশন একটি প্যারামিটার হিসাবে একটি ইন্টারফেস নেয়, তবে সেই ইন্টারফেসে কোনও পদ্ধতি কল করে, ইন্টারফেস পদ্ধতির পরামিতিগুলির নামগুলি সহজেই উপলব্ধ available যদি কোনও ফাংশন প্যারামিটার হিসাবে অন্য ফাংশন নেয়, তবে ফাংশনে পাসের জন্য প্যারামিটারের নামগুলি অর্পণ করা সহজ নয়

— বেন অ্যারনসন

1

হ্যাঁ, @ বেনআারনসন এটি ফাংশনের স্বাক্ষরে হারিয়ে যাওয়া তথ্যের টুকরোগুলির মধ্যে একটি। উদাহরণস্বরূপ let consumer (messageQuery : int -> string) = messageQuery 5, idপ্যারামিটারটি মাত্র একটি int। আমি অনুমান করি একটি যুক্তি হ'ল আপনার একটি পাস করা উচিত Id, একটি নয় int। আসলে এটি নিজের মধ্যে একটি শালীন উত্তর তৈরি করবে।

— অ্যালেক্সফক্সগিল

@ অ্যালেক্সফক্সগিল আসলে আমি ঠিক সেই লাইনে কিছু লেখার প্রক্রিয়ায় ছিলাম!

— বেন অ্যারনসন

0

আমি একমত যে একক ফাংশনটির 'সিনেটিক চুক্তি' থাকতে পারে না। এই আইনগুলি বিবেচনা করুন foldr:

foldr f z nil = z
foldr f z (singleton x) = f x z
foldr f z (xn <> ys) = foldr f (foldr f z ys) xn

কোন অর্থে এটি অর্থবোধক নয়, বা চুক্তি নয়? আপনার কোনও 'ফোল্ডার' এর জন্য কোনও ধরণের সংজ্ঞা দেওয়ার দরকার নেই, বিশেষত কারণ foldrএই আইনগুলি দ্বারা অনন্যভাবে নির্ধারিত। আপনি ঠিক জানেন যে এটি কি করতে চলেছে।

আপনি যদি কোনও ধরণের কোনও ফাংশন নিতে চান তবে আপনি একই জিনিসটি করতে পারেন:

-- The first argument `f` must satisfy for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
sort :: forall 'a. (a -> a -> bool.t) -> list.t a -> list.t a;

আপনার যদি একই চুক্তির একাধিকবার প্রয়োজন হয় তবে আপনাকে কেবল সেই ধরণের নাম এবং ক্যাপচার করতে হবে:

-- Type of functions `f` satisfying, for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
type comparison.t 'a = a -> a -> bool.t;

টাইপ-চেকার আপনি কোনও ধরণের সিমানটিকসকে যেভাবে নির্ধারণ করেন তা প্রয়োগ করতে যাচ্ছে না, তাই প্রতিটি চুক্তির জন্য একটি নতুন ধরণ তৈরি করা কেবল বয়লারপ্লেট।

— জনাথন কাস্ট
সূত্র

1

আমি মনে করি না যে আপনার প্রথম পয়েন্টটি প্রশ্নের সমাধান করে - এটি একটি ফাংশন সংজ্ঞা, স্বাক্ষর নয়। অবশ্যই কোনও শ্রেণি বা কোনও ক্রিয়াকলাপের বাস্তবায়ন দেখে আপনি এটি কী করতে পারেন তা বলতে পারেন - প্রশ্নটি জিজ্ঞাসা করে আপনি এখনও বিমূর্ততার একটি স্তরে শব্দার্থবিজ্ঞান সংরক্ষণ করতে পারেন (একটি ইন্টারফেস বা ফাংশন স্বাক্ষর)

— অ্যালেক্সফক্সগিল

@AlexFoxGill - এটা না একটি ফাংশন সংজ্ঞা, যদিও এটি স্বতন্ত্র নির্ধারণ করে foldr। ইঙ্গিত: সংজ্ঞাটির foldrদুটি সমীকরণ রয়েছে (কেন?) এবং উপরে বর্ণিত স্পেসিফিকেশনটির তিনটি রয়েছে।

— জোনাথন

আমার অর্থ হ'ল ফোল্ডারটি একটি ফাংশন যা কোনও ফাংশনের স্বাক্ষর নয়। আইন বা সংজ্ঞাটি স্বাক্ষরের অংশ নয়

— অ্যালেক্সফক্সগিল

-1

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

উদাহরণস্বরূপ, বলুন যে কোনও ক্লায়েন্ট কোনও বার্তা ক্যোয়ারির একটি প্রয়োগ চান যা একটি তালিকা দ্বারা ব্যাক হয়েছিল। হাসকেলে, বাস্তবায়ন এটির মতো সহজ হতে পারে:

messages = ["Message 0", "Message 1", "Message 2"]
messageQuery = (messages !!)

ব্যবহার newtype Message = Message Stringএই অনেক কম সহজবোধ্য হবে, ভালো কিছু খুঁজছেন এই বাস্তবায়ন যাব:

messages = map Message ["Message 0", "Message 1", "Message 2"]
messageQuery (Id index) = messages !! index

এটি কোনও বড় চুক্তির মতো নাও মনে হতে পারে তবে আপনাকে এই ধরণের রূপান্তরটি সর্বত্র এবং সর্বত্রই করতে হবে বা আপনার কোডের একটি সীমানা স্তর স্থাপন করতে হবে যেখানে উপরের সমস্ত কিছুই Int -> Stringআপনাকে Id -> Messageনীচের স্তরে পাস করার জন্য রূপান্তর করতে হবে। বলুন আমি আন্তর্জাতিকীকরণ যুক্ত করতে চেয়েছিলাম, বা সমস্ত ক্যাপগুলিতে এটি ফর্ম্যাট করতে চেয়েছি, বা লগিং প্রসঙ্গে বা যা কিছু যোগ করতে চাইছি। এই ক্রিয়াকলাপগুলি একটি রচনা করার জন্য সমস্ত মৃত সহজ Int -> String, এবং একটি সাথে বিরক্তিকর Id -> Message। এটি এমন নয় যে বর্ধিত ধরণের নিষেধাজ্ঞাগুলি কখনই কাম্য নয়, তবে বিরক্তি বাণিজ্যটি বন্ধ রাখার পক্ষে উপযুক্ত।

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

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

— কার্ল বিলেফেল্ট
সূত্র

1

এটি বেন / ডেনিথের উত্তরগুলিতে আরও বেশি মন্তব্য করার মতো অনুভূত হয় - যে আপনি শব্দার্থক প্রকারগুলি ব্যবহার করতে পারেন তবে অসুবিধার কারণে না? আমি আপনাকে হ্রাস করি নি তবে এটি এই প্রশ্নের উত্তর নয়।

— অ্যালেক্সফক্সগিল

-1 এটি সামঞ্জস্যতা বা পুনঃব্যবহারযোগ্যতা মোটেই ক্ষতি করবে না। যদি Idএবং Messageজন্য সহজ চাদরে হয় Intএবং String, এটা তুচ্ছ তাদের মধ্যে রূপান্তর করবে।

— মাইকেল শ

হ্যাঁ, এটি তুচ্ছ, তবে সমস্ত জায়গাতেই বিরক্তিজনক oy আমি একটি উদাহরণ যুক্ত করেছি এবং কিছুটা টাইপ প্রতিশব্দ এবং মোড়কের ব্যবহারের মধ্যে পার্থক্য বর্ণনা করে।

— কার্ল বিলেফেল্ট

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

— বেন অ্যারনসন

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

— কার্ল বিলেফেল্ড