
প্রতিটি অ্যাপ্লিকেশনের নিজস্ব গোপন সূত্র রয়েছে, এর অস্তিত্বের কারণ। গোপন সূত্রের সংহিতাকরণ রক্ষণাবেক্ষণযোগ্য এবং সফল অ্যাপ্লিকেশন লেখার জন্য অত্যন্ত গুরুত্বপূর্ণ।
অপেক্ষা করুন। সংহিতাকরণ কী? ধৈর্য ধরুন বন্ধু, আমরা সেখানে পৌঁছাব।
প্রথমে আসুন একটি অনুমান করি:
আপনি সবেমাত্র লিড সফটওয়্যার ইঞ্জিনিয়ার পদে পদোন্নতি পেয়েছেন (অভিনন্দন!)। আপনার সিইও-এর প্রথম কাজ হল কোম্পানির জন্য একটি নতুন পণ্য তৈরি করা। এটি একটি নতুন অ্যাকাউন্টিং অ্যাপ্লিকেশন। নির্বাহীরা মনে করেন যে একটি কাস্টম অ্যাকাউন্টিং সমাধান তাদের প্রতিযোগিতায় এগিয়ে রাখবে।
কয়েক মাস কেটে গেছে, বেশিরভাগ ক্রস-কাটিং উদ্বেগ তৈরি হয়েছে (ইয়ে আপনি!)। দলটি এখন অ্যাপ্লিকেশনের সুস্বাদু অংশে মনোনিবেশ করছে: ব্যবসায়িক ডোমেইন (গোপন সূত্র)। এখানেই গোপন সূত্রের সংহিতাকরণ শুরু হয়।
সংহিতাকরণ হল ব্যবসায়িক ডোমেইনের একটি অপরিহার্য ধারণার চারপাশে কাঠামো স্থাপন করা।
অ্যাকাউন্টিংয়ে, মূল্য (P) আয় (E) অনুপাত (P/E অনুপাত) একটি কোম্পানির আয়ের পরিমাপ। একটি উচ্চ P/E অনুপাত ভবিষ্যতে উচ্চ আয় বৃদ্ধির পরামর্শ দেয়। P/E অনুপাত গণনা করা হয় প্রতি শেয়ার বাজার মূল্য (শেয়ারের দাম) কে প্রতি শেয়ার আয় (লাভ – লভ্যাংশ / বকেয়া শেয়ারের সংখ্যা) দিয়ে ভাগ করে।
একটি সহজ, এবং আমি যুক্তি দিই, নিষ্পাপ বাস্তবায়ন:
public class Metric
{
public string Name { get; set; }
public decimal Value {get; set}
public int Order {get; set;}
}
public class AccountingSummary
{
public Metric[] GetMetrics(decimal price, decimal earnings)
{
var priceEarningsRatio = price/earnings;
var priceEarningsRatioMetric = new Metric
{
Name = "P/E Ratio",
Value = priceEarningsRatio,
Order = 0
}
return new [] {priceEarningsRatioMetric};
}
}
যদি এটি শুধুমাত্র একটি জায়গায় ব্যবহৃত হয়, তাহলে এটি ঠিক আছে। আপনি যদি P/E অনুপাত অন্যান্য এলাকায় ব্যবহার করেন তাহলে কী হবে?
যেমন এখানে PriceEarnings.cs এ
var priceEarningsRatio = price/earnings;
এবং এখানে AccountSummary.cs এ
var priceEarningsRatio = price/earnings;
এবং এখানে StockSummary.cs এ
var priceEarningsRatio = price/earnings;
P/E অনুপাত এই অ্যাপ্লিকেশনের মূল অংশ, কিন্তু এটি কীভাবে বাস্তবায়িত হয়েছে, বিভিন্ন জায়গায় হার্ডকোড করা, P/E অনুপাতের গুরুত্ব কোডের সমুদ্রে হারিয়ে যায়। এটি বনের আরেকটি গাছ মাত্র।
আপনি একটি জায়গায় অনুপাত পরিবর্তন করার কিন্তু অন্য জায়গায় না করার ঝুঁকিও নিয়ে থাকেন। এটি ডাউনস্ট্রিম গণনাকে বিপর্যস্ত করতে পারে। এই ধরনের ত্রুটি খুঁজে পাওয়া কুখ্যাতভাবে কঠিন।
প্রায়শই পরীক্ষকরা ধরে নেবেন যে এটি একটি এলাকায় কাজ করলে, এটি সব এলাকায় সঠিক। অ্যাপ্লিকেশন কেন সমগ্র অ্যাপ্লিকেশনের জন্য P/E অনুপাত তৈরি করতে একই কোড ব্যবহার করবে না? এটি কি অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের মূল বিষয় নয়?
আমি কল্পনা করতে পারি এই ধরনের একটি ত্রুটি প্রোডাকশনে চলে যাওয়া এবং আপনার নির্বাহীর একটি ভিজিট পর্যন্ত আবিষ্কৃত না হওয়া যিনি জানতে চান কেন SEC-এর P/E অনুপাত গণনা কোম্পানির ফাইল করা থেকে আলাদা। এটি থাকার জন্য একটি ভাল জায়গা নয়।
আসুন আমাদের P/E অনুপাত বাস্তবায়ন পুনর্বিবেচনা করি এবং দেখি কীভাবে আমরা আমাদের প্রথম প্রচেষ্টার উন্নতি করতে পারি।
অ্যাকাউন্টিং সিস্টেমে সূত্র একটি বিষয়, আসুন একটি ইন্টারফেস যোগ করে সূত্রের চারপাশে কাঠামো স্থাপন করি:
public interface IFormula
{
decimal Calculate<T>(T model);
}
প্রতিটি সূত্র এখন এই ইন্টারফেসের সাথে বাস্তবায়িত হয় যা আমাদের সামঞ্জস্য এবং পূর্বাভাসযোগ্যতা দেয়।
আমাদের ইন্টারফেস বাস্তবায়নের পর আমাদের উন্নত P/E অনুপাত এখানে:
আমরা আমাদের Calculate পদ্ধতিতে প্রয়োজনীয় ডেটা পাস করার জন্য একটি PriceEarningsModel যোগ করেছি।
public class PriceEarningsModel
{
public decimal Price {get; set;}
public decimal Earnings {get; set;}
}
আমাদের PriceEarningsModel ব্যবহার করে, আমরা P/E অনুপাতের জন্য IFormula ইন্টারফেসের একটি বাস্তবায়ন তৈরি করেছি।
public class PriceEarningsRatioFormula : IFormula
{
public decimal Calculate<PriceEarningsModel>(PriceEarningsModel model)
{
return model.Price / model.Earnings;
}
}
আমরা এখন P/E অনুপাতকে সংহিতাবদ্ধ করেছি। এটি আমাদের অ্যাপ্লিকেশনে একটি প্রথম-শ্রেণীর ধারণা। আমরা এটি যেকোনো জায়গায় ব্যবহার করতে পারি। এটি পরীক্ষাযোগ্য, এবং একটি পরিবর্তন সমগ্র অ্যাপ্লিকেশনকে প্রভাবিত করে।
একটি অনুস্মারক হিসাবে, এখানে আমরা যে বাস্তবায়ন দিয়ে শুরু করেছিলাম:
public class Metric
{
public string Name { get; set; }
public decimal Value {get; set}
public int Order {get; set;}
}
public class AccountingSummary
{
public Metric[] GetMetrics(decimal price, decimal earnings)
{
var priceEarningsRatio = price/earnings;
var priceEarningsRatioMetric = new Metric
{
Name = "P/E Ratio",
Value = priceEarningsRatio,
Order = 0
}
return new [] {priceEarningsRatioMetric};
}
}
এটি সহজ এবং কাজটি সম্পন্ন করে। সমস্যা হল P/E অনুপাত, যা আমাদের অ্যাকাউন্টিং অ্যাপ্লিকেশনের একটি মূল ধারণা, তা আলাদা হয় না। অ্যাপ্লিকেশন বা ব্যবসায়িক ডোমেইনের সাথে পরিচিত নয় এমন ইঞ্জিনিয়াররা এর গুরুত্ব বুঝতে পারবেন না।
আমাদের উন্নত বাস্তবায়ন আমাদের নতুন P/E অনুপাত ক্লাস ব্যবহার করে। আমরা PriceEarningsRatioFormula ক্লাসটি আমাদের AccountSummary ক্লাসে ইনজেক্ট করি।
আমরা আমাদের হার্ডকোড করা P/E অনুপাতকে আমাদের নতুন PriceEarningsRatioFormula
ক্লাস দিয়ে প্রতিস্থাপন করি।
public class AccountingSummary
{
private PriceEarningsRatioFormula _peRatio;
public AccountingSummary(PriceEarningsRatioFormula peRatio)
{
_peRatio = peRatio;
}
public Metric[] GetMetrics(decimal price, decimal earnings)
{
var priceEarningsRatio = _peRatio.Calculate(new PriceEarningsModel
{
Price = price,
Earnings = earnings
});
var priceEarningsRatioMetric = new Metric
{
Name = "P/E Ratio",
Value = priceEarningsRatio,
Order = 0
}
return new [] {priceEarningsRatioMetric};
}
}
কেউ যুক্তি দিতে পারেন যে পূর্ববর্তী বাস্তবায়নের তুলনায় PriceEarningsRationFormula এর সাথে একটু বেশি কাজ আছে এবং আমি একমত হব। একটু বেশি আনুষ্ঠানিকতা আছে কিন্তু সুবিধাগুলি কোড এবং আনুষ্ঠানিকতার ছোট বৃদ্ধির জন্য যথেষ্ট মূল্যবান।
প্রথমত, আমরা সমগ্র অ্যাপ্লিকেশনের জন্য P/E অনুপাত পরিবর্তন করার ক্ষমতা অর্জন করি। আমাদের কাছে ত্রুটি দেখা দিলে ডিবাগ করার জন্য একটি একক বাস্তবায়নও রয়েছে।
সবশেষে, আমরা অ্যাপ্লিকেশনে PriceEarningsRatioFormula এর ধারণাকে সংহিতাবদ্ধ করেছি। যখন একজন নতুন ইঞ্জিনিয়ার দলে যোগ দেন, তারা জানবেন যে সূত্রগুলি অ্যাপ্লিকেশন এবং ব্যবসায়িক ডোমেইনের জন্য অপরিহার্য।
ডোমেইনকে সংহিতাবদ্ধ (এনক্যাপসুলেট) করার অন্যান্য পদ্ধতি রয়েছে, যেমন মাইক্রোসার্ভিস এবং অ্যাসেম্বলি। প্রতিটি পদ্ধতির নিজস্ব সুবিধা এবং অসুবিধা রয়েছে, আপনি এবং আপনার দল আপনার অ্যাপ্লিকেশনের জন্য কোনটি সেরা তা নির্ধারণ করতে হবে।
ক্লাস এবং ইন্টারফেসে মূল ডোমেইন ধারণাগুলি স্থাপন করা পুনঃব্যবহারযোগ্য উপাদান এবং ধারণাগত সীমানা তৈরি করে। একটি অ্যাপ্লিকেশনকে যুক্তি দিয়ে সহজ করে তোলে, ত্রুটি হ্রাস করে এবং নতুন ইঞ্জিনিয়ারদের অনবোর্ডিংয়ের বাধা কমায়।
লেখক: চাক কনওয়ে সফটওয়্যার ইঞ্জিনিয়ারিং এবং জেনারেটিভ এআই-তে বিশেষজ্ঞ। তার সাথে সোশ্যাল মিডিয়ায় যোগাযোগ করুন: X (@chuckconway) অথবা তাকে YouTube-এ দেখুন।