ফাংশনাল প্রোগ্রামিং কি GoF ডিজাইনের ধরণগুলি প্রতিস্থাপন করে?


1046

যেহেতু আমি গত বছর F # এবং OCaml শিখতে শুরু করেছি, তাই আমি প্রচুর নিবন্ধ পড়েছি যেগুলি জোর দিয়েছিল যে ডিজাইনের ধরণগুলি (বিশেষত জাভাতে) অপরিহার্য ভাষাগুলিতে নিখোঁজ বৈশিষ্ট্যগুলির জন্য কার্যকারিতা। আমার পাওয়া একটি নিবন্ধ মোটামুটি দৃ claim় দাবি করেছে :

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

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

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

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

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


18
আপনি স্টিভ ইয়েজের লেখাটি দেখতে পারেন (স্টিভ-ইয়েজ.ব্লগস্পট.com/ 2006/ 03/ )
রাল্ফ

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

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

3
@ আর.বারজেল এই "পর্যাপ্ত উচ্চ স্তরের অপরিহার্য ভাষা" কী? ধন্যবাদ।
সিবারসিটিজেন 1

5
উচ্চতর অর্ডার ফাংশন এবং বেনামী ফাংশনগুলির জন্য সমর্থন সহ @ সিবারসিটিজেন 1 হাঁস-টাইপ করা ভাষা। এই বৈশিষ্ট্যগুলি প্রচুর পরিমাণে শক্তি সরবরাহ করে যা অনেকগুলি ডিজাইনের নিদর্শন সরবরাহ করে।
আর বারজেল

উত্তর:


1075

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

তবে এটি সঠিক যে বেশিরভাগ ওওপি-নির্দিষ্ট নকশার ধরণগুলি কার্যকরী ভাষায় বেশ অপ্রাসঙ্গিক।

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

এই সমস্যা সম্পর্কে এখানে গ্যাং অফ ফোরের বক্তব্যটি এখানে রয়েছে:

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

(উপরেরটি ডিজাইন প্যাটার্নস বইয়ের পৃষ্ঠা 4, অনুচ্ছেদ 3 এর পরিচিতির একটি উদ্ধৃতি)

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

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

তাই হ্যাঁ, বেশিরভাগ জিওএফ ডিজাইনের নিদর্শনগুলি এফপি ভাষাগুলিতে নিরঙ্কুশভাবে উপস্থাপন করা হয়েছে, কারণ আরও শক্তিশালী এবং সহজ বিকল্পগুলির উপস্থিতি রয়েছে।

তবে অবশ্যই এখনও নকশার নিদর্শন রয়েছে যা এফপি ভাষার দ্বারা সমাধান করা হয় না solved সিঙ্গেলনের এফপি সমতুল্য কত? (এক মুহুর্তের জন্য অবহেলা করা যে সিলেটলেটগুলি সাধারণত ব্যবহারের জন্য একটি ভয়ানক নিদর্শন))

এবং এটি উভয় উপায়েও কাজ করে। যেমনটি আমি বলেছি, এফপির ডিজাইনের ধরণগুলিও রয়েছে; লোকেরা সাধারণত তাদের এ জাতীয় মনে করে না।

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

"একটি স্ট্যাটিক পরিবর্তনশীল বাড়ায়" জন্য, বা "যে সকেট থেকে পড়া", কারণ এটি আপনি শুধু কি আমরা একটি নকশা প্যাটার্ন প্রয়োজন হবে না কি

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

(খাঁটি) কার্যকরী ভাষায়, পার্শ্ব প্রতিক্রিয়া এবং পরিবর্তনীয় স্থিতি অসম্ভব, যদি না আপনি মনোড "ডিজাইন প্যাটার্ন", বা একই জিনিসকে অনুমতি দেওয়ার জন্য অন্য কোনও পদ্ধতির সাথে কাজ করে না।

অতিরিক্ত হিসাবে, কার্যকরী ভাষায় যা ওওপি সমর্থন করে (যেমন এফ # এবং ওসিএএমএল), এটি আমার কাছে স্পষ্ট বলে মনে হয় যে এই ভাষাগুলি ব্যবহার করে প্রোগ্রামাররা অন্যান্য ওওপি ভাষার জন্য উপলব্ধ একই নকশার নিদর্শনগুলি ব্যবহার করবে use আসলে, এখনই আমি প্রতিদিন F # এবং OCaml ব্যবহার করি এবং জাভাতে লেখার সময় আমি যে ভাষা ব্যবহার করি সেগুলি বনাম এই ভাষাগুলিতে আমি যে প্যাটার্নগুলি ব্যবহার করি তার মধ্যে কোনও উল্লেখযোগ্য পার্থক্য নেই।

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

তবে আরেকটি সম্ভাবনা হতে পারে যে আপনি কেবল বুঝতে পারেন নি যে আপনি সমস্যাগুলি ন্যূনতমভাবে সমাধান করছেন যা একটি OOP ভাষায় নকশার নিদর্শনগুলির প্রয়োজন হবে।

আপনি যখন কার্চিং ব্যবহার করেন, বা অন্যের পক্ষে যুক্তি হিসাবে কোনও ফাংশনটি পাস করেন, তখন থামুন এবং কীভাবে আপনি ওওপি ভাষায় এটি করবেন তা ভাবুন।

ফাংশনাল প্রোগ্রামিং ওওপি ডিজাইনের নিদর্শনগুলির প্রয়োজনীয়তা বাদ দেয় এমন দাবি করার কোনও সত্যতা কি আছে?

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

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


যেমনটি প্রত্যাশা করা হয়েছিল, কিছু লোক আমার নকশার ধরণগুলির সংজ্ঞাটিকে "একটি ভাষায় ত্রুটিগুলি বাছাই করা" হিসাবে আপত্তি জানিয়েছিল, তাই আমার ন্যায়সঙ্গততা এখানে:

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

কেন বিমূর্ত কারখানার প্যাটার্ন এফপিতে বিদ্যমান নেই? কারণ এটি যে সমস্যাটি সমাধান করার চেষ্টা করে তা সেখানে বিদ্যমান নেই।

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


73
নকশার নিদর্শনগুলি মৌলিক সমস্যার সাধারণ সমাধান বর্ণনা করে। তবে প্রোগ্রামিং ভাষা এবং প্ল্যাটফর্মগুলি এটিই করে। সুতরাং আপনি যখন ভাষা এবং প্ল্যাটফর্মগুলি ব্যবহার করছেন তা পর্যাপ্তর না হয়ে আপনি নকশার ধরণগুলি ব্যবহার করেন।
yfeldblum

135
এস.লোট: তারা প্রদত্ত ভাষায় বিদ্যমান সমস্যাগুলির সমাধানগুলি বর্ণনা করে, হ্যাঁ। এফপি ভাষায় কোনও কমান্ড ডিজাইনের প্যাটার্ন নেই, কারণ এটি যে সমস্যার সমাধান করার চেষ্টা করে তা বিদ্যমান নেই। যার অর্থ হ'ল তারা এমন সমস্যাগুলি সমাধান করে যা ভাষা নিজেই সমাধান করতে পারে না। এটি হ'ল ভাষাতে ত্রুটিগুলি
jalf

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

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

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

151

ফাংশনাল প্রোগ্রামিং ওওপি ডিজাইনের নিদর্শনগুলির প্রয়োজনীয়তা বাদ দেয় এমন দাবি করার কোনও সত্যতা কি আছে?

ক্রিয়ামূলক প্রোগ্রামিং অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ের মতো নয়। অবজেক্ট-ওরিয়েন্টেড ডিজাইন নিদর্শনগুলি কার্যকরী প্রোগ্রামিংয়ের ক্ষেত্রে প্রযোজ্য না। পরিবর্তে, আপনার কার্যকরী প্রোগ্রামিং ডিজাইনের ধরণ রয়েছে।

ক্রিয়ামূলক প্রোগ্রামিংয়ের জন্য, আপনি ওও ডিজাইনের প্যাটার্ন বইগুলি পড়বেন না; আপনি এফপি ডিজাইনের ধরণগুলিতে অন্য বই পড়বেন।

ভাষা অজ্ঞানী

সম্পূর্ণ না। ওও ভাষাগুলির প্রতি সম্মান সহ শুধুমাত্র ভাষা-অজ্ঞাতনামা। নকশার ধরণগুলি মোটেই প্রক্রিয়াকরণী ভাষাতে প্রযোজ্য না। তারা সবেমাত্র একটি সম্পর্কিত ডেটাবেস ডিজাইনের প্রসঙ্গে বোঝায়। স্প্রেডশিট ডিজাইন করার সময় এগুলি প্রয়োগ হয় না।

একটি সাধারণ ওওপি ডিজাইনের ধরণ এবং এর কার্যকরী সমতুল্য?

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

ওও ডিজাইন থেকে কার্যকরী ডিজাইনে কোনও সাধারণ ম্যাপিং নেই। তারা সমস্যাটি দেখার খুব ভিন্ন উপায়।

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

নকশা নিদর্শন - একটি ধারণা হিসাবে - প্রযুক্তি বা সমস্যা ডোমেন নির্বিশেষে বিল্ডিংয়ের একটি নিরবধি উপায়। তবে নির্দিষ্ট সমস্যা ডোমেন এবং প্রযুক্তিগুলিতে নির্দিষ্ট নকশার ধরণগুলি প্রয়োগ হয়।

তারা যা করছে সে সম্পর্কে যারা চিন্তা করেন তারা ডিজাইনের নিদর্শনগুলি উদঘাটন করবেন।


12
এমভিসি ওও ডিজাইন নয়। এটি স্থাপত্য নকশা - এই প্যাটার্নটি বেশ বিস্তৃতভাবে প্রযোজ্য app
এসলট

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

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

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

2
সমাপ্ত বাক্যটির জন্য +1। ডিজাইনের নিদর্শনগুলি প্রোগ্রামিংকে সহজতর করা এবং ফলস্বরূপ প্রোগ্রামগুলিকে আরও দক্ষ করে তোলা, যা তারা করার তাগিদ দ্বারা বোঝানো হয়।
ক্রমানুসারে

46

ভাষা এবং প্যাটার্নের মধ্যে শক্ত যোগসূত্র সম্পর্কে ব্রায়ানের মন্তব্যগুলি মূলত:

এই আলোচনার অনুপস্থিত অংশটি হ'ল প্রতিমাগুলির ধারণা। জেমস ও কোপলিনের বই "অ্যাডভান্সড সি ++" এখানে বিশাল প্রভাব ফেলেছিল। তিনি নাম ছাড়াই ক্রিস্টোফার আলেকজান্ডার এবং কলাম আবিষ্কার করার অনেক আগে (এবং আপনি আলেকজান্ডার না পড়েই নিদর্শন সম্পর্কে সংবেদনশীলতার সাথে কথা বলতে পারবেন না), তিনি সত্যই কোন ভাষা শেখার ক্ষেত্রে আইডিয়ামগুলিতে দক্ষতা অর্জনের গুরুত্ব সম্পর্কে কথা বলেছেন। তিনি সি হিসাবে স্ট্রিং কপিটি উদাহরণ হিসাবে ব্যবহার করেছিলেন, while(*from++ = *to++);আপনি এটিকে অনুপস্থিত ভাষার বৈশিষ্ট্য (বা গ্রন্থাগারের বৈশিষ্ট্য) জন্য বান্দাইদ হিসাবে দেখতে পারেন, তবে আসলে কী বিষয়টি গুরুত্বপূর্ণ তা হ'ল এটি যে কোনও একটির চেয়ে চিন্তার বা ভাবের বৃহত একক unit এর অংশগুলি

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

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


8
ধন্যবাদ! এই নিদর্শনগুলি হ'ল জ্ঞানীয় বোঝা হ্রাস করার জন্য "ধারণাগত চঞ্চক"।
র্যান্ডাল শুল্জ

এবং কার্যকরী মনাদ অবশ্যই এই আলোচনার অন্তর্ভুক্ত।
গ্রেগ

@ র্যান্ডালশুল্জ: ভাষার বৈশিষ্ট্যগুলি (এবং অবশ্যই তাদের মুশকিল ব্যবহার) "জ্ঞানীয় বোঝা কমিয়ে ধারণাগত ছাঁটাই" বিভাগে ভালভাবে ফিট করতে পারে।
রায় টিঙ্কার 18

39

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


34

পিটার নরভিগের ডায়নামিক প্রোগ্রামিংয়ে নকশার প্যাটার্নগুলির এই সাধারণ থিমটির চিন্তাশীল কভারেজ রয়েছে, যদিও 'কার্যকরী' পরিবর্তে 'গতিশীল' ভাষা সম্পর্কে (ওভারল্যাপ রয়েছে)।


26

এই বিষয়টি আলোচনা করে এখানে অন্য লিঙ্কটি দেওয়া হয়েছে: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

এডওয়ার্ড তার ব্লগে পোস্টে হাস্কেলের ক্ষেত্রে সমস্ত 23 টি মূল জিওএফ নিদর্শন বর্ণনা করেছেন।


4
নিবন্ধটি হাস্কেলটিতে সত্যই নকশার নিদর্শনগুলি দেখায় বলে মনে হচ্ছে না, তবে হাসকেল কীভাবে নিদর্শনগুলি ছাড়াই এই প্রয়োজনগুলিকে সম্বোধন করবে তা দেখান।
ফ্রেশিয়েবল

3
@ ফ্রেশইবল: আপনার নিদর্শনগুলির সংজ্ঞা উপর নির্ভর করে। কোনও তালিকার উপরে কোনও ফাংশন ম্যাপিং কি ভিজিটর প্যাটার্নের বৈকল্পিক? আমি সাধারণত ভেবেছি উত্তরটি "হ্যাঁ" ছিল। প্যাটার্নগুলি নির্দিষ্ট সিনট্যাক্সের বাইরে যাওয়ার কথা। প্রয়োগ করা ফাংশনটি কোনও অবজেক্ট হিসাবে মোড়ানো বা কোনও ফাংশন পয়েন্টার হিসাবে পাস হতে পারে তবে ধারণাটি আমার কাছে একই। আপনি একমত না?
এসএমএম 21

20

আপনি যখন "ডিজাইনের ধরণগুলি" (সাধারণভাবে) এবং "এফপি বনাম ওওপি" এর স্তরের দিকে এটি দেখার চেষ্টা করেন, আপনি যে উত্তরগুলি খুঁজে পাবেন সেটি সর্বোপরি নরম হবে।

যদিও উভয় অক্ষের উপরে আরও গভীরতর হন এবং নির্দিষ্ট নকশার ধরণ এবং নির্দিষ্ট ভাষার বৈশিষ্ট্য এবং জিনিসগুলি আরও স্পষ্ট হয়ে উঠুন consider

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

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

(একদিকে: এখানে আমি লিখেছিলাম একটি সাম্প্রতিক ব্লগ , যা এফপি এবং ডিজাইনের নিদর্শনগুলিতে আরও আলোচনার অন্যান্য লিঙ্কগুলি রয়েছে))


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

22
হ্যাঁ, তবে এটি এমন একটি প্যাটার্ন থেকে পরিবর্তিত হয়েছে যা আপনি ডিজাইন ধারণা যা আপনি কোনও বইয়ে পড়েন এবং আপনার কোডটিতে "স্রেফ কোড" এ প্রয়োগ করেন। অর্থাৎ, "ইউনিয়নের ধরণ এবং প্যাটার্ন ম্যাচিং ব্যবহার করুন" ঠিক তেমনই আপনি কীভাবে কোনও ভাষায় স্টাফ কোড করেন। (সাদৃশ্য: যদি কোনও ভাষার forলুপ না থাকে এবং সেগুলি কেবল whileলুপগুলি থাকে তবে "জন্য" একটি পুনরাবৃত্তি প্যাটার্ন হতে পারে But তবে যখন forভাষাটি কেবল কোনও ভাষা দ্বারা সমর্থিত এবং মানুষ কীভাবে সাধারণভাবে কোড করে, তখন এটি কোনও নিদর্শন নয় - আপনি ডন ' টির জন্য একটি প্যাটার্ন দরকার, এটি কেবল কোড, ম্যান
ব্রায়ান

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

1
ব্রায়ান: আমি মনে করি আমাদের "প্যাটার্ন" এর আলাদা আলাদা সংজ্ঞা রয়েছে। আমি কোনও শনাক্তযোগ্য নকশার বিমূর্তিটিকে একটি প্যাটার্ন হিসাবে বিবেচনা করি, যখন আপনি কেবল অ-সুস্পষ্ট বিমূর্তিটিকেই একটি নিদর্শন বলে মনে করেন । কেবল সি # এর কারণ foreachএবং হাস্কেলের mapMঅর্থ এই নয় যে তাদের কাছে আইট্রেটার প্যাটার্ন নেই। আমি এটা বলতে কোনও সমস্যা দেখতে পাচ্ছি না যে IEnumerable<T>সি # তে জেনেরিক ইন্টারফেস এবং হাস্কেলের টাইপক্লাস হিসাবে ইটেটর প্যাটার্নটি প্রয়োগ করা হয়েছে Traversable
গ্যাবে

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

16

নরভিগের উপস্থাপনাটি তারা সমস্ত জিওএফ নিদর্শনগুলির বিশ্লেষণকে প্রমাণ করে এবং তারা বলে যে 23 টির মধ্যে 16 টি কার্যকরী ভাষায় সহজ বাস্তবায়ন করেছে বা কেবল ভাষার অংশ ছিল of সুতরাং সম্ভবতঃ তাদের মধ্যে কমপক্ষে সাতটি হয় ক) সমান জটিল বা খ) ভাষায় উপস্থিত ছিল না। দুর্ভাগ্য আমাদের জন্য, তারা গণনা করা হয় না!

আমি মনে করি এটি স্পষ্ট যে GoF- এ বেশিরভাগ "সৃজনশীল" বা "কাঠামোগত" নিদর্শন জাভা বা সি ++ এ আদিম টাইপ সিস্টেমগুলি পেতে চান তা করার জন্য কেবল কৌশল are আপনি যে কোন ভাষাতে প্রোগ্রাম করেন না কেন তবে বাকীগুলি বিবেচনার যোগ্য।

একটি প্রোটোটাইপ হতে পারে; এটি জাভাস্ক্রিপ্টের মৌলিক ধারণা হলেও এটি অন্য ভাষায় স্ক্র্যাচ থেকে প্রয়োগ করতে হবে।

আমার প্রিয় নিদর্শনগুলির মধ্যে একটি হ'ল নাল অবজেক্ট প্যাটার্ন: কোনও বস্তুরূপে এমন কোনও কিছুর অনুপস্থিতি প্রতিনিধিত্ব করে যা উপযুক্ত ধরণের কিছুই করে না। এটি কার্যকরী ভাষায় মডেল করা আরও সহজ হতে পারে। যাইহোক, আসল অর্জনটি দৃষ্টিভঙ্গিতে পরিবর্তন the


2
জিওএফ নিদর্শনগুলি শ্রেণিভিত্তিক ওওপি ভাষাগুলির জন্য বিশেষভাবে নকশা করা হয়েছিল, তাই কী কী অদ্ভুত বিশ্লেষণ করতে হবে। পাইপ রেনচগুলি বৈদ্যুতিক কাজ করার জন্য ভাল কিনা তা বিশ্লেষণ করার মতো মনে হয়।
munificent

@ মুখ্য: সত্য নয়। অবজেক্ট-ওরিয়েন্টেশন বহুরূপী সরবরাহ করে; ফাংশনাল প্রোগ্রামিং সাধারণত পলিমারফিজম সরবরাহ করে।
মার্সিন

@ মার্কিন একটি ওও প্রোগ্রামার অর্থ একটি কার্যকরী প্রোগ্রামারের তুলনায় পলিমারফিজম দ্বারা খুব আলাদা কিছু।
অ্যান্ড্রুসি

পছন্দ করুন ওও প্রোগ্রামার মনে করতে পারে যে তারা কিছু আলাদা বোঝায় তবে তারা তা করে না।
মার্সিন

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

15

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


আমি পুরোপুরি হারিয়ে গেছি। বিমূর্ততা সহ কিছু আপ করতে ... এর অর্থ কী?
tuinstoel

2
আপনি ম্যাক্রো ছাড়াই ডোমেন নির্দিষ্ট বিমূর্ততা (এমনকি এম্বেড করাও) তৈরি করতে পারেন। ম্যাক্রো কেবল কাস্টম বাক্য গঠন যুক্ত করে আপনাকে এগুলি সুন্দর করতে দেয়।
জন হ্যারোপ

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

9

এমনকি ওও ডিজাইনের প্যাটার্ন সমাধানগুলি ভাষা নির্দিষ্ট।

ডিজাইনের নিদর্শনগুলি এমন সাধারণ সমস্যার সমাধান যা আপনার প্রোগ্রামিং ভাষাটি আপনার জন্য সমাধান করে না। জাভাতে, সিঙ্গলটন প্যাটার্নটি এক-এর-কিছু (সরলিকৃত) সমস্যার সমাধান করে।

স্কালায় আপনার ক্লাস ছাড়াও অবজেক্ট নামে একটি শীর্ষ স্তরের কনস্ট্রাক্ট রয়েছে। এটি অলসভাবে তাত্ক্ষণিকভাবে রয়েছে এবং কেবল একটিই আছে। আপনাকে সিঙ্গলটন পেতে সিঙ্গলটন প্যাটার্ন ব্যবহার করতে হবে না। এটি ভাষার অংশ।


8

প্যাটার্নগুলি অনুরূপ সমস্যাগুলি সমাধান করার উপায় যা বারবার দেখা যায় এবং তারপরে বর্ণিত ও ডকুমেন্টেড হয়। সুতরাং না, এফপি নিদর্শনগুলি প্রতিস্থাপন করবে না; তবে, এফপি নতুন প্যাটার্ন তৈরি করতে পারে এবং কিছু বর্তমান "সেরা অনুশীলন" নিদর্শনগুলিকে "অপ্রচলিত" করে তুলতে পারে।


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

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

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

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

1
কয়েক বছর পর এই কথোপকথনে ফিরে ঘুরে, আমি মনে করি যে প্রচুর লোক প্যাটার্নসকে একটি নির্দিষ্ট প্রোগ্রামিং ভাষা বা একটি নির্দিষ্ট প্রোগ্রামিং দৃষ্টান্তের সাথে সংযুক্ত করে। এগুলি এ জাতীয় প্রসঙ্গে ব্যবহার করা যেতে পারে তবে প্রোগ্রামিংয়ের আগে এগুলি বিদ্যমান ছিল। "বিল্ডিংয়ের একটি নিরবধি" বিল্ডিং আর্কিটেকচার এবং সম্প্রদায় পরিকল্পনার বিষয়ে আলোচনা করে। এটি বোঝায় যে প্যাটার্ন ভিত্তিক কৌশলগুলি "ভাষার ভাষার সীমাবদ্ধতার" বাইরে ব্যবহার করা যেতে পারে যদি না আপনি বিল্ডিং নির্মাণকে প্রোগ্রামিং ভাষা বলতে চান না :)
এডউইন বাক

8

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

স্ক্যালাল কীভাবে "সিঙ্গলটন প্যাটার্ন" কে সরিয়ে দেয় তা একবার দেখুন: আপনি ক্লাসের পরিবর্তে কেবল কোনও বিষয় ঘোষণা করেন । আর একটি বৈশিষ্ট্য, প্যাটার্ন মিল, দর্শনার্থীদের প্যাটার্নের খাঁটিতা এড়াতে সহায়তা করে। এখানে তুলনা দেখুন: স্কালার প্যাটার্ন ম্যাচিং = স্টেরয়েডগুলিতে দর্শকের প্যাটার্ন

এবং স্কেল, এফ # এর মতো ওও-ক্রিয়ামূলক a আমি এফ # সম্পর্কে জানি না, তবে এতে সম্ভবত এই ধরণের বৈশিষ্ট্য রয়েছে।

বন্ধগুলি কার্যকরী ভাষায় উপস্থিত থাকে, তবে সেগুলি তাদের মধ্যে সীমাবদ্ধ করার দরকার নেই। তারা প্রতিনিধি প্যাটার্ন সাহায্য।

আরও একটি পর্যবেক্ষণ। এই কোডের এই অংশটি একটি প্যাটার্ন প্রয়োগ করে: এটি এমন একটি ধ্রুপদী এবং এটি এত মৌলিক যে আমরা সাধারণত এটি "প্যাটার্ন" হিসাবে ভাবি না, তবে এটি নিশ্চিত:

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

জাভা এবং সি # এর মতো অপরিহার্য ভাষাগুলি এটিকে মোকাবেলায় মূলত একটি কার্যকরী কাঠামো গ্রহণ করেছে: "ভবিষ্যদ্বাণী"।


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

মতামত যদি একটি ******* এর মতো হয় তবে ভাল ... বাকী উত্তরগুলি দেখুন। "আপনি ক্লাসের পরিবর্তে কেবল কোনও বস্তু ঘোষণা করুন" এতটাই সত্য, আমি স্পষ্টতই এটিকে একটি বস্তু হিসাবে আক্ষরিক বলব (যদিও ভার সিঙ্গলটন = {};)। আমি ফরচ প্যাটার্ন সম্পর্কে উল্লেখও পছন্দ করি। দুর্ভাগ্যক্রমে, দেখে মনে হচ্ছে বেশিরভাগ লোকেরা যারা এই প্রশ্নের উত্তর দিয়েছেন / মন্তব্য করেছেন তারা কার্যকরী প্রোগ্রামিং বোঝে না এবং OOP ডিজাইনের ধরণগুলির ব্যবহারকে ন্যায়সঙ্গত করবে। কংক্রিটের উদাহরণ দেওয়ার জন্য +1, আমি পারলে আরও বেশি দিতাম।
ইভান প্লেস

@ জ্যাকসবিবি আমি স্কালা / হাস্কেল সম্পর্কে মন্তব্য করতে পারব না তবে জাভাস্ক্রিপ্টে (যেমন হাইব্রিড ফাংশনাল / অপরিহার্য) অবজেক্ট আক্ষরিক বাক্য গঠন, বেনামে ফাংশন এবং প্রথম হিসাবে ফাংশনগুলি পাস করার মাধ্যমে আপনি যেভাবে অবজেক্টগুলি ঘোষণা করবেন ঠিক তেমন কোনও বয়লারপ্লেট নেই শ্রেণীর সদস্য এবং একাধিক উত্তরাধিকারকে অনুমতি দেয় (ইন্টারফেস চুক্তিগুলির প্রয়োজনীয়তা অপসারণ)।
ইভান প্লেইস

8

জিওএফ ডিজাইন প্যাটার্নস জাভা এবং সি ++ এর মতো সিমুলা 67 এর বংশধর ওও ভাষাগুলির জন্য ওয়ার্কআরউন্ড রেসিপিগুলি কোডিং করছে ।

নকশার নিদর্শন দ্বারা চিকিত্সা করা বেশিরভাগ "ইলস" এর কারণে ঘটে:

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

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

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

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

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


2
"জিওএফ ডিজাইনের প্যাটার্নগুলি ওয়ার্কআরউন্ড রেসিপিগুলি কোডিং করছে" কেবল একটি মিথ্যা বিবৃতি।
জন পিটারস

7

আমি জেরেমি গিবনসের কয়েকটি দুর্দান্ত তবে কিছুটা ঘন কাগজপত্র প্লাগ করতে চাই: "উচ্চ-অর্ডার ডেটাটাইপ-জেনেরিক প্রোগ্রাম হিসাবে নকশাগুলি" এবং "আইট্রেটারের প্যাটার্নের সারাংশ" (উভয়ই এখানে উপলভ্য: http: // www। comlab.ox.ac.uk/jeremy.gibbons/publications/ )।

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


6

টাইপ সিস্টেম না নিয়ে আপনি এই আলোচনা করতে পারবেন না।

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

এর কারণ এই বৈশিষ্ট্যগুলি ওওপি-র একই সমস্যাগুলিকে সম্বোধন করে না ... এগুলি অত্যাবশ্যক প্রোগ্রামিংয়ের বিকল্প। ওওপি-র এফপি উত্তর এমএল এবং হাস্কেলের টাইপ সিস্টেমে অন্তর্ভুক্ত ... বিশেষত প্রকার, বিমূর্ত তথ্য প্রকার, এমএল মডিউল এবং হাস্কেল টাইপক্লাসগুলি যোগ করে।

তবে অবশ্যই এখনও নকশার নিদর্শন রয়েছে যা এফপি ভাষার দ্বারা সমাধান করা হয় না। সিঙ্গেলনের এফপি সমতুল্য কত? (একক মুহূর্তের জন্য অবহেলা করা যে সিলেটলেটগুলি সাধারণত ব্যবহারের জন্য একটি ভয়ানক নিদর্শন)

টাইপচ্লাসগুলি প্রথম কাজটি হ'ল সিঙ্গেলনের প্রয়োজনীয়তা অপসারণ।

আপনি ২৩ এর তালিকায় যেতে পারেন এবং আরও কিছু সরিয়ে দিতে পারেন তবে এখনই আমার কাছে সময় নেই।


6
কীভাবে টাইপচ্লাসগুলি (ওওপি ইন্টারফেসের এফপির সমতুল্য) সিঙ্গলেটনের (গ্লোবাল স্টেটের এফপি সমতুল্য) প্রয়োজনীয়তা দূর করতে পারে?
গাবে

4

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


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

4

মূলত, হ্যাঁ !

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

এছাড়াও, এই পৃষ্ঠাগুলি (আরডিডিজাইনপ্যাটার্নসমিসিংল্যাঙ্গুয়েজ ফিচারস) একটি "প্যাটার্ন / বৈশিষ্ট্য" অনুবাদ টেবিল এবং কিছু সুন্দর আলোচনা সরবরাহ করে, যদি আপনি খনন করতে চান তবে।


3

কার্যকরী প্রোগ্রামিং ডিজাইনের নিদর্শনগুলিকে প্রতিস্থাপন করে না। নকশার নিদর্শনগুলি প্রতিস্থাপন করা যায় না।

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


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

3
যে কোনও নির্দিষ্ট প্যাটার্নটি প্রতিস্থাপনযোগ্য হতে পারে, তবে নিদর্শনগুলির ধারণাটি পারে না। মনে রাখবেন যে "প্যাটার্ন" শব্দটি স্থাপত্যের ক্ষেত্রে উদ্ভূত হয়েছিল ।
ফ্রাঙ্ক শেয়ারার

1
প্যাটার্নগুলি প্রোগ্রামিং সমস্যাগুলি সমাধান করার জন্য নয়। প্যাটার্নগুলি হল আমরা প্রোগ্রাম করার উপায়। নিদর্শনগুলির ডকুমেন্টেশন প্রোগ্রামিংয়ের সমস্যাগুলি সমাধান করতে সহায়তা করে।
Torbjørn

3
@ টরবজর্ন: ভাষা যখন আসে তখন প্যাটার্নগুলি হ'ল আমরা প্রোগ্রাম করি । প্রোগ্রামটির পছন্দসই আচরণ এবং ভাষার অন্তর্নির্মিত ক্ষমতাগুলির মধ্যে কিছু অমিলের কারণে এগুলি বিদ্যমান, যেখানে প্রয়োজনীয়তা এবং ক্ষমতাগুলি সঠিকভাবে মানচিত্র দেয় না বা অস্পষ্টভাবে ম্যাপ করে না। যদি এটি না হয় তবে কোনও প্যাটার্ন থাকত না; আপনার কাছে এমন একটি বাস্তবায়ন রয়েছে যা ঠিক কীভাবে জিনিসগুলি সম্পন্ন হয় , এবং অন্যান্য বাস্তবায়ন কার্যকরভাবে বিবেচনা করার মতো নয়।
সিএওও

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

3

"ফাংশনাল প্রোগ্রামিং প্যাটার্নস-ইন স্কেলা অ্যান্ড ক্লোজার" নামে নতুন 2013 বইয়ে লেখক মাইকেল.বি। লিন জিওএফ নিদর্শনগুলির জন্য অনেক ক্ষেত্রে প্রতিস্থাপন এবং প্রতিস্থাপনের জন্য একটি শালীন কাজ করে এবং 'লেজ পুনরাবৃত্তি', 'স্মৃতিচারণ', 'আলস্য ক্রম' ইত্যাদির মতো আরও নতুন কার্যকরী নিদর্শনগুলি নিয়েও আলোচনা করে Lin

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


3

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

বাস্তব ফাংশনাল প্রোগ্রামিংয়ের মতো কোনও রাষ্ট্রের অস্তিত্ব নেই, এটি জিওএফ নিদর্শনগুলি প্রয়োগ করার কোনও মানে হয় না। GoF ডিজাইনের ধরণগুলি একইভাবে কার্যকরী নকশার ধরণগুলি নেই। প্রতিটি কার্যকরী নকশার প্যাটার্নটি বাস্তবের বিপরীতে কৃত্রিম হয় কারণ ফাংশনগুলি গণিতের গঠন এবং বাস্তবের নয়।

ফাংশনগুলির সময় ধারণার অভাব হয় কারণ সময়টি ফাংশন পরামিতিগুলির অংশ না হয় যতক্ষণ না "ভবিষ্যতের অনুরোধগুলি" প্রসেস করা সত্যিই কঠিন করে তোলে তা যদি বর্তমান সময় যা হয় তা সর্বদা একই মূল্য ফেরত দেয় Fun হাইব্রিড ভাষাগুলি সেই ধারণাগুলিকে মিশ্রিত করে ভাষাগুলিকে বাস্তব কার্যকরী প্রোগ্রামিং ভাষা নয় not

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

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

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


2
এফপির স্টেট থাকতে পারে - কেবল কোনও গ্লোবাল, শেয়ারড বা মিউটেটেবল স্টেট নেই।
vt5491

2

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

এইচএফের নীতিমালার অর্থ হ'ল ফাংশনগুলি অন্যান্য ফাংশনের পক্ষে যুক্তি হিসাবে পাস করা যেতে পারে। এবং ফাংশন মান প্রদান করতে পারে।


1

যেমন গৃহীত উত্তরটি বলেছে, ওওপি এবং এফপি সবার নিজস্ব নির্দিষ্ট নিদর্শন রয়েছে।

তবে এমন কিছু নিদর্শন রয়েছে যা এত সাধারণ যে আমি ভাবতে পারি সমস্ত প্রোগ্রামিং প্ল্যাটফর্মগুলি থাকা উচিত। এখানে একটি (অসম্পূর্ণ) তালিকা রয়েছে:

  • অ্যাডাপ্টার। আমি কার্যকরভাবে একটি কার্যকর প্রোগ্রামিং প্ল্যাটফর্মের কথা ভাবতে পারি যা এতই বিস্তৃত (এবং স্ব-পরিপূর্ণ) যে এটির সাথে বিশ্বের সাথে কথা বলার দরকার নেই। এটি যদি এটি করতে চলেছে তবে অবশ্যই একটি অ্যাডাপ্টারের প্রয়োজন।

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

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

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

  • মোনাড ট্রান্সফরমার এবং ডেকোরেটর। পূর্ববর্তীটি বিদ্যমান মোনাদে অতিরিক্ত ক্ষমতা যুক্ত করতে ব্যবহার করত, পরবর্তীকালে বিদ্যমান অবজেক্টটিতে অতিরিক্ত ক্ষমতা যুক্ত করা হয়।

1

আমি মনে করি যে প্রতিটি দৃষ্টান্ত একটি পৃথক উদ্দেশ্য পরিবেশন করে এবং সেগুলির সাথে এইভাবে তুলনা করা যায় না।

আমি শুনিনি যে GoF ডিজাইনের ধরণগুলি প্রতিটি ভাষার জন্য প্রযোজ্য। আমি শুনেছি সেগুলি সমস্ত ওওপি ভাষায় প্রযোজ্য । আপনি যদি ফাংশনাল প্রোগ্রামিং ব্যবহার করেন তবে আপনার সমস্যার সমাধানের ডোমেন ওও ভাষা থেকে আলাদা different

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


1

ওওপি এবং এফপির বিভিন্ন লক্ষ্য রয়েছে। ওওপিটির উদ্দেশ্য সফটওয়্যার উপাদানগুলির জটিলতা / চলমান অংশগুলি সজ্জিত করা এবং এফপি সফ্টওয়্যার উপাদানগুলির জটিলতা এবং নির্ভরতা হ্রাস করতে লক্ষ্য করে।

তবে এই দুটি দৃষ্টান্তগুলি অগত্যা 100% স্ববিরোধী নয় এবং উভয় বিশ্ব থেকে উপকার পেতে একসাথে প্রয়োগ করা যেতে পারে।

এমনকি এমন একটি ভাষা যা সি # এর মতো স্থানীয়ভাবে কার্যকরী প্রোগ্রামিং সমর্থন করে না, আপনি যদি এফপি নীতিগুলি বুঝতে পারেন তবে আপনি কার্যকরী কোড লিখতে পারেন। তেমনি আপনি ওওপি নীতি, নিদর্শন এবং সর্বোত্তম অনুশীলনগুলি বুঝতে পারলে আপনি F # ব্যবহার করে ওওপি নীতিগুলি প্রয়োগ করতে পারেন। আপনি যে প্রোগ্রামিং ভাষা ব্যবহার করেন না কেন আপনি পরিস্থিতি ও সমস্যার সমাধানের চেষ্টা করছেন তার ভিত্তিতে সঠিক পছন্দটি বেছে নেবেন।


1

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

বহু অভিজ্ঞতার ভাষায় (রুবি) বিকাশের আমার অভিজ্ঞতায় এফপি বাস্তবায়ন সাধারণ ক্ষেত্রে ভাল কাজ করে তবে যেখানে প্রসঙ্গটি আরও জটিল, সেখানে জিওএফ ওওপি ভিত্তিক পদ্ধতিটি আরও ভাল ফিট।

এফপি পদ্ধতি ওওপি পদ্ধতির প্রতিস্থাপন করে না, এটি এটি পরিপূরক করে।


0

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

আইএমএইচও হ'ল অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ের মূল বৈশিষ্ট্যটি হল আপনি অভ্যন্তরীণ স্থিতিযুক্ত বস্তুর সাথে প্রোগ্রামিং করছেন। খাঁটি ফাংশনে আপনার অভ্যন্তরীণ অবস্থা থাকতে পারে না - বস্তু-ভিত্তিক প্রোগ্রামিং ভাষাগুলি জিনিসগুলি করতে বিবৃতি প্রয়োজন statements (কার্যকরী প্রোগ্রামিংয়ে কোনও বক্তব্য নেই))

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


হুম, আমার লক্ষ্য করা উচিত ছিল যে উত্তর দেওয়ার আগে প্রশ্নটি এগারো বছরের পুরানো ছিল। :-)
জিম বন্যা

0

তোমাদের বন্ধনে আবদ্ধ কর.

আমাকে ডিজাইনের ধরণগুলি প্রতিস্থাপন এবং সলিড এবং ডিআরওয়াই ডিবাঙ্কড করার দাবি শুনতে শুনতে অনেকেই বাড়ে। আমি কেউ না. তবুও, আমি সঠিকভাবে সহযোগী (ম্যানুফ্যাকচারিং) আর্কিটেকচারকে মডেল করেছিলাম এবং এর জন্য কোড এবং বিজ্ঞানের পাশাপাশি অনলাইন ওয়েবসাইট তৈরির প্রক্রিয়াগুলির নিয়মগুলি আমার ওয়েবসাইট http://www.powersemantics.com/ এ প্রকাশ করেছি ।

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

  • উত্পাদন = প্রতিটি পদক্ষেপ একটি পণ্যের সাথে যোগাযোগ করে
  • ওওপি = প্রতিটি পদক্ষেপ নিজেকে এবং অন্যান্য মডিউলগুলির সাথে ইন্টারেক্ট করে, অকেজো অফিসের কর্মীদের মতো পয়েন্ট থেকে পয়েন্টে পণ্যটি পাস করে

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

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

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


0

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

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