খুচরা গেমগুলি কি "নিয়ন্ত্রণের বিপরীতমুখী" এবং "নির্ভরতা ইনজেকশন" ব্যবহার করে?

Question

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

Comments

আমি মনে করি যে এই বিশ্বের পারফরম্যান্স সর্বোপরি গুরুত্বপূর্ণ, যেহেতু আরও বেশি ব্যবহারকারী খারাপ কোডের মাধ্যমে প্রোগ্রামারদের চেয়ে কম পারফরম্যান্সের দ্বারা ক্ষতিগ্রস্থ হবেন।

— বার্ট ভ্যান হিউকেলোম

নির্ভরতা ইনজেকশনটি কোনও উপাদান-ভিত্তিক সিস্টেমের মতো শোনাচ্ছে, তবে কীভাবে কেউ নিয়ন্ত্রণের বিপরীতমুখী হবে তার উদাহরণ রয়েছে?

— এডিবি

যেহেতু এই থ্রেডটির বেশিরভাগটি আইওসি কী এবং এটি কী সমাধান করে সে সম্পর্কে ভুল তথ্য রয়েছে বলে মনে হয় এবং ওপি সত্যিই জিজ্ঞাসা করছে না যে আমি প্রথম স্থানে ভবিষ্যতের দর্শকদের জন্য এখানে নির্দেশ করব: sebaslab.com/ioc-container-unity-part-1

— বরিস ক্যালেন্স

হ্যাঁ তারা করে. প্রকৃতপক্ষে, বিরলদের কীভাবে তারা চোরের সমুদ্র - ইউটিউব . com/ watch ? v = KmaGxprTUfI& t = 1s তে তাদের পরীক্ষা বাস্তবায়ন করছে সে সম্পর্কে একটি আলোচনা ছিল । দুর্ভাগ্যক্রমে অবাস্তব ইঞ্জিনের ইনভারসন অফ কন্ট্রোল সম্পর্কে তাদের বলার মতো খুব বেশি কিছু ছিল না, তবে, আমি একটি প্রকল্প লিখেছি যা এটি দেখায় যে এটি কীভাবে কাজ করে: github.com/jimmyt1988/UE- টেস্টিং

— Jimmyt1988

Answer 1

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

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

সুতরাং, সংক্ষিপ্ত উত্তর: হ্যাঁ, তবে আপনি যেভাবে ভাবছেন তেমন নয়। কখনও কখনও, যখন আপনার বিনিময়যোগ্য আচরণের প্রয়োজন হয়, আপনি কোনও অবজেক্টটিতে কোনও কনস্ট্রাক্টরের কাছে পৌঁছে যা নতুন অবজেক্টের আচরণের অংশটি নির্ধারণ করে। এটা সম্বন্ধে.

Comments

+1 - আমি সম্মত হই যে জাভা সম্প্রদায়টি খুব সাধারণ ধারণা বলে মনে হচ্ছে যা অত্যধিক জটিল ছিল।

— ক্রিস হাও

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

— মাইক স্ট্রোবেল

@ থমাস ডুফর: পরীক্ষার ধারণা কখনই কিছু প্রমাণ করতে পারে না। এটি কেবল একটি ডাটা পয়েন্ট। এটি 100001 রানে পাস করবে তা প্রমাণ ছাড়াই আপনার 100000 বার একটি পরীক্ষার পাস হতে পারে of প্রবন্ধটি বিষয়টির যৌক্তিক বিশ্লেষণ থেকে আসে। আমি যুক্তি দিয়ে বলব যে এই আইওসি পাত্রে এবং এর মতো সংশোধনকে আরও শক্তিশালী করে তুলতে ব্যয় করে পরীক্ষা করা সহজ করা যায় এবং আমি বিশ্বাস করি যে এটি একটি খারাপ জিনিস।

— কাইলোটান

@ কাইলোটন পরীক্ষার ধারণাটি কখনই কোনও কিছু প্রমাণ করার চেষ্টা করে না । এটি প্রদর্শনের চেষ্টা করে যে প্রদত্ত ইনপুটগুলির সাথে আচরণটি প্রত্যাশার মতো হয়। যত বেশি আচরণ সঠিক হিসাবে দেখানো হয়েছে, তত বেশি আপনার বিশ্বাস যে সামগ্রিক ক্রিয়াটি সঠিক তবে এটি কখনই 100% নয়। একটি ন্যূনতম ইন্টারফেস যে কোনও কিছু প্রমাণ করে যে বিবৃতিটি হাস্যকর।

— ড্যাশ-টম-ব্যাং

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

— কাইলোটন

Answer 2

কৌশল প্যাটার্ন , রচনা , নির্ভরতা ইনজেকশন , সবই খুব ঘনিষ্ঠভাবে সম্পর্কিত।

যেহেতু কৌশল প্যাটার্নটি নির্ভরতা ইঞ্জেকশনের একটি রূপ, উদাহরণস্বরূপ আপনি যদি ইউনিটির মতো ইঞ্জিনগুলি একবার দেখে নেন তবে তারা এই নীতিটি পুরোপুরি ভিত্তি করে based উপাদানগুলির তাদের কৌশল (কৌশল প্যাটার্ন) গভীরভাবে তাদের পুরো ইঞ্জিনে এম্বেড করা হয়েছে।

উপাদানগুলির পুনরায় ব্যবহার বাদ দিয়ে অন্যতম প্রধান সুবিধা হ'ল ভয়ঙ্কর গভীর শ্রেণীর শ্রেণিবিন্যাস এড়ানো।

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

আপনার শ্রেণিবিন্যাসকে বিকশিত করুন

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

Comments

+1, আপনার হায়ারার্কি বিকশিত করা একটি দুর্দান্ত লিঙ্ক যা আমি সম্পূর্ণরূপে ভুলে গিয়েছিলাম। স্কট বিলাসের স্লাইডগুলি খুব ভাল - এর জন্য সঠিক লিঙ্কটি হ'ল ( স্কটবিলাস . com / files / 2002 / gdc_san_jose / game_objects_slides.pdf )। সম্পর্কিত আরও স্লাইডগুলির আরও একটি সেট রয়েছে তবে আমি কোথায় ভুলে

— গিয়েছি

এছাড়াও গেমারস রত্ন 5 এর নিবন্ধটি (আমার মনে হয়) বাজনে রেনে রচনা করেছেন।

— ক্রিস হাও

Answer 3

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

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

উপরের দিকে এটি স্পষ্ট যে Sprite.Loadএর উপর নির্ভরতা রয়েছে FileReader। আপনি যখন পদ্ধতিটি পরীক্ষা করতে চান আপনার নিম্নলিখিতগুলি প্রয়োজন:

1. জায়গায় একটি ফাইল সিস্টেম
2. ফাইল সিস্টেম থেকে লোড করার জন্য একটি পরীক্ষা ফাইল
3. সাধারণ ফাইল সিস্টেমের ত্রুটিগুলি ট্রিগার করার ক্ষমতা

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

আইওসি এর লক্ষ্য এটির নির্মাণ থেকে আচরণের ব্যবহারকে দ্বিগুণ করা। এটি কৌশল কৌশল থেকে কীভাবে আলাদা হয় তা নোট করুন। কৌশল প্যাটার্নের সাথে লক্ষ্যটি হ'ল আচরণের পুনর্বার ব্যবহারযোগ্য অংশকে সজ্জিত করা যাতে আপনি সহজেই ভবিষ্যতে এটি প্রসারিত করতে পারেন; কৌশলগুলি কীভাবে তৈরি করা হয় সে সম্পর্কে এটি বলার কিছুই নেই।

যদি আমরা Sprite.Loadউপরের পদ্ধতিটি পুনরায় লিখতে পারি তবে আমরা সম্ভবত এর সাথে শেষ করব:

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

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

মনে রাখবেন যে আমি আমার পুনর্খনিতে দুটি কাজ করেছি। আমি একটি ইন্টারফেস তৈরি করেছি IReaderযা কিছু আচরণকে আবদ্ধ করে তোলে - যেমন কৌশল প্যাটার্নটি প্রয়োগ করে। তদতিরিক্ত, আমি সঠিক পাঠককে অন্য শ্রেণিতে সরিয়ে দেওয়ার জন্য দায়বদ্ধ করেছি।

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

Comments

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

— Kylotan

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

— অ্যালেক্স শিকারের

আমি সন্দেহ করি অনেক লোক আইওসির বিপক্ষে কারণ এর অর্থ:

— ফ্ট্রিভিয়ার

Answer 4

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

Comments

সুনির্দিষ্টভাবে বলতে গেলে আমি এমন কোনও কোডের জন্য ভেটেবল জরিমানার বিষয়ে উদ্বিগ্ন যেগুলি অনেক বার ফ্রেম বলে called এটি নিম্ন-স্তরের বা নাও থাকতে পারে।

— দশগুণ

Answer 5

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

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

এটি একটি ধারণা যা ১৯৫০ এর দশক থেকে প্রায়। এটি সি স্ট্যান্ডার্ড লাইব্রেরিতে রয়েছে (কিউসোর্ট মাথায় আসে) এবং এটি ডেলফি এবং। নেট (ইভেন্ট হ্যান্ডলার / প্রতিনিধি) এর পুরো জায়গা জুড়ে । এটি পুরানো কোডটি পুনরায় সংকলনের প্রয়োজন ছাড়াই নতুন কোড কল করতে সক্ষম করে এবং এটি গেম ইঞ্জিনগুলিতে সর্বদা ব্যবহৃত হয়।

Comments

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

— ড্যাশ-টম-ব্যাং

Answer 6

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

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

Answer 7

আমি পেশাগত গেম দেব নই, এবং কেবল একবার সি ++ এ আইওসি প্রয়োগের চেষ্টা করেছি, সুতরাং এটি কেবল অনুমান করা হচ্ছে।

তবে আমি সন্দেহ করি গেম ডেভেলপাররা আইওসি সম্পর্কে সন্দেহজনক হবে কারণ এর অর্থ:

1 / প্রচুর ইন্টারফেস এবং প্রচুর ছোট ক্লাস ডিজাইনিং

2 / প্রতিটি ফাংশন কল ইদানীং সীমাবদ্ধ হচ্ছে

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

আমি মন্তব্যগুলিতে আগ্রহী যদি সেটির কোনও অর্থ হয় না;)