یک اینترفیس دو کلاس مشتقش شده ازش و دو متد همنام با پارامترهایی از این دو کلاس!

سلام
من یک اینترفیس دارم و دو کلاس که از این اینترفیس مشتق شده :

Interface A {}



class B implements A{ String name;}

calass C implements A{ String lastName;}

دو متد تو یک کلاسی مثل K دارم که اسماشون یکیه و پارمترهاش از نوع کلاس A و کلاس B هست.

class k {

        public void del(B b){

           delete(b.name);

        }

        public void del(C c){

           delete(c.lastName);

        }     }

توی یک کلاس دیگه مثل G :

class G{

  K k=new k();

  public void delete (A a){

  k.del(a); }

حالا من میخام یه شیء از کلاس G بسازم و وقتی یه شی از نوع کلاس B بهش دادم name رو حذف کنه و وقتی یه شیء از کلاس C بهش دادم last name رو مثلا حذف کنه !

G g=new g();

B b=new b();

g.delete(b)

چطوری میتونم اینکارو کنم ؟
ینی اصن امکانش هست بدون اینکه چند متد مختلف درست کنم و تو متد delete چک کنم ببینم که پارامتر از چه نوعی هست و متد مربوطه اجرا بشه خود جاوا بفهمه که متدی که فرستادم بهش از چه نوعیه ؟ مثلا چیزی شبیه فرستادن آرایه ها که با این روش میشه مشخص کرد از چه نوعیه

delete(List<? extends A>)

چیزی شبیه به این هست برای کلاس ها و پارمتر ها ؟

نه نمیشه. تو کلاس G به مشکل میخوری چون k.del باید مشخص کنی A کدوم هست. یعنی با cast کردن مشخص میکنی که دانسته داری A رو مثلا B یا C فرض میکنی و همون نقطه باید مشخص بشه.
البته اگر از IDE مثل Netbeans استفاده کنی، خودش اینا رو هشدار میده و اگر راه حلی داره مثل cast کردن میگه

ینی هیچ راهی نیست که خود جاوا بفهمه کدوم یکی از زیرکلاسا داره استفاده میشه ؟ پس چرا برای لیست ها هست مثه همین مثالی که زدم

delete(List<? extendsA>)

خودش میتونه تشخیص بده که کدوم کلاس از زیر کلاس های A استفاده شده .
چیزی شبیه به این نداریم

<?> calss A

یا

<?> extends A

یا همچین چیزی؟
ینی حتما باید مشخص کنم که اگه مثلا فلان کلاس instance of فلان کلاس بود این کارو بکن ؟

نقل قول:

---

ینی حتما باید مشخص کنم که اگه مثلا فلان کلاس instance of فلان کلاس بود این کارو بکن ؟

---

ببینید شما در متد del در کلاس K دو نوع B و C میگیرید. از طرفی در کلاس G متد delete یک نوع A رو میگیره. A چون مثل پدر B و C هست نمیتونه جای B و C بشینه چون مشخص نیست کدومشه و ممکنه هیچ کدوم نباشه اونوقت چی؟ ولی B و C راحت میتونن جای A بشینن همه جا.
در نتیجه فقط با cast کردن میتونید به کامپایلر بگید که خودم حواسم هست. فرض کنید یه کلاس دیگه دارید به اسم D که A رو implement میکنه. خب آبجکتی ازش بسازیم و به این متد delete بدیم، هیچ متدی متناظرش نیست و در حالی که هنگام کامپایل کردن هم بهمون هشداری داده نشده. پس با cast کردن به صورت واضح مسئولیتش رو میپذیریم و به کامپایلر میگیم بیخیال شو :لبخند:
اون مثال

delete(List<? extends A>)

هم با این متفاوته. چرا چون شما در متد delete برنامه رو جوری نوشتید که با A تطبیق داشته باشه و هر فرزندی از A هم میتونه جای این قرار بگیره. ولی در مثالی که خودتون زدید، در داخل delete از کلاسی به اسم K استفاده کردید که به B و C ارتباط پیدا کرده. که اینجور برنامه نویسی به نظر من اشتباهه. شما در سطح abstract یا بالاتر دارید در سطح A صحبت میکنید، بعد تو کد دوباره میایید در سطح پایینتر و فرزندان مورد استفاده قرار میدید. در صورتی که در هر سطحی، رو به بالا (پدر، پدر پدر) میشه کد نوشت ولی در جایی که سطح رو پدر هست، از فرزند نباید استفاده بشه. البته نباید مطلق نیست، چون کامپایلر با cast و... این امکان رو بهتون میده ولی با دقت اگر جایی لازم بود باید استفاده بشه که با instance of میشه چک کرد. همچنین همیشه چک کن instance of x و... و یه else هم میخواد چون ممکنه کلاسی باشه که انتظارش رو نداشتی فرزند A باشه.