"Stuffচ্ছিক" নির্ভরতা সহ পৃথক উপাদানগুলিতে একটি "ওয়াড অফ স্টাফ" ইউটিলিটি প্রকল্প পৃথক করা

26

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

এই লাইব্রেরির অনেক অংশই একক, এবং আলাদা প্রকল্পে বিভক্ত হতে পারে (যা আমরা ওপেন-সোর্স করতে চাই)। তবে একটি বড় সমস্যা রয়েছে যা এগুলি পৃথক গ্রন্থাগার হিসাবে প্রকাশের আগে সমাধান করা দরকার। মূলত, এই লাইব্রেরির মধ্যে আমি "alচ্ছিক নির্ভরতা" বলতে পারি তার প্রচুর এবং প্রচুর মামলা রয়েছে ।

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

এই লাইব্রেরির প্রত্যেকটি সম্পূর্ণ একা একা ব্যবহৃত হতে পারে তবে সেগুলি যদি একসাথে ব্যবহার করা হয় তবে দরকারী অতিরিক্ত বৈশিষ্ট্যগুলি থাকতে হবে। উদাহরণস্বরূপ, উভয় CommandLineParserএবং XmlClassifyপোস্ট-বিল্ড চেকিং কার্যকারিতা প্রকাশ করে যা প্রয়োজন PostBuildCheck। একইভাবে, CommandLineParserপ্রয়োজনীয় রঙিন স্ট্রিং আক্ষরিক ব্যবহার করে অপশন ডকুমেন্টেশন সরবরাহ করার অনুমতি দেয় ConsoleColoredStringএবং এটি অনুবাদযোগ্য ডকুমেন্টেশনগুলির মাধ্যমে সমর্থন করে Lingo।

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

এই "ইউটিলি" লাইব্রেরির মধ্যে দিয়ে আমি দেখতে পাচ্ছি যে প্রায় সমস্ত সম্ভাব্য পৃথকযোগ্য লাইব্রেরিতে এমন suchচ্ছিক বৈশিষ্ট্য রয়েছে যা এগুলি অন্যান্য লাইব্রেরিতে বেঁধে রাখে। যদি আমি আসলে সেই লাইব্রেরিগুলিকে নির্ভরতা হিসাবে প্রয়োজন হয় তবে স্টাফের এই ওয়াডটি সত্যিকার অর্থেই শৃঙ্খলাবদ্ধ নয়: আপনি যদি কেবল একটি ব্যবহার করতে চান তবে আপনাকে মূলত সমস্ত লাইব্রেরি প্রয়োজন require

.NET- এ এই জাতীয় ?চ্ছিক নির্ভরতা পরিচালনার জন্য কি কোনও প্রতিষ্ঠিত পন্থা রয়েছে?

.net dependencies modules

— রোমান স্টারকভ
সূত্র

2

এমনকি লাইব্রেরিগুলি একে অপরের উপর নির্ভরশীল, তবুও তাদের সুসংগত তবে পৃথক গ্রন্থাগারগুলিতে পৃথক করার কিছু সুবিধা থাকতে পারে, যার প্রতিটিটিতে বিস্তৃত কার্যকারিতা রয়েছে।

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

20

ধীরে ধীরে রিফ্যাক্টর।

এটি সম্পূর্ণ হতে কিছুটা সময় নেবে বলে আশা করুন এবং আপনি আপনার ইউটিলস সমাবেশটি পুরোপুরি সরিয়ে নেওয়ার আগে বেশ কয়েকটি পুনরাবৃত্তির মাধ্যমে ঘটতে পারে ।

সামগ্রিক পদ্ধতি:

প্রথমে কিছুটা সময় নিন এবং এই কাজটি সম্পন্ন হওয়ার পরে আপনি কীভাবে এই ইউটিলিটি সমাবেশগুলি দেখতে চান তা ভেবে দেখুন। আপনার বিদ্যমান কোড সম্পর্কে খুব বেশি চিন্তা করবেন না, শেষ লক্ষ্যটি ভাবেন। উদাহরণস্বরূপ, আপনি এটি করতে ইচ্ছুক হতে পারেন:
- মাইকম্পানি. ইউটিলিটিস.কোর (অ্যালগোরিদম, লগিং ইত্যাদি ধারণ করে)
- মাইকম্পানি. ইউটিলিটিস.ইউআই (অঙ্কন কোড ইত্যাদি)
- মাইকম্পানি. ইউটিলিটিস.ইউআই উইনফর্মস (সিস্টেম. উইন্ডোজ.ফর্মগুলি সম্পর্কিত কোড, কাস্টম নিয়ন্ত্রণ, ইত্যাদি)
- MyCompany.Utilities.UI.WPF ( ডাব্লুপিএফ -সম্পর্কিত কোড, এমভিভিএম বেস ক্লাস)।
- মাইকম্পানি. ইউটিলিটিস.সরিয়ালাইজেশন (সিরিয়ালাইজেশন কোড)।
এই প্রতিটি প্রকল্পের জন্য খালি প্রকল্প তৈরি করুন এবং যথাযথ প্রকল্পের রেফারেন্স তৈরি করুন (UI রেফারেন্স কোর, UI.Winforms রেফারেন্স UI), ইত্যাদি
আপনার ইউটিস অ্যাসেম্বলি থেকে নিম্ন টার্গেটযুক্ত ফলের (শ্রেণি বা পদ্ধতিগুলি যা নির্ভরতা সম্পর্কিত সমস্যায় ভোগেনা) কোনওটি নতুন টার্গেট অ্যাসেমব্লিতে স্থানান্তরিত করুন।
কঠোরদের নিয়ে কাজ শুরু করার জন্য আপনার ইউটিস অ্যাসেমব্লিকে বিশ্লেষণ শুরু করতে এনডিপেন্ড এবং মার্টিন ফাউলারের রিফ্যাক্টরিংয়ের একটি অনুলিপি পান । দুটি কৌশল যা সহায়ক হবে:
- অনেক ক্ষেত্রে আপনাকে ইন্টারফেস, প্রতিনিধি বা ইভেন্টগুলির মাধ্যমে নিয়ন্ত্রণ বিপরীত করতে হবে ।
- আপনার "alচ্ছিক" নির্ভরতাগুলির ক্ষেত্রে নীচে দেখুন।

Lingচ্ছিক ইন্টারফেস হ্যান্ডলিং

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

প্রথমে আপনার মূল সমাবেশে সাধারণ ইন্টারফেসগুলি সংজ্ঞায়িত করুন:

উদাহরণস্বরূপ, IStringColorerইন্টারফেসটি দেখতে পাবেন:
```
 namespace MyCompany.Utilities.Core.OptionalInterfaces
 {
     public interface IStringColorer
     {
         string Decorate(string s);
     }
 }
```

তারপরে, বৈশিষ্ট্য সহ সমাবেশে ইন্টারফেসটি প্রয়োগ করুন। উদাহরণস্বরূপ, StringColorerশ্রেণিটি দেখতে হবে:

using MyCompany.Utilities.Core.OptionalInterfaces;
namespace MyCompany.Utilities.Console
{
    class StringColorer : IStringColorer
    {
        #region IStringColorer Members

        public string Decorate(string s)
        {
            return "*" + s + "*";   //TODO: implement coloring
        }

        #endregion
    }
}

এমন একটি PluginFinder(বা সম্ভবত ইন্টারফেসফিন্ডারের ক্ষেত্রে আরও ভাল নাম) শ্রেণি তৈরি করুন যা বর্তমান ফোল্ডারে ডিএলএল ফাইলগুলি থেকে ইন্টারফেসগুলি খুঁজে পেতে পারে। এখানে সরল উদাহরণ রয়েছে। প্রতি @ এডউডককের পরামর্শ (এবং আমি সম্মত), যখন আপনার প্রকল্পগুলি বৃদ্ধি পাবে আমি আরও নির্ভরশীল "আমাকে সন্ধান করুন" এর সাথে আরও দৃ implementation় বাস্তবায়নের জন্য উপলভ্য ইনজেকশন ইনজেকশন ফ্রেমওয়ার্কগুলির মধ্যে একটি ( সাধারণ iv ক্য এবং স্প্রিংয়ের সাথে সাধারণ সেরিবাস লোকেশন মনে রাখবেন না) ব্যবহার করার পরামর্শ দেব would বৈশিষ্ট্যটি "ক্ষমতাগুলি, অন্যথায় পরিষেবা লোকেটার প্যাটার্ন হিসাবে পরিচিত । আপনার প্রয়োজন অনুসারে আপনি এটি পরিবর্তন করতে পারেন।
```
using System;
using System.Linq;
using System.IO;
using System.Reflection;

namespace UtilitiesCore
{
    public static class PluginFinder
    {
        private static bool _loadedAssemblies;

        public static T FindInterface<T>() where T : class
        {
            if (!_loadedAssemblies)
                LoadAssemblies();

            //TODO: improve the performance vastly by caching RuntimeTypeHandles

            foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
            {
                foreach (Type type in assembly.GetTypes())
                {
                    if (type.IsClass && typeof(T).IsAssignableFrom(type))
                        return Activator.CreateInstance(type) as T;
                }
            }

            return null;
        }

        private static void LoadAssemblies()
        {
            foreach (FileInfo file in new DirectoryInfo(Directory.GetCurrentDirectory()).GetFiles())
            {
                if (file.Extension != ".DLL")
                    continue;

                if (!AppDomain.CurrentDomain.GetAssemblies().Any(a => a.Location == file.FullName))
                {
                    try
                    {
                        //TODO: perhaps filter by certain known names
                        Assembly.LoadFrom(file.FullName);
                    }
                    catch { }
                }
            }
        }
    }
}
```

শেষ অবধি, FindInterface পদ্ধতিতে কল করে আপনার অন্যান্য সমাবেশগুলিতে এই ইন্টারফেসগুলি ব্যবহার করুন। এখানে একটি উদাহরণ CommandLineParser:

static class CommandLineParser
{
    public static string ParseCommandLine(string commandLine)
    {
        string parsedCommandLine = ParseInternal(commandLine);

        IStringColorer colorer = PluginFinder.FindInterface<IStringColorer>();

        if(colorer != null)
            parsedCommandLine = colorer.Decorate(parsedCommandLine);

        return parsedCommandLine;
    }

    private static string ParseInternal(string commandLine)
    {
        //TODO: implement parsing as desired
        return commandLine;
    }

}

সর্বাধিক গুরুত্বপূর্ণ: প্রতিটি পরিবর্তনের মধ্যে পরীক্ষা, পরীক্ষা, পরীক্ষা।

— কেভিন ম্যাককর্মিক
সূত্র

আমি উদাহরণ যোগ! :-)

— কেভিন ম্যাককর্মিক 20

1

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

— এড জেমস

@ এডউডকক গুড পয়েন্ট এড, এবং আমি বিশ্বাস করতে পারি না যে আমি এটি লেখার সময় সার্ভিস লোকেটার প্যাটার্নটির কথা ভাবিনি। প্লাগইন ফাইন্ডার অবশ্যই একটি অপরিপক্ক বাস্তবায়ন এবং একটি ডিআই ফ্রেমওয়ার্ক অবশ্যই এখানে কাজ করবে।

— কেভিন ম্যাককর্মিক 15

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

— রোমান স্টারকভ

@ রামকিনস তাহলে আপনি কোন পথে যাচ্ছেন? যেমন আছে তেমনি রেখে দিচ্ছি? :)

— সর্বোচ্চ

5

আপনি অতিরিক্ত লাইব্রেরিতে ঘোষিত ইন্টারফেসগুলি ব্যবহার করতে পারেন।

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

এটি এমইএফ-এর সাথে বিশেষত করা সহজ, কারণ এটি পাঠ্যপুস্তক এটির জন্য ব্যবহার করে।

এটি আপনাকে গ্রন্থাগারগুলি n + 1 dll এ বিভক্ত করার মূল্যে সংকলন করার অনুমতি দেবে।

আছে HTH।

— লুই কোটম্যান
সূত্র

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

— রোমান স্টারকভ

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

— রোমান স্টারকভ

2

আমি ভেবেছিলাম যে আমি এখন পর্যন্ত নিয়ে আসা সবচেয়ে কার্যকর বিকল্পটি পোস্ট করব, চিন্তাভাবনাগুলি কী তা দেখার জন্য।

মূলত, আমরা প্রতিটি উপাদান শূন্য উল্লেখ সহ একটি লাইব্রেরিতে পৃথক করতাম; যে সমস্ত কোডের জন্য একটি রেফারেন্স দরকার #if/#endifতা যথাযথ নাম সহ একটি ব্লকে স্থাপন করা হবে । উদাহরণস্বরূপ, CommandLineParserযে হ্যান্ডলগুলির কোডগুলি ConsoleColoredString.োকানো হত #if HAS_CONSOLE_COLORED_STRING।

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

একটি রেফারেন্স যোগ CommandLineParserকরারConsoleColoredString
প্রকল্প ফাইলটিতে HAS_CONSOLE_COLORED_STRINGসংজ্ঞা যুক্ত CommandLineParserকরুন।

এটি প্রাসঙ্গিক কার্যকারিতা উপলব্ধ করে তুলবে।

এটি নিয়ে বেশ কয়েকটি সমস্যা রয়েছে:

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

বরং সুন্দর-সুন্দর, তবুও, আমরা সামনে এলাম এটিই সবচেয়ে কাছের।

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

— রোমান স্টারকভ
সূত্র

1

আমি নেট থেকে ব্রাউনফিল্ড অ্যাপ্লিকেশন ডেভলপমেন্ট বইটি সুপারিশ করতে যাচ্ছি । দুটি সরাসরি প্রাসঙ্গিক অধ্যায় 8 এবং 9. অধ্যায় 8 আপনার অ্যাপ্লিকেশনটিকে রিলেয়ার করার বিষয়ে কথা বলছে, যখন 9 তম অধ্যায়টি টেমিং নির্ভরতা, নিয়ন্ত্রণের বিপরীতমুখীকরণ এবং পরীক্ষার উপরে এর প্রভাব সম্পর্কে কথা বলে about

— Tangurena
সূত্র

1

সম্পূর্ণ প্রকাশ, আমি জাভা লোক। সুতরাং আমি বুঝতে পারছি আপনি সম্ভবত যে প্রযুক্তিগুলি এখানে উল্লেখ করবেন তা সন্ধান করছেন না। তবে সমস্যাগুলি একই, তাই সম্ভবত এটি আপনাকে সঠিক দিকে নির্দেশ করবে।

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

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

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

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

— cwash
সূত্র

0

সম্ভবত জন লাকোসের "বৃহত আকারের সি ++ সফটওয়্যার ডিজাইন" বইটি দরকারী (অবশ্যই সি # এবং সি ++ বা একই নয় তবে আপনি বইটি থেকে দরকারী কৌশলগুলি ডিস্টিল করতে পারেন)।

মূলত, পুনরায় ফ্যাক্টর করুন এবং দুটি বা ততোধিক লাইব্রেরি ব্যবহার করে এমন কার্যকারিতাটি এই লাইব্রেরির উপর নির্ভর করে একটি পৃথক উপাদান হিসাবে সরান। প্রয়োজনে অস্বচ্ছ ধরণের মতো কৌশল ব্যবহার করুন etc.

— ক্যাস্পার ভ্যান ডেন বার্গ
সূত্র