কৌশলের সাথে টেমপ্লেট পদ্ধতির সংমিশ্রণ


14

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

  • যেভাবে কোনও পদক্ষেপের ফলাফলটি পরিচালনা করা হয়
  • যেভাবে গেমের শেষটি নির্ধারিত হয়
  • যেভাবে বিজয়ী নির্ধারিত হয়

এটি নকশা করার জন্য আমার মনে যে প্রথম জিনিসটি এসেছিল তা হ'ল কৌশল বিন্যাসটি ব্যবহার করা, আমার অ্যালগরিদমে (গেমের আসল নিয়ম) এর একটি প্রকরণ রয়েছে। নকশাটি দেখতে দেখতে এটির মতো হতে পারে: এখানে চিত্র বর্ণনা লিখুন

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

আমি তখন এটি নিয়ে এসেছি: এখানে চিত্র বর্ণনা লিখুন

প্রতিটি গেম (মানকালা, ওয়ারী, কালাহ, ...) কেবল প্রতিটি নিয়মের ইন্টারফেসের ধরণের বৈশিষ্ট্যযুক্ত থাকে, WinnerDeterminerএবং যদি কোনও ম্যানচালা ২.০ সংস্করণ থাকে তবে বিজয়ী কীভাবে নির্ধারণ করা হয় তা ব্যতীত মানচালা ১.০ এর সমান মানকালা সংস্করণ ব্যবহার করুন।

আমি মনে করি কৌশল বিধি হিসাবে এই বিধিগুলির বাস্তবায়ন অবশ্যই বৈধ। তবে আসল সমস্যাটি তখনই আসে যখন আমি এটিকে আরও ডিজাইন করতে চাই।

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

  • গর্তগুলিতে পাথর জমা করুন (এটি সমস্ত গেমের জন্য একই, সুতরাং এটি টেমপ্লেট পদ্ধতিতে প্রয়োগ করা হবে)
  • পদক্ষেপের ফলাফল নির্ধারণ করুন
  • আগের পদক্ষেপের কারণে গেমটি শেষ হয়েছে কিনা তা নির্ধারণ করুন
  • গেমটি শেষ হয়ে গেলে, কে জিতেছে তা নির্ধারণ করুন

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

আমি সত্যিই কৌশল প্যাটার্ন এবং এই মধ্যে নকশা পার্থক্য দেখতে না? তবে আমি নিশ্চিত যে আমার একটি টেম্পলেট পদ্ধতি ব্যবহার করা দরকার (যদিও আমি কৌশল প্যাটার্নটি ব্যবহারের বিষয়ে ঠিক তেমন নিশ্চিত ছিলাম)।

আমি TurnTemplateবস্তুটি তৈরির জন্য কে দায়ী হবে তাও নির্ধারণ করতে পারছি না , কৌশল কৌশল অনুসারে আমার মনে হয়েছে যে আমার কাছে অবজেক্টগুলির পরিবার রয়েছে (তিনটি বিধি) যা আমি সহজেই একটি বিমূর্ত কারখানার নিদর্শন ব্যবহার করে তৈরি করতে পারি। আমার তখন একটি MancalaRuleFactory, WariRuleFactoryইত্যাদি ছিল এবং তারা নিয়মের সঠিক দৃষ্টান্ত তৈরি করে এবং আমাকে কোনও RuleSetবস্তু ফিরিয়ে দেয় ।

ধরা যাক যে আমি কৌশলটি + বিমূর্ত কারখানার প্যাটার্নটি ব্যবহার করি এবং আমার কাছে এমন একটি RuleSetআইটেম রয়েছে যা এতে তিনটি নিয়মের জন্য অ্যালগরিদম রয়েছে। আমি এখনও এটির সাহায্যে টেমপ্লেট পদ্ধতির প্যাটার্নটি ব্যবহার করতে পারি বলে মনে হয় কেবলমাত্র এটি RuleSetআমার কাছে এই অবজেক্টটি পাস করা TurnTemplate। তারপরে 'সমস্যা' যে সমস্যাগুলি হ'ল তা হ'ল আমার কংক্রিট বাস্তবায়নের দরকার হবে না TurnTemplate, এই শ্রেণিগুলি অচল হয়ে উঠবে। আমার সুরক্ষিত পদ্ধতিতে TurnTemplateআমি কেবল কল করতে পারি ruleSet.determineWinner()। ফলস্বরূপ, TurnTemplateক্লাসটি আর বিমূর্ত হবে না তবে কংক্রিট হয়ে উঠতে হবে, এটি কি এখনও একটি টেম্পলেট পদ্ধতির প্যাটার্ন?

সংক্ষেপে বলি, আমি কি সঠিক উপায়ে চিন্তা করছি বা খুব সহজ কিছু মিস করছি? যদি আমি সঠিক পথে থাকি, তবে আমি কীভাবে কৌশল প্যাটার্ন এবং একটি টেম্পলেট পদ্ধতি প্যাটার্নটি একত্রিত করব?


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

" ... মনকালা ও ওয়ারির খেলায় বিজয়ী যেভাবে নির্ধারিত হয় ঠিক একইরকম এবং কোডটি নকল হবে। " কেন কোডটি নকল করে বোঝায়? উভয় শ্রেণীর একই ফাংশন কল করতে দিন।
ডি ড্রিমার

উত্তর:


6

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

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

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

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

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


যেহেতু আপনি উল্লেখ করেছেন যে আপনি একজন ছাত্র, তাই আমি একটি সফটওয়্যার ডিজাইন কোর্সের জন্য টিএ থাকাকালীন সময়ে কয়েকটি জিনিস ভাগ করে নিতে চাই:

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

দুর্দান্ত পরামর্শের জন্য ধন্যবাদ, বিশেষত আপনার এই ব্যপারটি সম্পর্কে যে বিষয়টি অ্যাবস্ট্রাকশনের ভুল স্তরে ছিল তা সম্পর্কে point আমি এখন এটিকে GameTemplateএমনভাবে পরিবর্তন করেছি যা অনেক বেশি ভাল অনুভব করে। এটি আমাকে খেলোয়াড়, বোর্ড ইত্যাদি প্রারম্ভিক করার জন্য একটি কারখানার পদ্ধতি একত্রিত করার অনুমতি দেয়
মেকসওয়াল

3

আপনার বিভ্রান্তি ন্যায়সঙ্গত। জিনিসটি হ'ল নিদর্শনগুলি পারস্পরিক একচেটিয়া নয়।

টেমপ্লেট পদ্ধতি কৌশল এবং স্টেটের মতো অন্যান্য ধাঁচগুলির একগুচ্ছের ভিত্তি। মূলত, কৌশল ইন্টারফেসে এক বা একাধিক টেম্পলেট পদ্ধতি রয়েছে, প্রত্যেকটিতে একটি কৌশল প্রয়োগকারী সমস্ত জিনিসকে (কমপক্ষে) একটি ডুএक्शन () পদ্ধতির মতো কিছু করার প্রয়োজন হয়। এটি কৌশলগুলি একে অপরের প্রতিস্থাপনের অনুমতি দেয়।

জাভাতে, একটি ইন্টারফেস টেম্পলেট পদ্ধতির সেট ছাড়া কিছুই নয়। তেমনি, কোনও বিমূর্ত পদ্ধতি মূলত একটি টেম্পলেট পদ্ধতি। এই নিদর্শনটি (অন্যদের মধ্যে) ভাষাটির ডিজাইনারদের কাছে ভাল জানা ছিল, তাই তারা এটিকে তৈরি করেছিলেন।

@ থমাস ওভেনস আপনার বিশেষ সমস্যাটির কাছে যাওয়ার জন্য দুর্দান্ত পরামর্শ দেয়।


0

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


2
যদিও আমি সাধারণভাবে আপনার সাথে একমত , এটি সত্যই কোনও উত্তর নয় যা ওপির সমস্যা সমাধান করে। "এটি করবেন না" একটি উত্তর, তবে এটি যদি একটি কার্যকর বিকল্প সরবরাহ না করে তবে একটি বরং দরিদ্র।
ইয়ানিস

@YannisRizos এবং যখন আমি একমত আপনি পাশাপাশি, আমি এখনও মনে করি তিনি শব্দ পরামর্শ দিয়েছেন (অথবা অন্তর্দৃষ্টি যদি পরামর্শ সঠিক শব্দ নয়)। যে কারণে, +1। যদিও, হ্যাঁ এটি প্রযুক্তিগতভাবে খুব কার্যকর উত্তর নয়।
কিনেছে 777

-1

আসুন ব্রাস টিকে নেমে আসি। কোনও গেম ইন্টারফেস, ডিজাইনের কোনও নিদর্শন, কোনও বিমূর্ত ক্লাস এবং কোনও ইউএমএলের কোনও প্রয়োজন নেই need

আপনার যদি ইউআই, সিমুলেশন এবং যেমন কিছু সমর্থন ক্লাস থাকে, তবে মূলত আপনার সমস্ত অ-গেম-লজিক-নির্দিষ্ট কোড যাইহোক পুনরায় ব্যবহার করা হবে। তদুপরি, আপনার ব্যবহারকারী গতিশীলভাবে তার গেমটি পরিবর্তন করে না। আপনি গেমসের মধ্যে 30Hz এ ফ্লিপ করবেন না। আপনি প্রায় আধা ঘন্টা একটি খেলা খেলেন। সুতরাং আপনার "গতিশীল" বহুত্ববাদ আসলে গতিশীল নয় not এটি বরং স্থির।

সুতরাং এখানে যাওয়ার বুদ্ধিমান উপায় হ'ল জেনেরিক ফাংশনাল অ্যাবস্ট্রাকশন যেমন সি # 'র Actionবা সি ++' এর মতো ব্যবহার করা std::function, একটি মানকালা, একটি ওয়ারি এবং একটি কালাহ শ্রেণি তৈরি করা এবং সেখান থেকে যাওয়া।

std::unordered_map<std::string, std::function<void()>> games = {
    { "Kalah", [] { return Kalah(); } },
    { "Mancala", [] { return Mancala(); } },
    { "Wari", [] { return Wari(); } }
};
void play() {
    std::function<void()> f;
    f = games[GetChoiceFromUI()];
    f();
    if (PlayAgain()) return play();
}
int main() {
    play();
}

সম্পন্ন.

আপনি গেমস কল করবেন না। গেমস আপনাকে কল করে।


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

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

4
সফটদেভে একটি উদ্বেগজনক / বিরক্তিকর প্রবণতা রয়েছে যেখানে ব্যবহার করা ডিজাইনের ধরণগুলি কেবলমাত্র সমস্যা সমাধানের চেয়ে আরও গুরুত্বপূর্ণ হিসাবে বিবেচিত হয়। ওভার ইঞ্জিনিয়ারিংয়ের মতো জিনিস রয়েছে।
জেমস 0

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

2
আমার পুরো জীবন আমি সবসময় ভেবেছিলাম এটি "ব্রাস ট্যাক্স" ... বাহ, "ব্রাস ট্যাক্স" আরও অর্থবোধ তৈরি করে। lol
777
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.