রেল প্যাটার্নস এবং অ্যান্টি-প্যাটার্নে রুবির ভূমিকা

রুবি অন রেল প্যাটার্নস এবং অ্যান্টি-প্যাটার্ন সম্পর্কে আমাদের সিরিজের প্রথম পোস্টে স্বাগতম। প্রতিটি পোস্টে, আমরা রেল অ্যাপগুলির সাথে কাজ করার সময় আপনি যে সমস্ত ধরণের প্যাটার্নগুলি দেখতে পাবেন সেগুলির মধ্যে গভীরভাবে ডুব দেব৷

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

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

হ্যাঁ, আপনি একজন ডিজাইনার

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

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

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

একটি ডিজাইন প্যাটার্ন কি?

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

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

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

পরবর্তীতে, সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ে ডিজাইন প্যাটার্নগুলি 1994 সালে প্রকাশিত কিংবদন্তি বই ডিজাইন প্যাটার্নস-এর গ্যাং অফ ফোর-এর পরে বৃহত্তর শ্রোতাদের কাছে বিখ্যাত হয়ে ওঠে। বইটিতে, বর্তমানে ব্যবহৃত নিদর্শনগুলির ব্যাখ্যা এবং সংজ্ঞা রয়েছে- ফ্যাক্টরি, সিঙ্গেলটন, ডেকোরেটর, শুধুমাত্র নামের জন্য। কিছু।

দুর্দান্ত, এখন আমরা ডিজাইন এবং প্যাটার্ন সম্পর্কে আমাদের জ্ঞানকে পরিচিত বা রিফ্রেশ করেছি, আসুন অ্যান্টি-প্যাটার্নগুলি কী তা খুঁজে বের করি৷

একটি ডিজাইন এন্টি-প্যাটার্ন কি?

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

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

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

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

এই জিনিসগুলি ঘটে এবং ঘটবে। ভাল ছেলেরা খারাপ কেনাকাটা করে, এবং এর বিপরীতে। কিন্তু রুবি এবং রেল এই ছবিতে কোথায় ফিট করে?

রুবি প্রথমে, তারপর রেল

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

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

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

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

MVC:রেলের রুটি এবং মাখন

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

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

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

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

কিন্তু এত ব্যাপকভাবে ব্যবহৃত প্যাটার্নে সেখানে অ্যান্টি-প্যাটার্ন কী আছে? চলুন MVC প্যাটার্নের প্রতিটি অংশের জন্য কিছু সাধারণ অ্যান্টি-প্যাটার্নের উপর নজর রাখি।

মডেল সমস্যা

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

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

class Song < ApplicationRecord
  belongs_to :album
  belongs_to :artist
  belongs_to :publisher
 
  has_one :text
  has_many :downloads
 
  validates :artist_id, presence: true
  validates :publisher_id, presence: true
 
  after_update :alert_artist_followers
  after_update :alert_publisher
 
  def alert_artist_followers
    return if unreleased?
 
    artist.followers.each { |follower| follower.notify(self) }
  end
 
  def alert_publisher
    PublisherMailer.song_email(publisher, self).deliver_now
  end
 
  def includes_profanities?
    text.scan_for_profanities.any?
  end
 
  def user_downloaded?(user)
    user.library.has_song?(self)
  end
 
  def find_published_from_artist_with_albums
    ...
  end
 
  def find_published_with_albums
    ...
  end
 
  def to_wav
    ...
  end
 
  def to_mp3
    ...
  end
 
  def to_flac
    ...
  end
end

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

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

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

অনুগামী এবং প্রকাশককে অবহিত করে এমন কলব্যাকগুলি কাজের জন্য বের করা যেতে পারে। কাজগুলি সারিবদ্ধ হবে এবং যুক্তিগুলিকে মডেলের বাইরে রাখা হবে, যেমন:

class NotifyFollowers < ApplicationJob
  def perform(followers)
    followers.each { |follower| follower.notify }
  end
end
 
class NotifyPublisher < ApplicationJob
  def perform(publisher, song)
    PublisherMailer.song_email(publisher, self).deliver_now
  end
end

মডেল থেকে দূরে আলাদা প্রক্রিয়ায় চাকরিগুলি নিজেরাই চলবে৷ এখন আপনি আলাদাভাবে আপনার কাজের যুক্তি পরীক্ষা করতে পারেন এবং আপনার মডেল থেকে সঠিক কাজটি সারিবদ্ধ হয়েছে কিনা তা পরীক্ষা করতে পারেন৷

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

class SongDecorator < Draper::Decorator
  delegate_all
 
  def includes_profanities?
    object.text.scan_for_profanities.any?
  end
 
  def user_downloaded?(user)
    object.user.library.has_song?(self)
  end
end

তারপর, আপনি কল করবেন decorate আপনার কন্ট্রোলারে, উদাহরণস্বরূপ:

def show
  @song = Song.find(params[:id]).decorate
end

এবং এটিকে আপনার মতামতের মত ব্যবহার করুন:

<%= @song.includes_profanities? %>
<%= @song.user_downloaded?(user) %>

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

module SongFinders
  def find_published_from_artist_with_albums
    ...
  end
 
  def find_published_with_albums
    ...
  end
end
 
module SongConverter
  def to_wav
    ...
  end
 
  def to_mp3
    ...
  end
 
  def to_flac
    ...
  end
end

গানের মডেলটি SongFinders প্রসারিত করবে মডিউল, তাই এর পদ্ধতিগুলি ক্লাস পদ্ধতি হিসাবে উপলব্ধ। গানের মডেলে SongConverter অন্তর্ভুক্ত থাকবে মডিউল, তাই এর পদ্ধতিগুলি মডেল দৃষ্টান্তে উপলব্ধ।

এই সমস্ত কিছু আমাদের গানের মডেলটিকে বেশ পাতলা করে তুলতে হবে:

class Song < ApplicationRecord
  extend SongFinders
  include SongConverter
 
  belongs_to :album
  belongs_to :artist
  belongs_to :publisher
 
  has_one :text
  has_many :downloads
 
  validates :artist_id, presence: true
  validates :publisher_id, presence: true
 
  after_update :alert_artist_followers, if: :published?
  after_update :alert_publisher
 
  def alert_artist_followers
    NotifyFollowers.perform_later(self)
  end
 
  def alert_publisher
    NotifyPublisher.perform_later(publisher, self)
  end
end

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

সমস্যা দেখুন

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

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

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

নিয়ন্ত্রক সমস্যা

রেল কন্ট্রোলাররাও বিভিন্ন সমস্যায় ভুগতে পারে। তাদের মধ্যে একটি ফ্যাট কন্ট্রোলার অ্যান্টি-প্যাটার্ন।

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

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

উপসংহার

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

পরেরটা পর্যন্ত, চিয়ার্স!

পি.এস. আপনি যদি রুবি ম্যাজিক পোস্টগুলি প্রেস থেকে বের হওয়ার সাথে সাথে পড়তে চান তবে আমাদের রুবি ম্যাজিক নিউজলেটারে সাবস্ক্রাইব করুন এবং একটি পোস্ট মিস করবেন না!