আমার কখন জাভা সুইং ক্লাস বাড়ানো উচিত?


35

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

আমার জাভা প্রফেসর আমাদের যা করার জন্য সুপারিশ করছেন সে কারণে আমি সেই বোঝার বিষয়ে প্রশ্ন করছি। তিনি সুপারিশ করেছেন যে একটি JSwingআবেদনের জন্য আমরা ক্লাসে তৈরি করছি

এক সব প্রসারিত করা উচিত JSwingশ্রেণীর ( JFrame, JButton,JTextBox পৃথক কাস্টম শ্রেণীতে, ইত্যাদি) এবং (কম্পোনেন্ট আকার, উপাদান লেবেল, ইত্যাদি) তাদের মধ্যে গুই সংশ্লিষ্ট স্বনির্ধারণ উল্লেখ

এতদূর ভাল, তবে তিনি আরও পরামর্শ দিয়ে চলেছেন যে প্রতিটি জেবাটনের নিজস্ব কাস্টম বর্ধিত শ্রেণি হওয়া উচিত যদিও একমাত্র স্বতন্ত্র ফ্যাক্টরটি তাদের লেবেল।

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

class OkayButton extends JButton{
    MainUI mui;
    public OkayButton(MainUI mui) {
        setSize(80,60);
        setText("Okay");
        this.mui = mui;
        mui.add(this);        
    }
}

class CancelButton extends JButton{
    MainUI mui;
    public CancelButton(MainUI mui) {
        setSize(80,60);
        setText("Cancel");
        this.mui = mui;
        mui.add(this);        
    }
}

আপনি দেখতে পাচ্ছেন একমাত্র পার্থক্যটি হল setTextফাংশনটিতে in

তাহলে কি এই স্ট্যান্ডার্ড অনুশীলন?

বিটিডব্লিউ, যে কোর্সে এটি নিয়ে আলোচনা করা হয়েছিল তাকে জাভাতে সেরা প্রোগ্রামিং অনুশীলন বলা হয়

[অধ্যাপকের কাছ থেকে জবাব দিন]

তাই আমি প্রফেসরের সাথে সমস্যাটি নিয়ে আলোচনা করেছি এবং উত্তরে বর্ণিত সমস্ত পয়েন্ট উত্থাপন করেছি।

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

আমার ধারণা করার কারণটি আমি পেয়েছি তবে এখনও এটি কেবল উত্তরাধিকার শোষণ করে কোডকে ভঙ্গুর করে তুলছে।

পরে, কোনও বিকাশকারী দুর্ঘটনাক্রমে setTextএকটি Okayবোতামে কল করতে এবং এটি পরিবর্তন করতে পারে। সাবক্লাস কেবল সেক্ষেত্রে উপদ্রব হয়ে যায়।


3
কেন JButtonআপনি এটির নির্মাণকারীর মধ্যে সর্বজনীন পদ্ধতিগুলি প্রসারিত এবং কল করতে পারেন, যখন আপনি কেবল JButtonশ্রেণীর বাইরে এই জাতীয় পাবলিক পদ্ধতিগুলি তৈরি করতে এবং কল করতে পারেন ?

17
পারলে সেই প্রফেসর থেকে দূরে থাকুন। এটি সেরা অনুশীলন হওয়া থেকে অনেক দূরে । আপনার চিত্রের মতো কোড সদৃশতা খুব খারাপ গন্ধ।
njzk2

7
কেবল তাকে কেন জিজ্ঞাসা করুন, তার অনুপ্রেরণাটি এখানে বলতে দ্বিধা করবেন না।
অ্যালেক্স

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

1
@ অ্যালেক্স আমি প্রফেসরটির ন্যায্যতার সাথে প্রশ্নটি আপডেট করেছি
পারস

উত্তর:


21

এটি লিসকভ সাবস্টিটিউশন নীতি লঙ্ঘন করে কারণ কোনওটি আশানুরূপ OkayButtonকোনও জায়গায় প্রতিস্থাপন করা যায় না Button। উদাহরণস্বরূপ, আপনি যে কোনও বোতামের লেবেল আপনার পছন্দ অনুযায়ী পরিবর্তন করতে পারেন। তবে OkayButtonএটির সাথে এটি করা এর অভ্যন্তরীণ আক্রমণকারীদের লঙ্ঘন করে।

কোড পুনরায় ব্যবহারের জন্য এটি উত্তরাধিকারের একটি সর্বোত্তম ব্যবহার। পরিবর্তে একটি সহায়ক পদ্ধতি ব্যবহার করুন।

এটি না করার অন্য একটি কারণ হ'ল লিনিয়ার কোডটি একই জিনিস অর্জনের এটি কেবল একটি সংশ্লেষিত উপায়।


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

এটি এটি লঙ্ঘন করে না কারণ আপনি পারেন। activateButton(Button btn)উদাহরণস্বরূপ , যদি কোনও পদ্ধতি কোনও বোতামের প্রত্যাশা করে তবে আপনি সহজেই এর উদাহরণ দিতে পারেন OkayButton। নীতিটির অর্থ এই নয় যে এর ঠিক একই কার্যকারিতা থাকতে হবে, কারণ এটি উত্তরাধিকারটিকে অনেক বেশি অকেজো করে তুলবে।
Sebb

1
@ সেবব তবে আপনি এটি কোনও ফাংশন দিয়ে ব্যবহার করতে পারবেন না setText(button, "x")কারণ এটি (অনুমান করা) আক্রমণকারীকে লঙ্ঘন করে। এটি সত্য যে এই নির্দিষ্ট ওকেবাটনের কোনও আকর্ষণীয় আক্রমণকারী নাও থাকতে পারে তাই আমি অনুমান করি যে আমি একটি খারাপ উদাহরণ বেছে নিয়েছি। তবে এটা হতে পারে। উদাহরণস্বরূপ, ক্লিক হ্যান্ডলার যদি বলে if (myText == "OK") ProcessOK(); else ProcessCancel();? তারপরে পাঠ্যটি হানাদারের অংশ।
usr

@ আরআর আমি পাঠ্যটি আক্রমণকারীর অংশ হওয়ার কথা ভাবিনি। আপনি ঠিক বলেছেন, এটি তখন লঙ্ঘিত হয়েছে।
Sebb

50

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


20
+1 টি। আরও রেফারেন্সের জন্য, অ্যাবস্ট্র্যাক্ট বাটনের সুইং ক্লাসের শ্রেণিবিন্যাস দেখুন । তারপরে JToggleButton এর শ্রেণিবিন্যাস দেখুন । উত্তরাধিকার বিভিন্ন ধরণের বোতাম ধারণ করতে ব্যবহৃত হয় to তবে এটি ব্যবসায়ের ধারণাগুলি পৃথক করতে ব্যবহৃত হয় না ( হ্যাঁ, না, চালিয়ে যান, বাতিল করুন ... )।
লাইভ

2
@Laiv: এমনকি, জন্য স্বতন্ত্র ধরনের থাকার যেমন JButton, JCheckBox, JRadioButton, শুধু ডেভেলপারদের অন্যান্য টুলকিট, প্লেইন AWT, যেখানে যেমন ধরনের মান মত সাথে পরিচিত হচ্ছে একটি ছাড় নেই। নীতিগতভাবে, এগুলি সমস্তই একক বোতাম শ্রেণীর দ্বারা পরিচালিত হতে পারে। এটি মডেল এবং ইউআই প্রতিনিধিদের সংমিশ্রণ যা আসল পার্থক্য করে।
হলগার

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

12

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

( যাইহোক , গুগল পণ্ডিত আপনি যে কাগজটি উদ্ধৃত করেছেন তা কখনও শুনেনি - আপনার কাছে আরও সুনির্দিষ্ট উল্লেখ আছে?)


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

@ কমফ্রোম আমি পুরো সুইং টিউটোরিয়ালটি না পড়ার বিষয়টি স্বীকার করব, সুতরাং এই স্টাইলটি কোথায় ব্যবহৃত হয়েছে তা আমি মিস করেছি, তবে যে পৃষ্ঠাগুলি আমি দেখেছি সেগুলি বেস ক্লাসগুলি ব্যবহার করে এবং সাবক্লাস চালনা করে না, যেমন ডকস.অরাকল .com / জাভাস / টিউটোরিয়াল / uiswing / উপাদান / বাটন html
জুলাই

@ জুলসের বিভ্রান্তির জন্য দুঃখিত, আমি বলতে চাইছি যে কোর্স / কাগজটি অধ্যাপক শেখাচ্ছেন তাকে জাভাতে সেরা অনুশীলন বলা হয়
প্যারাস

1
সাধারণত সত্য, তবে অন্য একটি বড় ব্যতিক্রম রয়েছে - JPanel। এটি পাতাগুলি JFrameকেবল একটি বিমূর্ত ধারক হওয়ার চেয়ে সাবক্লাসের পক্ষে আরও কার্যকর ।
অজস্র

10

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

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

class MyButton extends JButton{
    protected final MainUI mui;
    public MyButton(MainUI mui, String text) {
        setSize(80,60);
        setText(text);
        this.mui = mui;
        mui.add(this);        
    }
}

class OkayButton extends MyButton{
    public OkayButton(MainUI mui) {
        super(mui, "Okay");
    }
}

class CancelButton extends MyButton{
    public CancelButton(MainUI mui) {
        super(mui, "Cancel");
    }
}

কখন এটি একটি ভাল ধারণা? আপনি যখন তৈরি করেছেন টাইপগুলি ব্যবহার করেন! উদাহরণস্বরূপ, যদি আপনার একটি পপ-আপ উইন্ডো তৈরি করার কোনও ফাংশন থাকে এবং স্বাক্ষরটি হ'ল:

public void showPopUp(String text, JButton ok, JButton cancel)

এই ধরনের আপনি স্রেফ তৈরি করেছেন যা কিছু ভাল করছে না। কিন্তু:

public void showPopUp(String text, OkButton ok, CancelButton cancel)

এখন আপনি দরকারী কিছু তৈরি করেছেন।

  1. সংকলকটি যাচাই করে যে শোপপআপ একটি OkButton এবং একটি বাতিলবাটন নেয়। কোডটি পড়ছেন এমন কেউ জানেন যে এই ফাংশনটি কীভাবে ব্যবহার করা হচ্ছে তা বোঝায় কারণ এই জাতীয় ডকুমেন্টেশনটি যদি তারিখের বাইরে চলে যায় তবে একটি সংকলন-সময় ত্রুটির কারণ ঘটবে। এটি একটি মেজর সুবিধা। প্রকার সুরক্ষার সুবিধাগুলির 1 বা 2 গবেষণামূলক গবেষণায় দেখা গেছে যে মানব কোড বোধগম্যই ছিল একমাত্র পরিমাণে উপকার।

  2. এটি ত্রুটিগুলি প্রতিরোধ করে যেখানে আপনি ফাংশনে পাস করার বোতামগুলির ক্রমটি বিপরীত করেন। এই ত্রুটিগুলি সনাক্ত করা কঠিন, তবে এগুলি বেশ বিরল, সুতরাং এটি একটি মাইনর সুবিধা। এটি প্রকারের সুরক্ষা বিক্রি করার জন্য ব্যবহৃত হয়েছিল, তবে বিশেষভাবে কার্যকর হিসাবে প্রমাণিত হয়নি।

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

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

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

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

পিএস আমি muiপয়েন্টারটি চূড়ান্ত করেছিলাম - এটি পরিবর্তনীয় হওয়ার দরকার নেই।


6
আপনার 3 পয়েন্টগুলির মধ্যে 1 এবং 3 ঠিক জেনেরিক জেবুটন এবং একটি সঠিক ইনপুট প্যারামিটার নামকরণ প্রকল্পের সাথে পরিচালনা করতে পারে। পয়েন্ট 2 আসলে এটি একটি খারাপ দিক যা এটি আপনার কোডটিকে আরও দৃly়ভাবে মিশ্রিত করে তোলে: আপনি যদি বাটনটির ক্রমটি বিপরীত হতে চান তবে কী হবে? ঠিক আছে / বাতিল বোতামগুলির পরিবর্তে, আপনি হ্যাঁ / না বোতাম ব্যবহার করতে চান তবে কী হবে? আপনি কি পুরোপুরি নতুন শোপপআপ পদ্ধতিটি তৈরি করবেন যা একটি হ্যাঁস বাটন এবং একটি নবুটন লাগে? আপনি যদি কেবল ডিফল্ট JButtons ব্যবহার করেন তবে আপনাকে প্রথমে আপনার ধরণের তৈরি করার দরকার নেই কারণ সেগুলি ইতিমধ্যে বিদ্যমান।
Nzall

@ নাটকেরখফস যা বলেছে তা বাড়িয়ে দিয়ে, একটি আধুনিক আইডিই আপনি প্রকৃত প্রকাশের সময় টাইপ করার সময় আপনাকে আনুষ্ঠানিক যুক্তির নামগুলি দেখায়।
সলোমন আস্তে

8

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

বলা হচ্ছে, বাস্তব বিশ্বে আমরা উত্তরাধিকারের চেয়েও রচনার পক্ষপাতী ।

আপনার আইনের নিয়মটি যদি কেবলমাত্র একটি আইএস-এ সম্পর্ক উপস্থিত থাকে তবে একটি শ্রেণি বাড়ানো উচিত। এটি "... দিয়ে শেষ হওয়া উচিত এবং আমাদের ক্লাসের ডিফল্ট আচরণ পরিবর্তন করা দরকার" বড় সাহসী অক্ষরে ।

আপনার উদাহরণগুলি সেই মানদণ্ডের সাথে খাপ খায় না। আপনার পাঠ্যটি সেট করার জন্য extendআপনার JButtonক্লাসে নেই। এটিতে উপাদান যুক্ত করার জন্য extendআপনার JFrameক্লাসে নেই। আপনি তাদের ডিফল্ট বাস্তবায়নগুলি ব্যবহার করে এই জিনিসগুলি ঠিকঠাক করতে পারেন, সুতরাং উত্তরাধিকার যুক্ত করা কেবল অপ্রয়োজনীয় জটিলতা যুক্ত করে।

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

আপনার প্রশ্নে ফিরে যান: আপনার জাভা ক্লাস কখন বাড়ানো উচিত?যখন আপনার কাছে ক্লাস প্রসারিত করার সত্যিকারের, সত্যই, সত্যিকারের ভাল কারণ রয়েছে।

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

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


1
ওহ অপেক্ষা করুন, আপনি একটি সেট সেট করতে পারেন Borderযা অতিরিক্ত সজ্জা আঁকবে। অথবা একটি তৈরি করুন JLabelএবং Iconএটিতে একটি কাস্টম বাস্তবায়ন পাস করুন । JPanelপেইন্টিংয়ের জন্য সাবক্লাস করা প্রয়োজন হয় না (এবং JPanelপরিবর্তে কেন JComponent)।
হলগার

1
আমার মনে হয় আপনার এখানে সঠিক ধারণা আছে তবে সম্ভবত আরও ভাল উদাহরণ বেছে নিতে পারেন।

1
তবে আমি আপনার উত্তরটি সঠিক এবং আপনি ভাল পয়েন্ট তৈরির পুনরাবৃত্তি করতে চাই । আমি কেবল নির্দিষ্ট উদাহরণ এবং টিউটোরিয়ালটিকে দুর্বলভাবে সমর্থন করি বলে মনে করি think

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

1
"আমি বাজি ধরছি তারা আপনাকে বাধ্য করার জন্য এটি কেবল উদাহরণ হিসাবে ব্যবহার করছে ..." আমার অন্যতম প্রধান উঁকি! প্রশিক্ষক যারা শেখান কিভাবে এক্স করতে এর ভয়ঙ্করভাবে মানসিক বিকারগ্রস্ত উদাহরণ ব্যবহার কেন এক্স করতে
সলোমন স্লো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.