ওও ভাষায় যৌক্তিক পদ্ধতিগত সফ্টওয়্যারটি লেখার সবচেয়ে সহজ উপায়

Question

আমি একজন বৈদ্যুতিক প্রকৌশলী এবং আমি জানি না আমি কী করছি। আমার কোড ভবিষ্যতের রক্ষণাবেক্ষণকারীদের সংরক্ষণ করুন।

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

এগুলির জন্য প্রয়োজনীয় যুক্তিটি 2000 লাইনের কাছাকাছি। আমি অবশ্যই সমস্ত কিছু এককভাবে স্টাফ করতে চাই না main()এবং তারপরে #regionকিছু পূর্ববর্তী বিকাশকারীরা (কাঁপানো) যেমন করে এটি "ক্লিন আপ" করতে চাই ।

এখানে কিছু জিনিস আমি ইতিমধ্যে অনেক সন্তুষ্টি ছাড়াই চেষ্টা করেছি:

কার্যক্ষমতার প্রতিটি মোটা বিটের জন্য স্ট্যাটিক ইউটিলিটিগুলি তৈরি করুন, যেমন একটি ডাটাবেসইনফোজেটার, সংক্ষিপ্তসারক জেনারেটর এবং একটি মুদ্রণযুগলতা। মূল ফাংশনটি দেখতে এমনভাবে করা:

int main()
{
    var thisThing = DatabaseInfoGetter.GetThis();
    var thatThing = DatabaseInfoGetter.GetThat();
    var summary = SummaryPageGenerator.GeneratePage(thisThing, thatThing);

    PrintUtility.Print(summary);
}

একটি প্রোগ্রামের জন্য আমি এমনকি ইন্টারফেসও দিয়েছিলাম

int main()
{
    /* pardon the psuedocode */

    List<Function> toDoList = new List<Function>();
    toDoList.Add(new DatabaseInfoGetter(serverUrl));
    toDoList.Add(new SummaryPageGenerator());
    toDoList.Add(new PrintUtility());

    foreach (Function f in toDoList)
        f.Do();
}

এর কোনোটাই ঠিক মনে হয় না। কোডটি দীর্ঘ হওয়ার সাথে সাথে এই উভয় পদ্ধতিরই কুৎসিত হতে শুরু করে।

এই জাতীয় জিনিস কাঠামোর জন্য একটি ভাল উপায় কি?

Comments

আমি নিশ্চিত যে এটি কঠোরভাবে সদৃশ, কিন্তু দয়া করে পড়া am অনেক পদ্ধতি, যাতে কল করা আবশ্যক বনাম অনেক পরামিতি সঙ্গে একক পদ্ধতি ।

সম্ভবত আগ্রহের বিষয়: আপনি যদি পাঠযোগ্য এবং সহজেই রক্ষণাবেক্ষণযোগ্য কোডটি লিখে থাকেন তবে কীভাবে জানবেন?

— ড্যান পিচেলম্যান

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

— লম্বার্ড

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

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

— জর্জিও

Answer 1

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

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

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

---- পোস্টস্ক্রিপ্ট: ওও ডিজাইন ট্র্যাপস

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

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

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

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

Comments

"স্পষ্টতা" [দক্ষতার তুলনায়] এর জন্য +1 "

— স্টিফেন

আপনি কি আমাকে এমন কোনও লিঙ্কে নির্দেশ করতে পারেন যা "খারাপভাবে লিখিত OO প্রোগ্রাম" গঠন করে বা একটি সম্পাদনায় সে সম্পর্কে আরও কিছু তথ্য যুক্ত করতে পারে?

— লম্বার্ড

@ লম্বার্ড আমি এটি করেছি।

— টাইলার ডারডেন

Answer 2

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

যার কথা বলতে গিয়ে যতটা সম্ভব ক্রিয়া সম্পাদন করার পদ্ধতিগুলিকে সীমাবদ্ধ করার চেষ্টা করুন। কিছু প্রোগ্রামাররা সামান্য কম গ্রানুলারিটি পছন্দ করেন তবে বিশাল পদ্ধতিগুলি সর্বদা ক্ষতিকারক হিসাবে বিবেচিত হয়।

আপনি যদি এখনও জটিলতার সাথে লড়াই করে থাকেন তবে সম্ভবত আপনার প্রোগ্রামটি আরও বিচ্ছিন্ন করে দেওয়া দরকার need শ্রেণিবিন্যাসের আরও স্তর তৈরি করুন - সম্ভবত DatabaseInfoGetterকিছু অন্যান্য শ্রেণীর মতো ProductTableEntryবা অন্য কিছু উল্লেখ করা দরকার । আপনি পদ্ধতিগত কোড লিখছেন তবে মনে রাখবেন, আপনি সি # ব্যবহার করছেন এবং ওওপি জটিলতা হ্রাস করার জন্য আপনাকে প্রচুর সরঞ্জাম সরবরাহ করে, যেমন:

int main() 
{
    var thisthat = Database.GetThisThat();
}

public class ThisThatClass
{
    public String This;
    public String That;
}

public static class Database 
{
    public ThisThatClass GetThisThat()
    {
        return new ThisThatClass 
        {
            This = GetThis(),
            That = GetThat()
        };
    }

    public static String GetThis() 
    { 
        //stuff
    }
    public static String GetThat() 
    { 
        //stuff
    }

}

এছাড়াও, স্ট্যাটিক ক্লাস সম্পর্কে সতর্কতা অবলম্বন করুন। ডাটাবেস ক্লাসগুলি ভাল প্রার্থী হয় যতক্ষণ না আপনার কাছে সাধারণত একটি ডাটাবেস থাকে .. আপনি ধারণা পাবেন get

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

Answer 3

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

var summary = SummaryPageGenerator.GeneratePage(thisThing, thatThing);

এটিতে:

var summary = SummaryPageGenerator.GeneratePage(new This(DatabaseInfoGetter), new That(DatabaseInfoGetter));

এখন, এই পদ্ধতিগত কোডের এই ২,০০০+ লাইনগুলি দেখতে এবং বিভিন্ন অংশকে পৃথক শ্রেণিতে কীভাবে একত্রে ভাগ করা যায় এবং বিভিন্ন পদ্ধতিগুলিকে সেই শ্রেণিতে স্থানান্তরিত করা যায় তা নির্ধারণ করা আকর্ষণীয় হবে।
প্রতিটি শ্রেণীর সহজ এবং কেবল একটি কাজ করার দিকে মনোনিবেশ করা উচিত। এবং আমার কাছে মনে হয় যে কোডের কিছু অংশ ইতিমধ্যে সুপারক্লাসগুলির সাথে ডিল করছে, এটি কার্যত কার্যকর হওয়ার দিক থেকে খুব বড়। উদাহরণস্বরূপ, ডাটাবেসআইনফোজেটার বিভ্রান্তির উপায় বলে মনে হচ্ছে। এটি কীভাবে হচ্ছে? এটি খুব জেনেরিক লাগছে। তবুও সাম্রাজ্যপেজ জেনারেটরটি ভয়াবহভাবে নির্দিষ্ট! এবং মুদ্রণ ইউটিলিটি আবার জেনেরিক হচ্ছে।
সুতরাং, শুরু করার জন্য, আপনার ক্লাসের জেনেরিক নামগুলি এড়ানো উচিত এবং পরিবর্তে আরও নির্দিষ্ট নাম ব্যবহার করা শুরু করা উচিত। প্রিন্ট ইউটিলিটি ক্লাস, উদাহরণস্বরূপ, শিরোনাম শ্রেণি, একটি পাদলেখ শ্রেণি, একটি টেক্সটলক ক্লাস, একটি চিত্র শ্রেণি এবং সম্ভবত তারা কীভাবে প্রিন্টে প্রবাহিত হবে তা নির্দেশ করার কোনও উপায় সহ আরও একটি মুদ্রণ শ্রেণি হতে পারে llএই সব হতে পারে মুদ্রণযোগ্যতা নেমস্পেস , যদিও।
ডাটাবেসের জন্য, অনুরূপ গল্প। এমনকি যদি আপনি ডাটাবেস অ্যাক্সেসের জন্য সত্তা ফ্রেমওয়ার্ক ব্যবহার করেন তবে আপনার এটি ব্যবহার করা জিনিসগুলির মধ্যে সীমাবদ্ধ থাকা উচিত এবং এটিকে যৌক্তিক গোষ্ঠীতে বিভক্ত করা উচিত।
তবে আমি অবাক হয়েছি আপনি যদি 4 বছর পরেও এই সমস্যাটি মোকাবেলা করেন। যদি তা হয়, তবে এটি এমন একটি মানসিকতা যা "প্রক্রিয়াজাত ধারণা" থেকে দূরে এবং "অবজেক্ট ওরিয়েন্টেড কনসেপ্ট" এ পরিবর্তিত হওয়া দরকার। অভিজ্ঞতা না থাকলে যা চ্যালেঞ্জিং ...

Answer 4

আমি আমার মতামত, আপনার কোডটি পরিবর্তন করা উচিত যাতে এটি সরল, ধারাবাহিক এবং পঠনযোগ্য।

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

সরল: ঠিক যেমন একটি সার্কিট বোর্ডে বিভিন্ন টুকরা রয়েছে, প্রত্যেকটির একটি দায়বদ্ধ। কোড ছোট, সরল অংশে বিভক্ত করা উচিত।

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

পঠনযোগ্য: সংক্ষিপ্ত বিবরণগুলি ব্যবহার করবেন না যতক্ষণ না তারা সফ্টওয়্যার লক্ষ্য করে (ম্যাটনজ) লক্ষ্য করে এমন ডোমেনের মধ্যে ব্যাপকভাবে ব্যবহৃত হয় এবং পরিচিত হয়, পরিষ্কার এবং বোঝার জন্য সহজ নামগুলি পছন্দ করে।

Comments

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

— mattnz