বিভিন্ন শ্রেণিতে প্রোগ্রাম কোড এবং গ্রাফিকাল ইন্টারফেস কোডটি প্যাকেজ করার জন্য কেন এটি সেরা অনুশীলন হিসাবে বিবেচিত হয়?

Question

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

ধন্যবাদ!

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

Answer 1

আপনার শিক্ষক যে ধারণাটির কথা উল্লেখ করছেন সেটি হ'ল সংক্ষেপের পৃথকীকরণ called

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

একটি ইন্টারফেস নিয়ন্ত্রণ কেবল যা বলা হয়েছে তা আঁকার সাথে সম্পর্কিত হওয়া উচিত, গ্রিড যুক্তি কেবল গ্রিডের মধ্যে কী তা আঁকতে হবে তা নিয়ে নয়।

এটা কি সাহায্য করে ?

Comments

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

এই বিচ্ছিন্নতার একটি ইতিবাচক প্রভাবটি হ'ল, আপনাকে নিজের গেমের যুক্তিটি নতুন করে লিখতে হবে না, যদি আপনি উদাহরণস্বরূপ আপনার গুই প্রতিস্থাপন করতে চান

@ জন - আপনার নকশাটি কল্পনা করার প্রয়োজন হলে একটি স্পেসিফিকেশন ডকুমেন্ট লিখুন। আপনি যদি এটি বর্ণনা করতে পারেন, আপনি গেমিক যুক্তি থেকে গ্রাফিকাল ইন্টারফেস কোড পৃথক করা শুরু করতে পারেন।

— রামহাউন্ড

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

— ডোনাল ফেলো

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

— পিটার রুওয়েল

Answer 2

আপনার কোড পরিবর্তন করা সহজ করার জন্য । আগামীকাল যদি আপনি গ্রিড ছাড়াও একটি তালিকা ব্যবহার করতে চান না তবে কী হবে? আপনার জিইউআই আপনার যুক্তি থেকে পৃথক হয়ে গেলে এটি করা সহজ।

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

এটি আপনাকে এমন কোড দেয় যা পড়া সহজ। যদি আপনার গ্রিডটি কেবল জিইআইআই কার্যকারিতা করে তবে আপনার কোড বোঝা বা পরিবর্তন করা সহজ ।

Answer 3

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

যে কারণে গ্রিডে প্রদর্শিত ডেটার সাথে সম্পর্কিত গ্রিড এবং কোড প্রদর্শনের জন্য দায়বদ্ধ এমন কোড আলাদা করা আরও ভাল।

Answer 4

উদ্বেগ পৃথককরণ যখন কোনও অ্যাপ্লিকেশন কাঠামোর সাথে প্রয়োগ করা হয়, ফলাফলটি বহু-স্তরের আর্কিটেকচার (বা এন-টিয়ার আর্কিটেকচার) http://en.wikedia.org/wiki/Multitier_architecture ।

Answer 5

অন্যান্য উত্তরগুলি তৈরি করতে এবং আপনাকে একটি উদাহরণ দেওয়ার জন্য আপনার নিজের যুক্তি / ডেটা আপনার গ্রিডে বা তার বিপরীতে ইনজেক্ট করার অনুমতি দেওয়া উচিত।

আপনার গ্রিড নিয়ন্ত্রণটি কোনও Renderপদ্ধতি বা কোনও DataBindপদ্ধতি প্রকাশ করতে পারে ।

class GridControl
{
    public Render(GridData data) { ... }
}

অথবা

class GridControl
{
    public DataBind(GridData data) { ... }
}

তারপরে আপনার লজিকাল ইউনিট হয় গ্রিডকন্ট্রোল নিতে এবং এটিতে কোনও ডেটা অবজেক্টকে বেঁধে রাখতে পারে বা যেকোন সময় পরিবর্তিত হওয়ার পরে ম্যানুয়ালি ডেটা অবজেক্টের সাথে রেন্ডার কল করতে পারে।

আপনার গ্রিডলজিকের গ্রিডকন্ট্রোলেরও একটি উল্লেখ থাকতে হবে যাতে এটি যে কোনও ইনপুট / ইভেন্টের সাথে আবদ্ধ হতে পারে।

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

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

Answer 6

আমি দৃ strongly়ভাবে পরামর্শ দিচ্ছি যে আপনি এমভিসি আর্কিটেকচারটি একবার দেখুন ।

এটি আপনার উল্লিখিত ধারণার সংশোধন (প্রোগ্রাম কোড এবং গ্রাফিক ইন্টারফেসের বিভাজন)। এমভিসি মানে মডেল-ভিউ-কন্ট্রোলার। এখানে মডেলটি হ'ল ডেটা, ভিউ গ্রাফিক ইন্টারফেস কোড এবং কনট্রোলার এমন কোড যা ডেটা প্রক্রিয়াকরণ করে।

এইভাবে আপনি আপনার প্রোগ্রামের তিনটি অংশ তৈরি করেছেন। প্রতিটি অংশ অন্যান্য দুটি অংশের পরিবর্তনের প্রয়োজন ছাড়াই প্রতিস্থাপন করা যেতে পারে।

Answer 7

এটি নির্ভর করে ভবিষ্যতের যে ধরণের পরিবর্তনগুলি আপনি হতে পারে তা নির্ভর করে। আপনি যা হ্রাস করতে চান তা হ'ল প্রতিটি একক কার্যকরী পরিবর্তন সঠিকভাবে বাস্তবায়নের জন্য প্রয়োজনীয় ম্যানুয়াল কোড পরিবর্তনের সংখ্যা।

পরিবর্তনগুলি ভি অংশে বা "দেখুন" সীমাবদ্ধ থাকলে এমভিসি জিতে থাকে।

আমার অভিজ্ঞতায়, পরিবর্তনগুলি তিনটি অংশকেই প্রভাবিত করে এমনটি অনেক বেশি সম্ভবত তাই তারা পৃথক না করা ভাল it আমার অর্থটি বোঝাতে, আমি দীর্ঘদিন ধরে ডাইনামিক ডায়ালগস নামে পরিচিত একটি কৌশল ব্যবহার করেছি , যার মধ্যে একটি নতুন প্রয়োজনীয়তা যেমন "ব্যবহারকারীকে নাম সম্পাদনা করার অনুমতি দেওয়া হয়, এবং সম্পূর্ণ করার পরে XYZ" এর একক ব্লক হিসাবে উত্স কোডে প্রবেশ করা হয় as পাঠ্য:

if(deTextEdit(&sName)){
  // do XYZ
}

একাধিক পৃথক সম্পাদনার পরিবর্তে, সম্পাদনা ক্ষেত্রটি বিদ্যমান তা নির্দিষ্ট করার জন্য, এর জন্য একটি অনন্য শনাক্তকারী তৈরি করতে, এটি মডেল ভেরিয়েবলের সাথে আবদ্ধ করতে এবং হারানো-ফোকাস ইভেন্ট হ্যান্ডলারের সাথে লিঙ্ক করতে।

আপনি যদি সেই লিঙ্কটিতে যান তবে আপনি আরও জটিল উদাহরণ দেখতে পাবেন।

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

এটি নিখরচায় নয়। এটি প্রোগ্রামারটির জন্য এককালীন শেখার কার্ভটি প্রবর্তন করে।

Answer 8

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