আপনি যদি কখনও রেলে রুবি ব্যবহার করে থাকেন তবে আপনি সম্ভবত উদ্বেগের ধারণাটি জুড়ে এসেছেন। যখনই আপনি একটি নতুন রেল প্রকল্প জাম্পস্টার্ট করেন, আপনি adirectory পাবেন app/controllers/concerns এবং app/models/concerns . কিন্তু উদ্বেগ কি? এবং কেন রেল সম্প্রদায়ের লোকেরা মাঝে মাঝে তাদের সম্পর্কে খারাপ কথা বলে?

দ্রুত ওভারভিউ

একটি Rails Concern হল যে কোনও মডিউল যা ActiveSupport::Concern প্রসারিত করে মডিউল আপনি জিজ্ঞাসা করতে পারেন — কীভাবে উদ্বেগগুলি মডিউল থেকে এত আলাদা? প্রধান পার্থক্য হল রেলের উদ্বেগগুলি আপনাকে কিছুটা যাদু করতে দেয়, যেমন:

# app/models/concerns/trashable.rb
 
module Trashable
  extend ActiveSupport::Concern
 
  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end
 
  def trash
    update_attribute :trashed, true
  end
end

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

class Song < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  # ...
end

এই সময়ে বেশ সহজ এবং নিষ্পাপ, তাই না? মডেলটি কিছুটা ওজন হারিয়েছে এবং ট্র্যাশিং এখন অন্য মডেলগুলিতে পুনঃব্যবহার করা যেতে পারে, শুধু আমাদের গানের মডেল নয়৷ ওয়েল, জিনিসগুলি জটিল হতে পারে৷ আসুন খুঁজে বের করার জন্য ডুব দেওয়া যাক।

মিক্সিনের একটি ক্লাসিক উদাহরণ

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

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

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

আমার কাছে সব আছে

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

আমরা যদি Trashable দেখি আরও একবার:

module Trashable
  extend ActiveSupport::Concern
 
  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end
 
  def trash
    update_attribute :trashed, true
  end
end

উদ্বেগের যুক্তি নির্ভর করে যে trashed উদ্বেগ অন্তর্ভুক্ত যেখানেই ক্ষেত্র বিদ্যমান. ঠিক? কোন বড় কথা নয়, আমরা আফটারওল এটাই চাই। কিন্তু, আমি যা দেখছি তা হল লোকেরা মডেল থেকে উদ্বেগের মধ্যে অন্যান্য জিনিস টানতে প্রলুব্ধ হয়। এটি কীভাবে ঘটতে পারে তার একটি ছবি আঁকার জন্য, আসুন কল্পনা করি যে Song মডেলের আরেকটি পদ্ধতি আছে featured_authors :

class Song < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  def featured_authors
    authors.where(featured: true)
  end
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  def featured_authors
    authors.where(featured: true)
  end
 
  # ...
end

আরও ভালভাবে ব্যাখ্যা করার জন্য, আমি একটি Album যোগ করেছি মডেল যেটিতে Trashableও রয়েছে .তাহলে বলি আমরা গান এবং অ্যালবামের বৈশিষ্ট্যযুক্ত লেখকদের ট্র্যাশ করা হলে তাদের অবহিত করতে চাই৷ লোকেরা এই যুক্তিটিকে উদ্বেগের ভিতরে রাখতে প্রলুব্ধ হবে:

module Trashable
  extend ActiveSupport::Concern
 
  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end
 
  def trash
    update_attribute :trashed, true
 
    notify(featured_authors)
  end
 
  def notify(authors)
    # ...
  end
end

ঠিক এখানে, জিনিসগুলি কিছুটা জটিল হতে শুরু করেছে। যেহেতু আমাদের গানের মডেলের বাইরে ট্র্যাশিং লজিক আছে, তাই আমরা Trashable-এ বিজ্ঞপ্তি দেওয়ার জন্য প্রলুব্ধ হতে পারি উদ্বেগ সেখানে, কিছু "ভুল" ঘটে। featured_authors Song থেকে নেওয়া হয়েছে মডেল. ঠিক আছে, ধরা যাক এই পাসপুল রিকুয়েস্ট রিভিউ এবং সিআই চেক।

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

class Song < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  def featured_authors
    authors.where(featured: true).where(region: 'Europe')
  end
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  # ...
end

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

এখানে যেটি ঝুঁকিপূর্ণ তা হল উদ্বেগ (মিক্সিন) যে মডেলটি অন্তর্ভুক্ত করে সে সম্পর্কে অনেক কিছু জানে। এটিকে বলা হয় বৃত্তাকার নির্ভরতা . Song এবং Album নির্ভর করে Trashable ট্র্যাশ করার জন্য, Trashable featured_authors এর জন্য উভয়ের উপর নির্ভর করে সংজ্ঞা trashed এর ক্ষেত্রেও একই কথা বলা যেতে পারে Trashable থাকার জন্য উভয় মডেলেই ফিল্ডের অস্তিত্ব থাকা প্রয়োজন উদ্বেগ কাজ করছে।

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

আপনারা সবাই কোথা থেকে এসেছেন

আমাদের Trashable ফিরে দেখছি বিজ্ঞপ্তি দিয়ে, আমাদের এটি সম্পর্কে কিছু করতে হবে৷ উদ্বেগগুলি ব্যবহার করার সময় আরেকটি জিনিস যা ঘটে তা হল আমরা অতিরিক্ত শুষ্ক জিনিসগুলি করার প্রবণতা রাখি৷ আসুন এটি করার চেষ্টা করি, প্রদর্শনের উদ্দেশ্যে, আমাদের বিদ্যমান মডেলগুলিতে অন্য একটি উদ্বেগ তৈরি করে (আমার সাথে সহ্য করুন) এই এক):

module Authorable
  has_many :authors
 
  def featured_authors
    authors.where(featured: true)
  end
end

তারপর, আমাদের Song এবং Album এই মত দেখাবে:

class Song < ApplicationRecord
  include Trashable
  include Authorable
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
  include Authorable
 
  # ...
end

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

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

 
# Concerns
module Trashable
  extend ActiveSupport::Concern
 
  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end
 
  def trash
    update_attribute :trashed, true
  end
end
 
module Authorable
  has_many :authors
 
  # Other useful methods that relate to authors across models.
  # If there are none, ditch the concern.
end
 
# Models
class Song < ApplicationRecord
  include Trashable
  include Authorable
 
  def featured_authors
    authors.where(featured: true).where(region: 'Europe')
  end
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
  include Authorable
 
  def featured_authors
    authors.where(featured: true)
  end
 
  # ...
end

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

দ্য ফাইনাল বস

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

কোডের স্ক্রিনশট দেখে, আপনি হয় আপনার মুখ খুলছেন না হয় ভয়ে। আমি মনে করি এখানে এর মাঝে নেই। যদি আমি এই কোডটি সম্পাদনা করার সুযোগ পাই তবে আমি এটিকে "ফাইনাল কনসার্ন বস ফাইট" হিসাবে কল্পনা করব। কিন্তু মজার পাশাপাশি, মজার বিষয় হল এখানে এমন মন্তব্য রয়েছে যা বলে যে কোনটি কোনটির উপর নির্ভর করে। একবার দেখুন:

  # ...
 
  include Subscribable # Depends on Readable
  include Eventable    # Depends on Recordables
 
  # ...

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

ডিএইচএইচ আলোচনার ভিতরে মন্তব্যে এইরকম কিছু ভাগ করেছে৷ ভিতরের একটি প্রতিক্রিয়া টুইট জিজ্ঞাসা করে যে এই কোডবেসের সাথে কাজ করা লোকেরা কীভাবে এই জাতীয় উদ্বেগের সাথে যোগাযোগ করবে৷ DHH উত্তর দেয় যে তাদের কাছে খুব বেশি লিখিত নথি নেই, তারা খুব কমই নিয়োগ করে তাই তাদের দল এগুলোর সাথে ভালভাবে পরিচিত।

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

উপসংহার

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

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

কোন সমাধান নিখুঁত নয়, এবং আমি আশা করি আপনি ব্লগ পোস্টে কাজ করার উপায় সম্পর্কে রেলের উদ্বেগ বুঝতে পেরেছেন। সর্বদা হিসাবে, আপনার বিচার ব্যবহার করুন এবং সুবিধা এবং অসুবিধা সম্পর্কে সচেতন হন।

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

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