ฉันควรแค็ปซูลโครงสร้างข้อมูลภายในทั้งหมดหรือไม่

โปรดพิจารณาคลาสนี้:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThings(){
        return things;
    }

}

คลาสนี้จะเปิดเผยอาร์เรย์ที่ใช้ในการจัดเก็บข้อมูลรหัสลูกค้าใด ๆ ที่สนใจ

ฉันทำสิ่งนี้ในแอปที่ฉันทำงานอยู่ ฉันมีChordProgressionคลาสที่เก็บลำดับของChords (และทำสิ่งอื่น) มันมีChord[] getChords()วิธีที่คืนค่าอาร์เรย์ของคอร์ด เมื่อโครงสร้างข้อมูลต้องเปลี่ยน (จากอาร์เรย์เป็น ArrayList) รหัสไคลเอ็นต์ทั้งหมดจะพัง

นี่ทำให้ฉันคิดว่า - วิธีต่อไปนี้อาจจะดีกว่า:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThing(int index){
        return things[index];
    }

    public int getDataSize(){
        return things.length;
    }

    public void setThing(int index, Thing thing){
        things[index] = thing;
    }

}

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

เมื่อโครงสร้างข้อมูลเปลี่ยนแปลงวิธีการเหล่านี้เท่านั้นที่ต้องเปลี่ยน - แต่หลังจากทำแล้วรหัสลูกค้าทั้งหมดยังคงใช้งานได้

โปรดทราบว่าการรวบรวมที่ซับซ้อนกว่าอาร์เรย์อาจต้องใช้คลาสที่ล้อมรอบเพื่อใช้วิธีการมากกว่าสามวิธีในการเข้าถึงโครงสร้างข้อมูลภายใน

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

รหัสเช่น:

   public Thing[] getThings(){
        return things;
    }

ไม่สมเหตุสมผลนักเนื่องจากวิธีการเข้าถึงของคุณไม่ได้ทำอะไรเลย แต่ส่งคืนโครงสร้างข้อมูลภายในโดยตรง คุณอาจมีเพียงการประกาศให้เป็นThing[] things publicแนวคิดเบื้องหลังวิธีการเข้าถึงคือการสร้างอินเทอร์เฟซที่ป้องกันลูกค้าจากการเปลี่ยนแปลงภายในและขัดขวางพวกเขาจากการจัดการโครงสร้างข้อมูลจริงยกเว้นในวิธีที่รอบคอบตามที่ได้รับอนุญาตจากอินเตอร์เฟส เมื่อคุณค้นพบเมื่อรหัสลูกค้าทั้งหมดของคุณแตกวิธีการเข้าถึงของคุณไม่ได้ทำเช่นนั้น - มันเป็นเพียงแค่โค้ดที่เสียไป ฉันคิดว่าโปรแกรมเมอร์จำนวนมากมักเขียนโค้ดแบบนี้เพราะพวกเขาได้เรียนรู้ว่าทุกสิ่งจำเป็นต้องห่อหุ้มด้วยวิธีการเข้าถึง - แต่นั่นเป็นเหตุผลที่ฉันอธิบาย ทำเพียงเพื่อ "ติดตามแบบฟอร์ม" เมื่อวิธีการเข้าถึงไม่ได้ให้บริการเพื่อจุดประสงค์ใด ๆ เป็นเพียงจุดรบกวน

ฉันขอแนะนำวิธีแก้ปัญหาที่เสนอของคุณซึ่งบรรลุเป้าหมายที่สำคัญที่สุดของการห่อหุ้ม: ทำให้ลูกค้ามีอินเทอร์เฟซที่แข็งแกร่งและรอบคอบที่ป้องกันพวกเขาจากรายละเอียดการใช้งานภายในห้องเรียนของคุณและไม่อนุญาตให้พวกเขาสัมผัสโครงสร้างข้อมูลภายใน คาดหวังในวิธีที่คุณตัดสินใจว่ามีความเหมาะสม - "กฎหมายของสิทธิพิเศษที่จำเป็นน้อยที่สุด" หากคุณดูกรอบ OOP ยอดนิยมที่มีขนาดใหญ่เช่น CLR, STL, VCL รูปแบบที่คุณเสนอนั้นเป็นที่แพร่หลายด้วยเหตุผลดังกล่าว

คุณควรทำเช่นนั้นเสมอ ไม่จำเป็น. ตัวอย่างเช่นหากคุณมีคลาสผู้ช่วยหรือเพื่อนที่เป็นส่วนประกอบของคลาสคนงานหลักของคุณและไม่ใช่ "การเผชิญหน้ากับด้านหน้า" คุณก็ไม่จำเป็น - มันเป็น overkill ที่จะเพิ่มรหัสที่ไม่จำเป็นจำนวนมาก และในกรณีนี้ฉันจะไม่ใช้วิธีการเข้าถึงเลย - มันไม่มีเหตุผลตามที่อธิบาย เพียงประกาศโครงสร้างข้อมูลในแบบที่กำหนดขอบเขตให้กับคลาสหลักที่ใช้เท่านั้น - ภาษาส่วนใหญ่รองรับวิธีการทำเช่นนั้น - friendหรือประกาศในไฟล์เดียวกันกับคลาสของผู้ปฏิบัติงานหลักเป็นต้น

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

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

โปรดทราบว่าการรวบรวมที่ซับซ้อนกว่าอาร์เรย์อาจต้องใช้คลาสที่ล้อมรอบเพื่อใช้วิธีการมากกว่าสามวิธีในการเข้าถึงโครงสร้างข้อมูลภายใน

หากคุณเปิดเผยโครงสร้างข้อมูลทั้งหมดผ่านคลาสที่มี IMO คุณต้องคิดว่าเหตุใดคลาสดังกล่าวจึงถูกห่อหุ้มอยู่ทั้งหมดหากไม่ใช่เพียงแค่ให้อินเทอร์เฟซที่ปลอดภัยกว่า - "wrapper class" คุณกำลังบอกว่าคลาสที่มีอยู่นั้นไม่มีอยู่สำหรับจุดประสงค์นั้น - ดังนั้นอาจมีบางอย่างไม่ถูกต้องเกี่ยวกับการออกแบบของคุณ พิจารณาแบ่งชั้นเรียนของคุณออกเป็นโมดูลที่รอบคอบมากขึ้น

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

คุณถาม:ฉันควรแค็ปซูลโครงสร้างข้อมูลภายในทั้งหมด?

คำตอบสั้น ๆ :ใช่เวลาส่วนใหญ่ แต่ไม่เสมอไป

คำตอบยาว:ฉันคิดว่าคลาสมีหมวดหมู่ดังต่อไปนี้:

1. คลาสที่แค็ปซูลข้อมูลอย่างง่าย ตัวอย่าง: จุด 2D มันง่ายที่จะสร้างฟังก์ชั่นสาธารณะที่ให้ความสามารถในการรับ / ตั้งค่าพิกัด X และ Y แต่คุณสามารถซ่อนข้อมูลภายในได้อย่างง่ายดายโดยไม่มีปัญหามากเกินไป สำหรับคลาสดังกล่าวการเปิดเผยรายละเอียดโครงสร้างข้อมูลภายในจะไม่มีการเรียกใช้

2. คลาสคอนเทนเนอร์ที่รวบรวมแค็ปซูล STL มีคลาสคอนเทนเนอร์คลาสสิก ฉันพิจารณาstd::stringและstd::wstringในหมู่เหล่านั้นด้วย พวกเขาให้อินเตอร์เฟซที่อุดมไปด้วยการจัดการกับนามธรรม แต่std::vector, std::stringและstd::wstringยังมีความสามารถในการได้รับการเข้าถึงข้อมูลดิบ ฉันจะไม่รีบร้อนที่จะเรียกพวกมันว่าคลาสที่ออกแบบมาไม่ดี ฉันไม่ทราบเหตุผลในการเรียนเหล่านี้เปิดเผยข้อมูลดิบของพวกเขา อย่างไรก็ตามในการทำงานของฉันฉันพบว่ามันจำเป็นที่จะต้องเปิดเผยข้อมูลดิบเมื่อต้องรับมือกับโหนดโหนดจำนวนมากและข้อมูลบนโหนดโหนดเหล่านั้นด้วยเหตุผลด้านประสิทธิภาพ

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

3. คลาสที่ส่วนใหญ่ใช้งานได้ในธรรมชาติ ตัวอย่าง: std::istream,, ตัวstd::ostreamวนซ้ำของคอนเทนเนอร์ STL เป็นเรื่องโง่มากที่จะเปิดเผยรายละเอียดภายในของคลาสเหล่านี้

4. คลาสไฮบริด เหล่านี้เป็นชั้นเรียนที่แค็ปซูลโครงสร้างข้อมูลบางอย่าง แต่ยังมีฟังก์ชั่นอัลกอริทึม โดยส่วนตัวแล้วฉันคิดว่าสิ่งเหล่านี้เป็นผลมาจากการออกแบบความคิดที่ไม่ดี อย่างไรก็ตามหากคุณพบพวกเขาคุณต้องตัดสินใจว่ามันเหมาะสมที่จะเปิดเผยข้อมูลภายในของพวกเขาในแต่ละกรณี

โดยสรุป:ครั้งเดียวที่ฉันได้พบว่าจำเป็นต้องเปิดเผยโครงสร้างข้อมูลภายในของคลาสคือเมื่อมันกลายเป็นคอขวดของประสิทธิภาพ

แทนที่จะส่งคืนข้อมูลดิบโดยตรงลองทำสิ่งนี้

class ClassA {
  private Things[] things;
  ...
  public Things[] asArray() { return things; }
  public List<Thing> asList() { ... }
  ...
}

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

class ClassA {
  private List<Thing> things;
  ...
  public Things[] asArray() { return things.asArray(); }
  public List<Thing> asList() { return things; }
  ...
}

ตอนนี้คุณมีการห่อหุ้มที่เหมาะสมซ่อนรายละเอียดการใช้งานและให้ความเข้ากันได้ย้อนหลัง (มีค่าใช้จ่าย)

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

class ClassA{

    public ClassA(){
        things = new ArrayList<Thing>();
    }

    private List<Thing> things; // stores data

    // stuff omitted

    public List<Thing> getThings(){
        return things;
    }

}

วิธีการที่คุณสามารถเปลี่ยนArrayListไปLinkedListหรือสิ่งอื่นใดและคุณจะไม่ทำลายรหัสใด ๆ เนื่องจากทุกคอลเลกชัน Java (ข้างอาร์เรย์) ที่ได้ (หลอก?) Listเข้าถึงโดยสุ่มอาจจะดำเนินการ

นอกจากนี้คุณยังสามารถใช้Collectionวิธีการที่น้อยกว่าListแต่สามารถรองรับคอลเลกชันโดยไม่ต้องเข้าถึงแบบสุ่มหรือIterableที่สามารถรองรับสตรีม แต่ไม่ได้มีวิธีการเข้าถึงมาก ...

นี่เป็นเรื่องปกติที่จะซ่อนโครงสร้างข้อมูลภายในของคุณจากโลกภายนอก บางครั้งมัน overkill เป็นพิเศษใน DTO ฉันแนะนำสิ่งนี้สำหรับแบบจำลองโดเมน หากจำเป็นต้องเปิดเผยให้คืนสำเนาที่ไม่เปลี่ยนรูป นอกจากนี้ฉันขอแนะนำให้สร้างอินเทอร์เฟซที่มีวิธีการเหล่านี้เช่นรับตั้งเอาออก ฯลฯ