Baseฉันได้เรียนฐาน มันมีอยู่สอง subclasses, และSub1 Sub2แต่ละคลาสย่อยมีวิธีเพิ่มเติมบางอย่าง ตัวอย่างเช่นSub1มีSandwich makeASandwich(Ingredients... ingredients)และมีSub2boolean contactAliens(Frequency onFrequency)

เนื่องจากวิธีการเหล่านี้ใช้พารามิเตอร์ที่แตกต่างกันและทำสิ่งที่แตกต่างอย่างสิ้นเชิงพวกเขาไม่เข้ากันอย่างสมบูรณ์และฉันไม่สามารถใช้ความหลากหลายในการแก้ปัญหานี้ได้

Baseมอบการทำงานส่วนใหญ่และฉันมีBaseวัตถุจำนวนมาก อย่างไรก็ตามBaseวัตถุทั้งหมดเป็นแบบ a Sub1หรือ a Sub2และบางครั้งฉันจำเป็นต้องรู้ว่ามันคืออะไร

ดูเหมือนจะเป็นการดีที่จะทำสิ่งต่อไปนี้:

for (Base base : bases) {
    if (base instanceof Sub1) {
        ((Sub1) base).makeASandwich(getRandomIngredients());
        // ... etc.
    } else { // must be Sub2
        ((Sub2) base).contactAliens(getFrequency());
        // ... etc.
    }
}

ดังนั้นฉันจึงคิดกลยุทธ์เพื่อหลีกเลี่ยงสิ่งนี้โดยไม่ต้องร่าย Baseตอนนี้มีวิธีการเหล่านี้:

boolean isSub1();
Sub1 asSub1();
Sub2 asSub2();

และแน่นอนSub1ใช้วิธีการเหล่านี้เป็น

boolean isSub1() { return true; }
Sub1 asSub1();   { return this; }
Sub2 asSub2();   { throw new IllegalStateException(); }

และSub2นำไปใช้ในทางตรงกันข้าม

น่าเสียดายที่ตอนนี้Sub1และSub2มีวิธีการเหล่านี้ใน API ของตัวเอง Sub1ดังนั้นผมจึงสามารถทำเช่นนี้เช่นบน

/** no need to use this if object is known to be Sub1 */
@Deprecated
boolean isSub1() { return true; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub1 asSub1();   { return this; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub2 asSub2();   { throw new IllegalStateException(); }

ด้วยวิธีนี้หากวัตถุเป็นที่รู้จักเพียง a Baseวิธีการเหล่านี้จะไม่เลิกใช้และสามารถใช้ในการ "cast" ตัวเองไปเป็นประเภทอื่นดังนั้นฉันจึงสามารถเรียกใช้เมธอด subclass ของมันได้ สิ่งนี้ดูสง่างามสำหรับฉัน แต่ในทางกลับกันฉันชอบใช้คำอธิบายประกอบที่ไม่เหมาะสมเป็นวิธี "ลบ" วิธีการออกจากชั้นเรียน

เนื่องจากSub1อินสแตนซ์จริงๆเป็น Base จึงเหมาะสมที่จะใช้การสืบทอดมากกว่าการห่อหุ้ม ฉันทำอะไรได้ดี มีวิธีที่ดีกว่าในการแก้ปัญหานี้หรือไม่?

มันไม่สมเหตุสมผลที่จะเพิ่มฟังก์ชั่นให้กับคลาสพื้นฐานดังที่แนะนำไว้ในคำตอบอื่น ๆ การเพิ่มฟังก์ชั่นเคสพิเศษจำนวนมากเกินไปอาจส่งผลให้เกิดการรวมส่วนประกอบที่ไม่เกี่ยวข้องเข้าด้วยกัน

ตัวอย่างเช่นฉันอาจมีAnimalคลาสพร้อมCatและDogคอมโพเนนต์ ถ้าฉันต้องการที่จะสามารถพิมพ์พวกเขาหรือแสดงพวกเขาใน GUI มันอาจ overkill สำหรับฉันที่จะเพิ่มrenderToGUI(...)และsendToPrinter(...)ชั้นฐาน

วิธีการที่คุณใช้โดยใช้การตรวจสอบประเภทและการปลดเปลื้องนั้นมีความเปราะบาง แต่อย่างน้อยก็แยกความกังวลออกจากกัน

อย่างไรก็ตามหากคุณพบว่าตัวเองทำเช็ค / คาสต์ประเภทนี้บ่อยครั้งตัวเลือกหนึ่งคือการใช้รูปแบบของผู้เยี่ยมชม / ส่งซ้ำสองครั้ง ดูเหมือนว่าจะเป็นแบบนี้:

public abstract class Base {
  ...
  abstract void visit( BaseVisitor visitor );
}

public class Sub1 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub1(this); }
}

public class Sub2 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub2(this); }
}

public interface BaseVisitor {
   void onSub1(Sub1 that);
   void onSub2(Sub2 that);
}

ตอนนี้รหัสของคุณกลายเป็น

public class ActOnBase implements BaseVisitor {
    void onSub1(Sub1 that) {
       that.makeASandwich(getRandomIngredients())
    }

    void onSub2(Sub2 that) {
       that.contactAliens(getFrequency());
    }
}

BaseVisitor visitor = new ActOnBase();
for (Base base : bases) {
    base.visit(visitor);
}

ประโยชน์หลักคือถ้าคุณเพิ่มคลาสย่อยคุณจะได้รับข้อผิดพลาดในการรวบรวมมากกว่ากรณีหายไปอย่างเงียบ ๆ คลาสผู้เยี่ยมชมใหม่จะกลายเป็นเป้าหมายที่ดีในการดึงฟังก์ชั่นเข้ามา ตัวอย่างเช่นมันอาจเข้าท่าที่จะย้ายgetRandomIngredients()เข้าActOnBaseมา

คุณยังสามารถแยกลอจิกวนลูป: ตัวอย่างเช่นส่วนย่อยด้านบนอาจกลายเป็น

BaseVisitor.applyToArray(bases, new ActOnBase() );

การนวดเพิ่มเติมเล็กน้อยและการใช้ lambdas และการสตรีมของ Java 8 จะทำให้คุณไปถึงได้

bases.stream()
     .forEach( BaseVisitor.forEach(
       Sub1 that -> that.makeASandwich(getRandomIngredients()),
       Sub2 that -> that.contactAliens(getFrequency())
     ));

IMO ตัวไหนที่ดูเรียบร้อยและรวบรัดที่สุดเท่าที่จะทำได้

นี่คือตัวอย่างที่สมบูรณ์ของ Java 8:

public static abstract class Base {
    abstract void visit( BaseVisitor visitor );
}

public static class Sub1 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub1(this); }

    void makeASandwich() {
        System.out.println("making a sandwich");
    }
}

public static class Sub2 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub2(this); }

    void contactAliens() {
        System.out.println("contacting aliens");
    }
}

public interface BaseVisitor {
    void onSub1(Sub1 that);
    void onSub2(Sub2 that);

    static Consumer<Base> forEach(Consumer<Sub1> sub1, Consumer<Sub2> sub2) {

        return base -> {
            BaseVisitor baseVisitor = new BaseVisitor() {

                @Override
                public void onSub1(Sub1 that) {
                    sub1.accept(that);
                }

                @Override
                public void onSub2(Sub2 that) {
                    sub2.accept(that);
                }
            };
            base.visit(baseVisitor);
        };
    }
}

Collection<Base> bases = Arrays.asList(new Sub1(), new Sub2());

bases.stream()
     .forEach(BaseVisitor.forEach(
             Sub1::makeASandwich,
             Sub2::contactAliens));

จากมุมมองของฉัน: การออกแบบของคุณเป็นสิ่งที่ผิด

แปลเป็นภาษาธรรมชาติคุณกำลังพูดต่อไปนี้:

ป.ร. ให้เรามีanimalsมีและ cats มีคุณสมบัติซึ่งเป็นเรื่องธรรมดาที่จะและ แต่นั่นไม่เพียงพอ: มีคุณสมบัติบางอย่างที่แตกต่างจากดังนั้นคุณต้อง subclassfishanimalscatsfishcatfish

ตอนนี้คุณมีปัญหาที่คุณลืมรูปแบบการเคลื่อนไหว ถูก ค่อนข้างง่าย:

for(Animal a : animals){
   if (a instanceof Fish) swim();
   if (a instanceof Cat) walk();
}

แต่นั่นเป็นการออกแบบที่ผิด วิธีที่ถูกต้องจะเป็น:

for(Animal a : animals){
    animal.move()
}

ที่ไหนmoveพฤติกรรมจะร่วมกันดำเนินการที่แตกต่างจากสัตว์แต่ละ

เนื่องจากวิธีการเหล่านี้ใช้พารามิเตอร์ที่แตกต่างกันและทำสิ่งที่แตกต่างอย่างสิ้นเชิงพวกเขาไม่เข้ากันอย่างสมบูรณ์และฉันไม่สามารถใช้ความหลากหลายในการแก้ปัญหานี้ได้

ซึ่งหมายความว่า: การออกแบบของคุณเสีย

คำแนะนำของฉัน: refactor Base, และSub1Sub2

เป็นการยากที่จะจินตนาการถึงสถานการณ์ที่คุณมีกลุ่มของสิ่งต่าง ๆ และต้องการให้พวกเขาทำแซนด์วิชหรือติดต่อมนุษย์ต่างดาว ในกรณีส่วนใหญ่ที่คุณพบการคัดเลือกนักแสดงคุณจะทำงานด้วยประเภทเดียว - เช่นในเสียงดังกราวคุณกรองชุดของโหนดสำหรับการประกาศที่getAsFunctionส่งกลับค่าที่ไม่เป็นโมฆะแทนที่จะทำบางสิ่งที่แตกต่างกันสำหรับแต่ละโหนดในรายการ

อาจเป็นไปได้ว่าคุณต้องการลำดับของการดำเนินการและไม่เกี่ยวข้องกับวัตถุที่ใช้ในการดำเนินการ

ดังนั้นแทนที่จะเป็นรายการ Baseให้ทำงานกับรายการการกระทำ

for (RandomAction action : actions)
   action.act(context);

ที่ไหน

interface RandomAction {
    void act(Context context);
} 

interface Context {
    Ingredients getRandomIngredients();
    double getFrequency();
}

คุณสามารถให้ Base ใช้เมธอดเพื่อส่งคืนการกระทำหรือวิธีการอื่นใดที่คุณต้องเลือกการกระทำจากอินสแตนซ์ในรายการฐานของคุณ (เนื่องจากคุณบอกว่าคุณไม่สามารถใช้ polymorphism ดังนั้นการกระทำที่จะทำ ไม่ใช่ฟังก์ชันของคลาส แต่มีคุณสมบัติอื่นของเบสไม่เช่นนั้นคุณจะให้เมธอดเบส (บริบท) กับเบส

ถ้าคุณมี subclasses ของคุณใช้หนึ่งหรือมากกว่าหนึ่งอินเตอร์เฟสที่กำหนดสิ่งที่พวกเขาสามารถทำได้? บางสิ่งเช่นนี้

interface SandwichCook
{
    public void makeASandwich(String[] ingredients);
}

interface AlienRadioSignalAwarable
{
    public void contactAliens(int frequency);

}

จากนั้นคลาสของคุณจะมีลักษณะดังนี้:

class Sub1 extends Base implements SandwichCook
{
    public void makeASandwich(String[] ingredients)
    {
        //some code here
    }
}

class Sub2 extends Base implements AlienRadioSignalAwarable
{
    public void contactAliens(int frequency)
    {
        //some code here
    }
}

และ for-loop ของคุณจะกลายเป็น:

for (Base base : bases) {
    if (base instanceof SandwichCook) {
        base.makeASandwich(getRandomIngredients());
    } else if (base instanceof AlienRadioSignalAwarable) {
        base.contactAliens(getFrequency());
    }
}

ข้อดีสองประการที่สำคัญสำหรับวิธีการนี้:

• ไม่มีส่วนเกี่ยวข้องกับการคัดเลือกนักแสดง
• คุณสามารถให้แต่ละคลาสย่อยใช้อินเทอร์เฟซได้มากเท่าที่คุณต้องการซึ่งจะให้ความยืดหยุ่นสำหรับการเปลี่ยนแปลงในอนาคต

PS: ขออภัยสำหรับชื่อของอินเทอร์เฟซฉันไม่สามารถนึกถึงอะไรที่เจ๋งกว่าในขณะนั้น: D

วิธีการที่อาจจะเป็นหนึ่งที่ดีในกรณีที่เกือบทุกประเภทใด ๆ ภายในครอบครัวจะอย่างใดอย่างหนึ่งได้โดยตรงสามารถใช้งานได้ในฐานะที่เป็นอินเตอร์เฟซการดำเนินงานของบางอย่างที่มีคุณสมบัติตรงตามเกณฑ์บางส่วนหรือสามารถนำมาใช้ในการสร้างการดำเนินงานของอินเตอร์เฟซที่ ประเภทคอลเลกชันในตัว IMHO จะได้รับประโยชน์จากรูปแบบนี้ แต่เนื่องจากพวกเขาไม่ใช้เพื่อจุดประสงค์เช่นฉันจะคิดค้นส่วนต่อประสานการรวบรวมBunchOfThings<T>แต่เนื่องจากพวกเขาไม่ได้สำหรับวัตถุประสงค์ของตัวอย่างเช่นฉันจะคิดค้นอินเตอร์เฟซคอลเลกชัน

การใช้งานบางอย่างของBunchOfThingsไม่แน่นอน บางคนไม่ ในหลายกรณีวัตถุ Fred อาจต้องการเก็บสิ่งที่สามารถใช้เป็นBunchOfThingsและรู้ว่าไม่มีอะไรอื่นนอกจาก Fred จะสามารถแก้ไขได้ ข้อกำหนดนี้อาจทำได้สองวิธี:

1. เฟร็ดรู้ว่ามันมีเพียงการอ้างอิงถึงสิ่งBunchOfThingsนั้นและไม่มีการอ้างอิงภายนอกกับไออาร์ว่าBunchOfThingsมันมีอยู่ภายในทุกที่ในจักรวาล หากไม่มีใครมีการอ้างอิงถึงBunchOfThingsหรือภายในก็จะไม่มีใครสามารถแก้ไขได้ดังนั้นข้อ จำกัด จะเป็นที่พอใจ

2. ไม่BunchOfThingsสามารถแก้ไขหรืออ้างอิงภายในใด ๆ ที่มีการอ้างอิงภายนอกด้วยวิธีการใด ๆ หากไม่มีใครสามารถแก้ไข a ได้BunchOfThingsแน่นอนข้อ จำกัด จะเป็นที่พอใจ

วิธีหนึ่งในการทำให้พอใจข้อ จำกัด คือการคัดลอกวัตถุใด ๆ ที่ได้รับโดยไม่มีเงื่อนไข (การประมวลผลคอมโพเนนต์ที่ซ้อนกันซ้ำ ๆ ) อีกสิ่งหนึ่งคือการทดสอบว่าวัตถุที่ได้รับสัญญาว่าไม่สามารถเปลี่ยนแปลงได้หรือไม่และทำสำเนาของวัตถุนั้นและทำเช่นเดียวกันกับองค์ประกอบที่ซ้อนกัน อีกทางเลือกหนึ่งซึ่งจะสะอาดกว่าครั้งที่สองและเร็วกว่าครั้งแรกคือเสนอAsImmutableวิธีการที่ขอให้วัตถุทำสำเนาตัวเองที่ไม่เปลี่ยนรูป (ใช้AsImmutableกับส่วนประกอบที่ซ้อนกันที่สนับสนุน)

อาจมีการจัดเตรียมวิธีการที่เกี่ยวข้องasDetached(สำหรับใช้เมื่อรหัสได้รับวัตถุและไม่ทราบว่าจะต้องทำการกลายพันธุ์หรือไม่ในกรณีนี้วัตถุที่เปลี่ยนแปลงได้ควรถูกแทนที่ด้วยวัตถุที่เปลี่ยนแปลงได้ใหม่ แต่วัตถุที่ไม่เปลี่ยนรูปสามารถเก็บได้ ตามที่เป็น), asMutable(ในกรณีที่วัตถุรู้ว่ามันจะเก็บวัตถุก่อนหน้านี้ส่งคืนจากasDetachedเช่นการอ้างอิงที่ไม่ได้ใช้งานร่วมกันไปยังวัตถุที่ไม่แน่นอนหรือการอ้างอิงที่ใช้ร่วมกันได้กับวัตถุที่ไม่แน่นอน)asNewMutable (ในกรณีที่รหัสได้รับภายนอก การอ้างอิงและรู้ว่ามันจะต้องการที่จะกลายพันธุ์สำเนาของข้อมูลในนั้น - หากข้อมูลที่เข้ามาไม่แน่นอนไม่มีเหตุผลที่จะเริ่มต้นด้วยการทำสำเนาไม่เปลี่ยนรูปซึ่งจะถูกนำมาใช้ทันทีเพื่อสร้างสำเนาที่ไม่แน่นอนและถูกทอดทิ้ง)

โปรดทราบว่าในขณะที่asXXวิธีการอาจส่งคืนชนิดที่แตกต่างกันเล็กน้อยบทบาทที่แท้จริงของพวกเขาคือเพื่อให้แน่ใจว่าวัตถุที่ส่งคืนจะตอบสนองความต้องการของโปรแกรม

ไม่สนใจว่าคุณจะมีการออกแบบที่ดีหรือไม่และหากว่ามันดีหรืออย่างน้อยก็ยอมรับได้ฉันอยากจะพิจารณาความสามารถของคลาสย่อยไม่ใช่ประเภท

ดังนั้นทั้ง:

ย้ายความรู้เกี่ยวกับการดำรงอยู่ของแซนวิชและเอเลี่ยนลงในคลาสฐานแม้ว่าคุณจะรู้ว่าอินสแตนซ์บางตัวของคลาสพื้นฐานไม่สามารถทำได้ ใช้มันในคลาสฐานเพื่อโยนข้อยกเว้นและเปลี่ยนรหัสเป็น:

if (base.canMakeASandwich()) {
    base.makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    base.contactAliens(getFrequency());
    // ... etc.
}

จากนั้นหนึ่งหรือทั้งสอง subclasses แทนที่canMakeASandwich()และเพียงหนึ่งการดำเนินการแต่ละและmakeASandwich()contactAliens()

ใช้อินเตอร์เฟสไม่ใช่คลาสย่อยที่เป็นรูปธรรมในการตรวจสอบความสามารถของชนิดที่มี ออกจากคลาสฐานเพียงอย่างเดียวและเปลี่ยนรหัสเป็น:

if (base instanceof SandwichMaker) {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    ((AlienContacter)base).contactAliens(getFrequency());
    // ... etc.
}

หรืออาจเป็นไปได้ (และอย่าลังเลที่จะเพิกเฉยตัวเลือกนี้หากมันไม่เหมาะกับสไตล์ของคุณหรือสำหรับสไตล์ Java ที่คุณคิดว่าเหมาะสม)

try {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
} catch (ClassCastException e) {
    ((AlienContacter)base).contactAliens(getFrequency());
}

ส่วนตัวผมไม่ได้มักจะชอบสไตล์หลังของการจับข้อยกเว้นครึ่งคาดว่าเพราะความเสี่ยงของการไม่เหมาะสมจับที่ClassCastExceptionออกมาของgetRandomIngredientsหรือmakeASandwichแต่ YMMV

ที่นี่เรามีกรณีที่น่าสนใจของคลาสฐานที่ downcasts ตัวเองไปยังคลาสที่ได้รับของตัวเอง เรารู้ดีว่านี่เป็นเรื่องไม่ดี แต่ถ้าเราต้องการบอกว่าเราพบเหตุผลที่ดีให้เราดูและดูว่าข้อ จำกัด ของเรื่องนี้คืออะไร:

1. เราสามารถครอบคลุมทุกกรณีในคลาสฐาน
2. ไม่มีคลาสที่ได้รับจากต่างประเทศจะต้องเพิ่มเคสใหม่
3. เราสามารถอยู่กับนโยบายที่การเรียกเพื่อให้อยู่ภายใต้การควบคุมของคลาสพื้นฐาน
4. แต่เรารู้จากวิทยาศาสตร์ของเราว่านโยบายของสิ่งที่ต้องทำในชั้นเรียนที่ได้รับมาสำหรับวิธีการที่ไม่ได้อยู่ในชั้นฐานคือชั้นเรียนที่ได้รับไม่ใช่ชั้นเรียนพื้นฐาน

ถ้า 4 เรามี: 5. นโยบายของชนชั้นที่ได้รับอยู่ภายใต้การควบคุมทางการเมืองเช่นเดียวกับนโยบายของชนชั้นฐานเสมอ

2 และ 5 ทั้งสองบอกเป็นนัยโดยตรงว่าเราสามารถระบุคลาสที่ได้รับทั้งหมดซึ่งหมายความว่าไม่ควรมีคลาสที่ได้รับภายนอก

แต่นี่คือสิ่งที่ หากเป็นของคุณทั้งหมดคุณสามารถแทนที่ if ด้วย abstraction ที่เป็นการเรียกเมธอดเสมือน (แม้ว่าจะเป็นเรื่องไร้สาระ) และกำจัด if และ cast ด้วยตนเอง ดังนั้นอย่าทำ มีการออกแบบที่ดีกว่า

ใส่วิธีนามธรรมในคลาสฐานซึ่งทำสิ่งหนึ่งใน Sub1 และอีกอย่างใน Sub2 และเรียกวิธีนามธรรมนั้นในลูปผสมของคุณ

class Sub1 : Base {
    @Override void doAThing() {
        this.makeASandwich(getRandomIngredients());
    }
}

class Sub2 : Base {
    @Override void doAThing() {
        this.contactAliens(getFrequency());
    }
}

for (Base base : bases) {
    base.doAThing();
}

โปรดทราบว่าสิ่งนี้อาจต้องมีการเปลี่ยนแปลงอื่น ๆ ขึ้นอยู่กับวิธีกำหนด getRandomIngredients และ getFrequency แต่โดยความจริงแล้วในชั้นเรียนที่ติดต่อกับมนุษย์ต่างดาวน่าจะเป็นสถานที่ที่ดีกว่าในการนิยาม getFrequency

อนึ่งวิธี asSub1 และ asSub2 ของคุณนั้นเป็นวิธีปฏิบัติที่ไม่ดีอย่างแน่นอน หากคุณกำลังจะทำสิ่งนี้ให้ทำโดยการคัดเลือกนักแสดง ไม่มีวิธีการใดที่ทำให้คุณหล่อไม่ได้

คุณสามารถผลักดันทั้งสองmakeASandwichและcontactAliensเข้าไปในชั้นฐานแล้วใช้พวกเขากับการใช้งานหุ่น เนื่องจากประเภท / อาร์กิวเมนต์ส่งคืนไม่สามารถแก้ไขเป็นคลาสพื้นฐานทั่วไปได้

class Sub1 extends Base{
    Sandwich makeASandwich(Ingredients i){
        //Normal implementation
    }
    boolean contactAliens(Frequency onFrequency){
        return false;
    }
 }
class Sub2 extends Base{
    Sandwich makeASandwich(Ingredients i){
        return null;
    }
    boolean contactAliens(Frequency onFrequency){
       // normal implementation
    }
 }

มีข้อเสียที่เห็นได้ชัดสำหรับสิ่งต่าง ๆ เช่นสิ่งที่หมายถึงสัญญาของวิธีการและสิ่งที่คุณสามารถและไม่สามารถอนุมานเกี่ยวกับบริบทของผลลัพธ์ คุณไม่สามารถคิดได้เพราะฉันไม่ได้ทำแซนวิชส่วนผสมก็หมดไปในความพยายาม ฯลฯ

สิ่งที่คุณกำลังทำนั้นถูกกฎหมายอย่างสมบูรณ์ อย่าให้ความสนใจกับผู้ที่มีความสำคัญกับลัทธิชาวต่างชาติเพราะพวกเขาอ่านมันในหนังสือบางเล่ม Dogma ไม่มีที่ในด้านวิศวกรรม

ฉันใช้กลไกเดียวกันสองสามครั้งและฉันสามารถพูดด้วยความมั่นใจว่า java runtime สามารถทำสิ่งเดียวกันได้อย่างน้อยในที่เดียวที่ฉันสามารถคิดได้ดังนั้นจึงเป็นการเพิ่มประสิทธิภาพการใช้งานและการอ่านโค้ดที่ ใช้มัน

ยกตัวอย่างเช่นjava.lang.reflect.Memberซึ่งเป็นฐานของjava.lang.reflect.Fieldและjava.lang.reflect.Methodและ(ลำดับชั้นที่เกิดขึ้นจริงนั้นซับซ้อนกว่านั้นเล็กน้อย แต่มันไม่เกี่ยวข้องเลย) เขตข้อมูลและวิธีการเป็นสัตว์ที่แตกต่างกันอย่างมากมาย: หนึ่งมีค่าที่คุณสามารถได้รับหรือตั้งค่าในขณะที่คนอื่นไม่มีสิ่งนั้น แต่มันสามารถเรียก จำนวนพารามิเตอร์และมันอาจส่งกลับค่า ดังนั้นเขตข้อมูลและวิธีการเป็นทั้งสมาชิก แต่สิ่งที่คุณสามารถทำได้กับพวกเขาเกี่ยวกับความแตกต่างจากกันและกันเช่นการทำแซนวิชและการติดต่อกับมนุษย์ต่างดาว

ตอนนี้เมื่อเขียนโค้ดที่ใช้การสะท้อนเรามักจะมีMemberในมือของเราและเรารู้ว่ามันเป็นMethodหรือField(หรือไม่ค่อยมีอะไรอย่างอื่น) และเราต้องทำทุกอย่างที่น่าเบื่อinstanceofเพื่อหาอย่างแม่นยำ มันคืออะไรแล้วเราต้องโยนมันเพื่อรับการอ้างอิงที่เหมาะสม (และนี่ไม่เพียง แต่น่าเบื่อ แต่ยังไม่ได้ผลดีมาก)Methodชั้นเรียนสามารถใช้รูปแบบที่คุณอธิบายได้ง่ายมากซึ่งจะทำให้ชีวิตของโปรแกรมเมอร์นับพันง่ายขึ้น

แน่นอนว่าเทคนิคนี้ใช้ได้เฉพาะในลำดับชั้นเล็ก ๆ ที่กำหนดไว้อย่างดีของคลาสที่มีการเชื่อมโยงอย่างใกล้ชิดซึ่งคุณมี (และจะมี) การควบคุมระดับซอร์สของ: คุณไม่ต้องการทำสิ่งนี้หากลำดับชั้นของคลาสของคุณคือ มีแนวโน้มที่จะขยายออกไปโดยคนที่ไม่มีอิสระที่จะ refactor ชั้นฐาน

นี่คือสิ่งที่ฉันได้ทำแตกต่างจากสิ่งที่คุณทำ:

• ชั้นฐานให้การเริ่มต้นใช้งานสำหรับทั้งครอบครัวของวิธีการหนึ่งที่มีผลตอบแทนพวกเขาในแต่ละasDerivedClass()null

• แต่ละชั้นมาเฉพาะแทนที่หนึ่งในasDerivedClass()วิธีการที่กลับมาแทนthis nullมันไม่ได้แทนที่ส่วนที่เหลือใด ๆ และไม่ต้องการรู้อะไรเกี่ยวกับพวกเขา ดังนั้นจึงไม่มีการIllegalStateExceptionโยน

• คลาสพื้นฐานยังจัดให้มีfinalการใช้งานสำหรับวิธีการทั้งisDerivedClass()ตระกูลตามลำดับดังนี้: return asDerivedClass() != null; วิธีนี้จำนวนวิธีการที่จำเป็นต้อง overriden โดยคลาสที่ได้รับจะถูกย่อให้เล็กสุด

• ฉันไม่ได้ใช้@Deprecatedในกลไกนี้เพราะฉันไม่ได้คิด ตอนนี้คุณให้ความคิดกับฉันแล้วฉันจะใช้มันขอบคุณ!

C # มีกลไกที่เกี่ยวข้องในตัวผ่านการใช้asคำหลัก ใน C # คุณสามารถพูดDerivedClass derivedInstance = baseInstance as DerivedClassและคุณจะได้รับการอ้างอิงถึงDerivedClassถ้าคุณbaseInstanceอยู่ในชั้นเรียนนั้นหรือnullถ้ามันไม่ได้ (ในทางทฤษฎี) นี้ทำงานได้ดีกว่าisตามด้วย cast ( isเป็นคำหลักที่ยอมรับได้ดีกว่า C # สำหรับinstanceof,) แต่กลไกที่กำหนดเองที่เราได้ทำการประดิษฐ์ด้วยมือนั้นทำได้ดียิ่งขึ้น: คู่ของinstanceof- and-cast ปฏิบัติการของ Java เช่นกัน เนื่องจากasโอเปอเรเตอร์ของ C # ไม่ดำเนินการอย่างรวดเร็วเท่ากับการเรียกใช้เมธอดเสมือนเดียวของวิธีการที่กำหนดเอง

ฉันขอยกข้อเสนอที่ว่าเทคนิคนี้ควรถูกประกาศว่าเป็นรูปแบบและพบชื่อที่ดีสำหรับมัน

Gee ขอบคุณสำหรับ downvotes!

บทสรุปของการโต้เถียงเพื่อช่วยคุณจากปัญหาในการอ่านความคิดเห็น:

การคัดค้านของผู้คนดูเหมือนว่าการออกแบบดั้งเดิมนั้นไม่ถูกต้องซึ่งหมายความว่าคุณไม่ควรมีคลาสที่แตกต่างกันอย่างมากมายซึ่งมาจากคลาสพื้นฐานทั่วไปหรือแม้ว่าคุณจะทำรหัสที่ใช้ลำดับชั้นนั้นไม่ควรอยู่ในตำแหน่งที่มี การอ้างอิงพื้นฐานและจำเป็นต้องคิดออกคลาสที่ได้รับ ดังนั้นพวกเขาจึงพูดว่ากลไกการหล่อตัวเองที่เสนอโดยคำถามนี้และโดยคำตอบของฉันซึ่งช่วยปรับปรุงการใช้งานการออกแบบดั้งเดิมไม่ควรมีความจำเป็นตั้งแต่แรก (พวกเขาไม่ได้พูดอะไรจริง ๆ เกี่ยวกับกลไกการหล่อตัวเองพวกเขาเพียงแค่บ่นเกี่ยวกับธรรมชาติของการออกแบบที่กลไกนั้นตั้งใจจะนำไปใช้)

อย่างไรก็ตามในตัวอย่างข้างต้นที่ผมได้อยู่แล้วแสดงให้เห็นว่าผู้สร้างของรันไทม์จาวาได้ในความเป็นจริงเลือกออกแบบได้อย่างแม่นยำเช่นสำหรับjava.lang.reflect.Member, Field, Methodลำดับชั้นและในการแสดงความคิดเห็นด้านล่างนี้ผมยังแสดงให้เห็นว่าผู้สร้างของ C รันไทม์ # ที่มาถึงอิสระที่เทียบเท่าการออกแบบสำหรับSystem.Reflection.MemberInfo, FieldInfo, MethodInfoลำดับชั้น ดังนั้นสิ่งเหล่านี้จึงเป็นสถานการณ์จำลองในโลกแห่งความจริงที่แตกต่างกันสองสถานการณ์ซึ่งอยู่ภายใต้จมูกของทุกคน

นั่นคือสิ่งที่ความคิดเห็นต่อไปนี้ทั้งหมดต้มลงไป กลไกการหล่อด้วยตนเองนั้นแทบจะไม่ได้กล่าวถึง