জাভার @Overrideটীকাটি ব্যবহারের জন্য সর্বোত্তম অনুশীলনগুলি কী এবং কেন?
দেখে মনে হচ্ছে এটি @Overrideটীকা সহ প্রতিটি ওভাররাইড হওয়া পদ্ধতি চিহ্নিত করা ওভারকিল হবে । এমন কিছু প্রোগ্রামিং পরিস্থিতি রয়েছে যা @Overrideএবং কখনও কখনও ব্যবহার করা উচিত নয় এমন অন্যান্যদের ব্যবহারের জন্য ডাকে @Override?
উত্তর:
প্রতিবার দুটি উপকারের জন্য কোনও পদ্ধতিকে ওভাররাইড করার সময় এটি ব্যবহার করুন। এটি করুন যাতে আপনি যখন মনে করেন যে আপনি আসলে কোনও পদ্ধতিকেই ওভাররাইড করছেন তা নিশ্চিত করার জন্য আপনি সংকলক চেকিংয়ের সুবিধা নিতে পারেন। এইভাবে, আপনি যদি কোনও পদ্ধতির নামের ভুল বানান বা প্যারামিটারগুলির সাথে সঠিকভাবে মেলে না যাওয়ার সাধারণ ভুল করেন তবে আপনাকে সতর্ক করা হবে যে আপনি পদ্ধতিটি যেমন ভাবেন ঠিক তেমনভাবে ওভাররাইড হয় না। দ্বিতীয়ত, এটি আপনার কোডটিকে বোঝা সহজ করে তোলে কারণ যখন পদ্ধতিগুলি ওভাররাইট করা হয় তখন এটি আরও স্পষ্ট।
অতিরিক্ত হিসাবে, জাভা 1.6 এ আপনি যখন কোনও পদ্ধতি একই সুবিধার জন্য একটি ইন্টারফেস প্রয়োগ করে তখন এটি চিহ্নিত করতে আপনি এটি ব্যবহার করতে পারেন। আমি মনে করি আলাদা টীকাটি দেওয়া (যেমন @Implements) রাখাই ভাল তবে এটি কোনও কিছুর চেয়ে ভাল।
আমি মনে করি এটি একটি সংকলন-সময় অনুস্মারক হিসাবে সবচেয়ে কার্যকর যে পদ্ধতির উদ্দেশ্যটি পিতামাতার পদ্ধতিকে ওভাররাইড করা। উদাহরণ হিসাবে:
protected boolean displaySensitiveInformation() {
return false;
}আপনি প্রায়শই উপরের পদ্ধতির মতো কিছু দেখতে পাবেন যা বেস ক্লাসে কোনও পদ্ধতিকে ওভাররাইড করে। এটি এই শ্রেণীর একটি গুরুত্বপূর্ণ বাস্তবায়ন বিবরণ - আমরা সংবেদনশীল তথ্য প্রদর্শিত হতে চাই না।
ধরুন এই পদ্ধতিটি অভিভাবক শ্রেণিতে পরিবর্তিত হয়েছে
protected boolean displaySensitiveInformation(Context context) {
return true;
}এই পরিবর্তনটি কোনও সংকলন সময় ত্রুটি বা সতর্কবার্তা সৃষ্টি করবে না - তবে এটি সাবক্লাসের উদ্দেশ্যপূর্ণ আচরণকে সম্পূর্ণ পরিবর্তন করে।
আপনার প্রশ্নের উত্তর দেওয়ার জন্য: যদি একটি সুপার ক্লাসে একই স্বাক্ষরযুক্ত কোনও পদ্ধতির অভাব একটি বাগের ইঙ্গিত দেয় তবে আপনার @ ওভাররাইড টীকাটি ব্যবহার করা উচিত।
এখানে অনেক ভাল উত্তর আছে, সুতরাং আমি এটি দেখার জন্য অন্য একটি উপায় প্রস্তাব করি ...
আপনি কোডিংয়ের সময় কোনও ওভারকিল নেই। @ ওভাররাইড টাইপ করতে আপনার কোনও খরচ হয় না, তবে আপনি যদি কোনও পদ্ধতির নাম ভুল বানান করে থাকেন বা স্বাক্ষরটি কিছুটা ভুল করে থাকেন তবে সঞ্চয়গুলি অপরিসীম হতে পারে।
এটি সম্পর্কে এইভাবে ভাবুন: আপনি এখানে নেভিগেশন করেছেন এবং এই পোস্টটি টাইপ করেছেন, আপনি আপনার জীবনকাল ধরে @ ওভাররাইড টাইপ করতে ব্যয় করার চেয়ে অনেক বেশি সময় ব্যবহার করেছেন; তবে এটির একটি ত্রুটি আপনার ঘন্টা বাঁচাতে পারে।
জাভা সম্পাদনা / সংকলনের সময় আপনি যে কোনও ভুল করেননি তা নিশ্চিত করার জন্য যথাসাধ্য চেষ্টা করে, সম্পূর্ণ পরীক্ষার বাইরে অন্য কোনও উপায়ে প্রতিরোধযোগ্য নয় এমন একটি সম্পূর্ণ শ্রেণীর ভুল সমাধানের জন্য এটি কার্যত নিখরচায় একটি উপায়।
আপনি যখন জাভাতে কোনও পদ্ধতিকে ওভাররাইড করতে চেয়েছিলেন তখন তিনি আসলে কী করেছিলেন তা নিশ্চিত করার জন্য আপনি জাভাতে আরও ভাল প্রক্রিয়া নিয়ে আসতে পারেন?
আরেকটি ঝরঝরে প্রভাব হ'ল আপনি যদি টীকাটি সরবরাহ না করেন তবে এটি সংকলনের সময় আপনাকে সতর্ক করবে যে আপনি দুর্ঘটনাক্রমে একটি পিতামাতার পদ্ধতিকে ছাড়িয়ে যান - এমন কিছু যা আপনি যদি এটি করার ইচ্ছা না করেন তবে তা লক্ষণীয় হতে পারে।
@Overrideটীকাটি ব্যবহার করা একটি সাধারণ প্রোগ্রামিং ভুলের বিরুদ্ধে একটি সংকলন-সময় সুরক্ষার কাজ করে। আপনি যদি এমন কোনও পদ্ধতিতে টীকা থাকে যা আপনি আসলে সুপারক্লাস পদ্ধতিটিকে ওভাররাইড করছেন না এটি সংকলন ত্রুটি ছুঁড়ে দেবে।
আপনি যখন বেস ক্লাসে কোনও পদ্ধতি পরিবর্তন করে আলাদা প্যারামিটারের তালিকা তৈরি করেন তখন এটি কার্যকর এমন সর্বাধিক সাধারণ ক্ষেত্রে। একটি সাবক্লাসের একটি পদ্ধতি যা সুপারক্লাস পদ্ধতিটি ওভাররাইড করতে ব্যবহৃত হত পরিবর্তিত পদ্ধতির স্বাক্ষরের কারণে আর এটি করা হবে না। এটি কখনও কখনও জটিল উত্তরাধিকার কাঠামো নিয়ে কাজ করার সময় অদ্ভুত এবং অপ্রত্যাশিত আচরণের কারণ হতে পারে। এর @Overrideবিরুদ্ধে টীকা সুরক্ষার ব্যবস্থা।
সংকলক চেকিং থেকে সুবিধা নিতে আপনার সর্বদা ওভাররাইড টীকাটি ব্যবহার করা উচিত। তবে ভুলে যাবেন না যে জাভা সংকলক 1.5 এই ইন্টারফেস পদ্ধতিগুলিকে ওভাররাইড করার সময় এই টীকাটিকে অনুমতি দেবে না। আপনি কেবল এটি ক্লাসের পদ্ধতিগুলিকে ওভাররাইড করতে ব্যবহার করতে পারেন (বিমূর্ত বা না)।
কিছু আইডিই, যেমন ইক্লিপস, এমনকি জাভা ১.6 রানটাইম বা ততোধিক সময়ের সাথে কনফিগার করা হয়েছে, তারা জাভা ১.৫ এর সাথে সম্মতি বজায় রাখে এবং উপরে বর্ণিত হিসাবে @override ব্যবহারের অনুমতি দেয় না। এই আচরণটি এড়াতে আপনার অবশ্যই যেতে হবে: প্রকল্পের বৈশিষ্ট্য -> জাভা সংকলক -> "প্রকল্প নির্দিষ্ট সেটিংস সক্ষম করুন" -> "সংকলক সম্মতি স্তর" = 6.0 বা তার চেয়ে বেশি চয়ন করুন।
বেসটি যদি ইন্টারফেস বা শ্রেণি হয় তবে প্রতিবারই আমি স্বতন্ত্রভাবে কোনও পদ্ধতিকে ওভাররাইড করছি এই টিকাটি ব্যবহার করতে চাই।
এটি আপনাকে কিছু সাধারণ ত্রুটিগুলি এড়াতে সহায়তা করে, যেমন আপনি যখন ভাবছেন যে আপনি কোনও ইভেন্ট হ্যান্ডলারকে ওভাররাইড করছেন এবং তারপরে আপনি কিছুই ঘটছেন না তা দেখে। কল্পনা করুন আপনি কিছু ইউআই উপাদানতে ইভেন্ট শ্রোতা যুক্ত করতে চান:
someUIComponent.addMouseListener(new MouseAdapter(){
public void mouseEntered() {
...do something...
}
});উপরের কোডটি সংকলন করে চালান, তবে আপনি কিছু ইউআইকিউম্পোন্টের ভিতরে মাউসটি সরিয়ে ফেললে "কিছু করুন" কোডটি রান নোটটি লক্ষ্য করবে, কারণ বাস্তবে আপনি বেস পদ্ধতিটি ওভাররাইড করছেন না mouseEntered(MouseEvent ev)। আপনি কেবল একটি নতুন প্যারামিটার-কম পদ্ধতি তৈরি করেছেন mouseEntered()। সেই কোডটির পরিবর্তে, আপনি যদি @Overrideটীকাটি ব্যবহার করে থাকেন তবে আপনি একটি সংকলন ত্রুটি দেখেছেন এবং কেন আপনার ইভেন্ট হ্যান্ডলারটি চালাচ্ছে না তা ভেবে সময় নষ্ট করছেন না।
@ জাভাতে "ইন্টারফেসকে ওভাররাইডিং" করার মতো কোনও জিনিস নেই বলে ইন্টারফেস বাস্তবায়নের উপর ওভাররাইডটি অসঙ্গত।
@ ইন্টারফেস বাস্তবায়নের উপর ওভাররাইড অকেজো কারণ বাস্তবে এটি কোনও বাগ ধরেনি যা সংকলন যেভাবেই ধরবে না way কেবলমাত্র একটি, সুদৃ scenario় পরিস্থিতি রয়েছে যেখানে বাস্তবায়নকারীদের উপর ওভাররাইড আসলে কিছু করে: আপনি যদি কোনও ইন্টারফেস এবং ইন্টারফেস প্রয়োগ করে তবে পদ্ধতিগুলি অপসারণের সময় আপনাকে সংকলনের সময় জানানো হবে যে অব্যবহৃত বাস্তবায়নগুলি অপসারণ করা উচিত। লক্ষ্য করুন যে যদি ইন্টারফেসের নতুন সংস্করণে নতুন বা পরিবর্তিত পদ্ধতি থাকে তবে আপনি নতুন স্টাফ প্রয়োগ না করায় অবশ্যই স্পষ্টতই একটি সংকলন ত্রুটি পাবেন।
ইন্টারফেস প্রয়োগকারীদের @ ওভাররাইডের 1.6-এ কখনই অনুমতি দেওয়া উচিত ছিল না, এবং গ্রহনের সাথে দুঃখের সাথে ডিফল্ট আচরণ হিসাবে টীকাগুলি স্বয়ংক্রিয়ভাবে সন্নিবেশ করা বেছে নেওয়া, আমরা প্রচুর বিশৃঙ্খলাযুক্ত উত্স ফাইল পাই get ১. code কোড পড়ার সময়, আপনি যদি ওভাররাইড টীকা থেকে দেখতে পারেন না যে কোনও পদ্ধতি যদি আসলে সুপারক্লাসের কোনও পদ্ধতিকে ওভাররাইড করে বা কেবল একটি ইন্টারফেস প্রয়োগ করে।
একটি সুপারক্লাসে কোনও পদ্ধতিকে ওভাররাইড করার সময় @ ওভাররাইড ব্যবহার করা ভাল।
ওভাররাইড হিসাবে চিহ্নিত প্রতিটি পদ্ধতির জন্য এটি ব্যবহার করা সর্বোত্তম, এবং জাভা 6+, প্রতিটি ইন্টারফেসের প্রয়োগ হিসাবে চিহ্নিত প্রতিটি পদ্ধতি।
প্রথমত, এটি সংকলন সময়ে " hashcode()" এর পরিবর্তে " " "এর মতো ভুল বানানগুলি ধরে hashCode()। এটির কারণটি যখন আপনার কোডটি কখনই না চাওয়া হয় তখন কেন আপনার পদ্ধতির ফলাফলটি আপনার কোডের সাথে মেলে না বলে ডিবাগ করতে পারে।
এছাড়াও, যদি একটি সুপার ক্লাস কোনও পদ্ধতিতে স্বাক্ষর পরিবর্তন করে তবে পুরানো স্বাক্ষরটির ওভাররাইডগুলি "এতিম" হতে পারে, তাকে বিভ্রান্তিকর ডেড কোড হিসাবে রেখে যায়। @Overrideটীকা এইসব এতিমদের চিহ্নিত যাতে তারা নতুন স্বাক্ষর মেলে পরিবর্তন করা যাবে সাহায্য করবে।
যদি আপনি নিজেকে প্রায়শই ওভাররাইডিং (অ-বিমূর্ত) পদ্ধতিগুলি দেখতে পান তবে আপনি সম্ভবত আপনার নকশাটি একবার দেখতে চান। এটি খুব কার্যকর যখন সংকলক অন্যথায় ত্রুটিটি ধরবে না। উদাহরণস্বরূপ থ্রডলোকলে (আমি) থ্রিজলয়ে () টি ওভাররাইড করার চেষ্টা করছি।
ইন্টারফেসের পদ্ধতিগুলি (1.6+ বৈশিষ্ট্য) প্রয়োগ করার সময় @ ওভাররাইড ব্যবহার করা আমার কাছে কিছুটা ওভারকিল বলে মনে হচ্ছে। আপনার যদি প্রচুর পদ্ধতিতে লোড থাকে যার কয়েকটি ওভাররাইড করে এবং কিছু না করে, সম্ভবত এটি আবার খারাপ নকশা (এবং আপনার সম্পাদক সম্ভবত প্রদর্শিত হবে যা কোনটি যদি আপনি না জানেন)।
@ ইন্টারফেসে ওভাররাইড আসলে সহায়ক, কারণ আপনি ইন্টারফেস পরিবর্তন করলে আপনি সতর্কতা পাবেন।
এটি অন্য একটি জিনিস যা কোডটি পড়ার সময় এটি আরও স্পষ্ট করে তোলে যে এটি পিতাম শ্রেণীর আচরণ পরিবর্তন করছে। ডিবাগ করতে সাহায্য করতে পারে।
এছাড়াও, জোশুয়া ব্লকের কার্যকরী জাভা (দ্বিতীয় সংস্করণ) বইতে, আইটেম 36 টি টীকাটি করার সুবিধা সম্পর্কে আরও বিশদ দেয়।
কোনও ইন্টারফেস পদ্ধতি প্রয়োগ করার সময় @ ওভাররাইড ব্যবহার করা একেবারেই অর্থবোধ করে না। সেক্ষেত্রে এটি ব্যবহার করার কোনও সুবিধা নেই - সংকলক ইতিমধ্যে আপনার ভুলটি ধরবে, সুতরাং এটি কেবল অপ্রয়োজনীয় বিশৃঙ্খলা।
@Overrideযখন ইন্টারফেসে একটি পদ্ধতি মুছে ফেলা হবে একটি ইন্টারফেস নোটিশ আপনাকে বাধ্য করা হবে।
যখনই কোনও পদ্ধতি অন্য পদ্ধতিকে ওভাররাইড করে বা কোনও পদ্ধতি একটি ইন্টারফেসে একটি স্বাক্ষর প্রয়োগ করে।
@Overrideটীকা আপনি আশ্বাস দেয় যে, আপনি আসলে ওভাররাইড কিছু করেনি। টিকা ছাড়াই আপনি কোনও ভুল বানান বা প্যারামিটারের ধরণ এবং সংখ্যার মধ্যে পার্থক্য রাখেন।
আমি এটি প্রতিবার ব্যবহার করি। এটি আরও তথ্য যা আমি এক বছরে কোডটি পুনর্বিবেচনা করলে কী ঘটছে তা দ্রুত নির্ধারণ করতে ব্যবহার করতে পারি এবং আমি প্রথমবার যা ভাবছিলাম তা ভুলে গিয়েছি।
সর্বদা সেরা ব্যবহারিক হ'ল এটি সর্বদা ব্যবহার করা (বা আইডিই আপনার জন্য সেগুলি পূরণ করুন)
@ ওভাররাইড উপযোগিতা হ'ল পিতামাতার ক্লাসগুলির পরিবর্তনগুলি সনাক্ত করা যা শ্রেণিবদ্ধকরণের কথা বলা হয়নি। এটি ব্যতীত, আপনি একটি পদ্ধতি স্বাক্ষর পরিবর্তন করতে এবং @ ওভাররাইডের সাহায্যে এর ওভাররাইডগুলি পরিবর্তন করতে ভুলে যেতে পারেন, সংকলকটি এটি আপনার জন্য ধরবে।
এই জাতীয় সুরক্ষা জাল থাকা সর্বদা ভাল।
আমি এটি সর্বত্র ব্যবহার করি। চিহ্নিতকরণের পদ্ধতিগুলির জন্য প্রয়াসের প্রসঙ্গে, আমি গ্রীকটিকে এটি আমার জন্য করতে দিয়েছি, এটি কোনও অতিরিক্ত প্রচেষ্টা নয়।
আমি ধারাবাহিক রিফ্যাক্টরিং সম্পর্কে ধর্মীয় .... সুতরাং, আমি প্রতিটি ছোট জিনিস এটি আরও সুচারুভাবে চালিত করতে ব্যবহার করব।
যদি ধারাবাহিকভাবে ব্যবহার করা হয় তবে এটি আপনাকে বিপথগামী বাগের একটি বিশাল শ্রেণীর হাত থেকে রক্ষা করে।
এই বাগগুলি এড়াতে @ ওভাররাইড টীকাটি ব্যবহার করুন: (নিম্নলিখিত কোডটিতে বাগটি স্পট করুন :)
public class Bigram {
private final char first;
private final char second;
public Bigram(char first, char second) {
this.first = first;
this.second = second;
}
public boolean equals(Bigram b) {
return b.first == first && b.second == second;
}
public int hashCode() {
return 31 * first + second;
}
public static void main(String[] args) {
Set<Bigram> s = new HashSet<Bigram>();
for (int i = 0; i < 10; i++)
for (char ch = 'a'; ch <= 'z'; ch++)
s.add(new Bigram(ch, ch));
System.out.println(s.size());
}
}উত্স: কার্যকর জাভা
(b.first == first) && (b.second == second), তার &&চেয়ে কম অগ্রাধিকার থাকলেও ==।
Object::equalsহল boolean equals(Object), যখন উপেক্ষিত equalsহয় boolean equals(Bigram)যা একটি ভিন্ন পদ্ধতি স্বাক্ষর, যা ওভাররাইড না রয়েছে। @ ওভাররাইড যোগে equalsএই ত্রুটি সনাক্ত করবে।
আপনি ওভাররাইড ব্যবহার করার সময় সাবধান থাকবেন, কারণ আপনি পরে স্টারআউএমএলে বিপরীত প্রকৌশলী করতে পারবেন না; প্রথমে ইউএমএল তৈরি করুন।
মনে হয় এখানকার জ্ঞান বদলে যাচ্ছে। আজ আমি ইন্টেলিজ আইডিইএ 9 ইনস্টল করেছি এবং লক্ষ্য করেছি যে এটির " নিখোঁজ @ ওভাররাইড পরিদর্শন " এখন কেবল প্রয়োগ করা বিমূর্ত পদ্ধতি নয়, তবে প্রয়োগ করা ইন্টারফেস পদ্ধতিও কার্যকর করে। আমার নিয়োগকর্তার কোড বেস এবং আমার নিজস্ব প্রকল্পগুলিতে, আমার দীর্ঘদিন ধরে অভ্যাস ছিল কেবলমাত্র পূর্বের - বাস্তবায়িত বিমূর্ত পদ্ধতিগুলির জন্য @ ওভাররাইড ব্যবহার করার। তবে, অভ্যাসটি পুনর্বিবেচনা করলে উভয় ক্ষেত্রে টীকা ব্যবহারের যোগ্যতা স্পষ্ট হয়ে যায়। আরও ভার্বোজ হওয়া সত্ত্বেও, এটি ভঙ্গুর বেস শ্রেণীর সমস্যা (সি ++ এর মতো গুরুতর নয় - সম্পর্কিত উদাহরণগুলি) রক্ষা করে যেখানে ইন্টারফেস পদ্ধতির নাম পরিবর্তিত হয়, প্রাপ্ত উপায়ে প্রাপ্ত ক্লাসে প্রয়োগকারী পদ্ধতিটি অনাথ করা হয়।
অবশ্যই এই দৃশ্যটি বেশিরভাগ ক্ষেত্রে হাইপারবোল; উদ্ভূত শ্রেণীর আর সংকলন হবে না, এখন নাম পরিবর্তন করা ইন্টারফেস পদ্ধতি বাস্তবায়নের অভাব, এবং আজ সম্ভবত একটি পুরো নাম বেস ম্যাসেজ সম্বোধন করার জন্য একটি পুনর্নবীকরণ পদ্ধতি রিফ্যাক্টরিং অপারেশন ব্যবহার করবে ।
প্রদত্ত আইডিইএর পরিদর্শন বাস্তবায়িত ইন্টারফেস পদ্ধতি উপেক্ষা করার জন্য কনফিগারযোগ্য নয়, আজ আমি আমার অভ্যাস এবং আমার দলের কোড পর্যালোচনার মানদণ্ড উভয়ই পরিবর্তন করব।
বিকাশকারী কী প্যারেন্ট ক্লাস বা ইন্টারফেসে সঠিক পদ্ধতিটি ওভাররাইড করতে হবে তা যাচাই করতে সাহায্য করতে টীকা @ ওভাররাইড ব্যবহার করা হয়। যখন সুপারের পদ্ধতির নাম পরিবর্তন হয়, সংকলক সেই ক্ষেত্রে বিষয়টি অবহিত করতে পারে, যা কেবল সুপার এবং সাবক্লাসের সাথে সামঞ্জস্য রাখার জন্য।
বিটিডাব্লু, যদি আমরা সাবক্লাসে @ ওভাররাইড টিকাটি ঘোষণা না করে, তবে আমরা সুপারের কয়েকটি পদ্ধতি ওভাররাইড করি, তবে ফাংশনটি @ ওভাররাইড দিয়ে সেই হিসাবে কাজ করতে পারে। যখন সুপারের পদ্ধতিটি পরিবর্তন করা হয়েছিল তখন এই পদ্ধতিটি বিকাশকারীকে অবহিত করতে পারে না। কারণ এটি বিকাশকারীর উদ্দেশ্য জানত না - সুপারের পদ্ধতিটি ওভাররাইড করে বা কোনও নতুন পদ্ধতি সংজ্ঞায়িত করে?
সুতরাং যখন আমরা পলিমারফিজমটি ব্যবহার করতে সেই পদ্ধতিটি ওভাররাইড করতে চাই তখন আমাদের পদ্ধতির উপরে @ ওভাররাইড যুক্ত করা আরও ভাল।
যখন কোনও পদ্ধতির উপর চাপ দেওয়া হচ্ছে তখন সনাক্ত করতে আমি এটি যথাসাধ্য ব্যবহার করি। আপনি যদি স্কালা প্রোগ্রামিং ভাষার দিকে তাকান তবে তাদের একটি ওভাররাইড কীওয়ার্ডও রয়েছে। আমি এটি দরকারী মনে করি।
টীকা সংকলনকারীকে কোড সম্পর্কে মেটা ডেটা সরবরাহ করে এবং এনটোটেশন @ ওভাররাইড উত্তরাধিকারের ক্ষেত্রে ব্যবহৃত হয় যখন আমরা বেস ক্লাসের যে কোনও পদ্ধতিকে ওভাররাইড করি। এটি কেবল সংকলককে বলে যে আপনি পদ্ধতিটিকে ওভাররাইড করছেন। এটি পদ্ধতির যথাযথ স্বাক্ষর অনুসরণ না করা বা পদ্ধতির নামে ভুল বানান ইত্যাদি যেমন আমরা করতে পারি এমন কিছু সাধারণ ভুল এড়ানো যেতে পারে তাই @ ওভাররাইড টীকাটি ব্যবহার করা এটির একটি ভাল অভ্যাস।