পার্লে প্রোগ্রামিং শৈলী

Question

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

সুতরাং আমার প্রশ্নটি হ'ল: পার্লের জাভা আইডিয়োমেটিকের সাথে আমি কী অবজেক্ট ভিত্তিক নিদর্শনগুলির সাথে পরিচিত, বা কার্যকর পার্ল লেখার জন্য আমার কি আমার নকশার স্টাইলে উল্লেখযোগ্য পরিবর্তন দরকার?

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

Comments

আরও গুরুতর নোটে, "পার্ল দর্শনের" জন্য গুগল অনুসন্ধান করুন এবং এখানে একবার দেখুন: পার্ল্ডিসাইনপ্যাটার্নস ডটকম

— রবার্ট হার্ভে

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

— মার্টিন ইয়র্ক

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

— টঙ্কটালাস

Answer 1

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

পার্লের বহু-দৃষ্টিকোণ প্রকৃতি শোয়ার্তজিয়ান রূপান্তরের মতো জিনিসগুলিতে দেখা যায় যা এর খুব কার্যকরী দিক রয়েছে (লিস্পে এটি "সাজসজ্জা-সাজানো-আনকোরেক্ট" নামে পরিচিত)। OOP বিদ্যমান, যেমন পদ্ধতিগত (প্রোগ্রামিংয়ের মতো সি) এবং আবশ্যকীয় ("এটি তখন এটি করুন" এর মতো বাশ)।

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

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

পার্লে নকশার নিদর্শনগুলি অন্বেষণ করার সময়, দয়া করে মার্ক ডমিনাস দ্বারা তৈরি নয় "ডিজাইন প্যাটার্নগুলি" নোট করুন ।

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

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

কিছু লাইব্রেরি উভয়ই ওওপি এবং আরও প্রচলিত ফর্মগুলিতে বিদ্যমান। দেখুন আমি কি ফাংশন-ভিত্তিক বা অবজেক্ট-ভিত্তিক সিজিআই ইন্টারফেস ব্যবহার করব? একটি পুরাতন SO প্রশ্নের জন্য যেখানে কোনওটি লাইব্রেরিটি ব্যবহার করার উপায় জিজ্ঞাসা করে।

Comments

+ 1.আরীক্ষামূলক তথ্য.এ সমস্ত বিষয় বিবেচনায় রেখে কীভাবে এসওতে অনেকগুলি পোস্ট রয়েছে যা পার্লকে একটি পুরানো ভাষা হিসাবে প্রতিরক্ষা / আক্রমণ করার চেষ্টা করছে? আমার কাছে এটি শক্তিশালী এবং দরকারী বলে মনে হচ্ছে।

— ব্যবহারকারী 10326

প্রত্যেকের নিজস্ব নিজস্ব ভাষা আছে। অনেকে মনে করেন যে এই সপ্তাহে কোনও ভাষা নতুন জিনিসকে সমর্থন করতে সক্ষম না হলে ভাষাটি পুরানো এবং পুরানো and এবং সমস্ত কিছু এখান থেকে সরিয়ে নেওয়া উচিত। অন্যদের একটি নির্দিষ্ট ভাষা শেখার ক্ষেত্রে উল্লেখযোগ্য সময় ব্যয় হয় এবং এটি যে জায়গায় হয় সেখানে এটি কীভাবে কাজ করতে হয় তা জানে। এটি সহজেই যে কোনও ভাষায় পরিবর্তিত হয় যা হট নিউ ল্যাঙ্গুয়েজের মতো দ্রুত চলে না। পার্ল 6 (যে কোনও দিন .. ভুল .. এখন বছর!) পেতে সময় লেগেছিল তখন পার্ল একটি বিশেষ ক্ষমতায়নের ভুগেন। পার্ল শেখার ক্ষেত্রে এটির কোনওটি আটকাতে হবে না - এটি অনেক জায়গায় ব্যবহৃত হয়।

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

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

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

— ডেভিডো

Answer 2

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

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

Comments

কেন অনেকে লোককে এটি একটি খারাপ ক্যারিয়ার বিকল্প হিসাবে বিবেচনা করে? মনে হয় এটি শক্তিশালী এবং টুলসেটের অংশ হিসাবে অন্যান্য ভাষার পরিপূরক করতে পারে।

— ব্যবহারকারী 10326

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

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

একটি ভাল পার্ল ওওপি

— আর্টিকেলস

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

— ম্যাট ফ্রেইক

পার্লকে আমি কখনই খারাপ ক্যারিয়ারের বিকল্প হিসাবে খুঁজে পাইনি। একটি স্থানীয় পার্ল মোনার্স গ্রুপ সন্ধান করুন এবং বৈষম্যগুলি হ'ল প্রায় প্রতিটি সভায় কেউ পার্ল চাকরির প্রারম্ভের কথা উল্লেখ করবেন।

— ডেভিডো

Answer 3

আমি একই পরিস্থিতিতে আছি, আমি দীর্ঘকাল ধরে জাভা ব্যবহার করে আসছি,

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

পার্লের সাথে আরও মনে রাখবেন এটি করার আরও একটি উপায় রয়েছে, আমি কয়েক ঘন্টা নির্দিষ্ট কোডটি দেখতে এবং এটি সংশোধন করে কাটিয়েছি, তবে শেষ পর্যন্ত এটি একটি সাধারণ বাক্য গঠন ত্রুটির সাথে কাজটি করে।

Answer 4

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

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

তাই:

package Foo; 
use Foo::Util qw(util) ;
use strict ; 

sub foo {
}

sub bar {
}

1; 

package Foo::Bar ;
use Foo ; 
use Foo::Util qw(util) ;
our @ISA = qw(Foo) ; 
use strict ; 

sub bar {
}

1; 

package Foo::Util ; 
use Exporter ; 
our @ISA = qw(Exporter) ; 
our @EXPORT = qw(util) ;
use strict ; 

sub util {
}

1;

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

উপরের উদাহরণে:

Foo::Barfoo()ক্লাস থেকে পদ্ধতি উত্পন্নFoo

Foo::Barএকটি bar()পদ্ধতি সংজ্ঞায়িত করে যাতে বহুবর্ষীয় পদ্ধতিটি bar()ক্লাস থেকে উদ্ভূত হয় নাFoo

উভয় শ্রেণীর Fooএবং Foo::Barগ্রহণ EXPORTEDফাংশন ( না পদ্ধতি ) util()প্যাকেজ (থেকে না বর্গ )Foo::Util

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

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