ปัญหาเกี่ยวกับรูปแบบการเข้ารหัส: เราควรมีฟังก์ชั่นที่ใช้พารามิเตอร์แก้ไขหรือไม่แล้วกลับไปที่พารามิเตอร์นั้นหรือไม่

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

เรามีฟังก์ชั่นที่รับพารามิเตอร์เติมสมาชิกของมันแล้วส่งกลับ:

Item predictPrice(Item item)

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

เขาอ้างว่ามันไม่สร้างความแตกต่างและมันก็ไม่สำคัญว่ามันจะสร้างไอเท็มใหม่และคืนสิ่งนั้น ฉันไม่เห็นด้วยอย่างยิ่งด้วยเหตุผลดังต่อไปนี้:

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

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

• การจัดสรรฮีปอาจมีราคาแพงและดังนั้นจึงเป็นสิ่งสำคัญที่ฟังก์ชันที่เรียกใช้ทำเช่นนั้น

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

void predictPrice(Item item)

ในทุก codebase (ยอมรับกันว่า C และ C ++ codebases ไม่ใช่ภาษาจาวาซึ่งเป็นภาษาที่เรากำลังทำงานอยู่) ฉันได้ทำงานด้วยสไตล์ข้างต้นได้ยึดติดเป็นหลักและเก็บไว้โดยโปรแกรมเมอร์ที่มีประสบการณ์มากกว่า เขาอ้างว่าเนื่องจากขนาดตัวอย่างของโค๊ดเบสและเพื่อนร่วมงานของฉันนั้นเล็กมากจากโค๊ดและเพื่อนร่วมงานที่เป็นไปได้ทั้งหมดดังนั้นประสบการณ์ของฉันจึงไม่มีตัวบ่งชี้ที่แท้จริงว่ามีใครเหนือกว่า

ดังนั้นความคิดใด ๆ

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

ฉันต้องการ (ตามลำดับ)

1. นั่นpredictPriceเป็นวิธีการItem (โมดูโลเป็นเหตุผลที่ดีที่ไม่ควรทำแบบนั้นโดยรวมของคุณ)

   • ส่งคืนราคาที่คาดการณ์หรือ

   • มีชื่อเหมือนsetPredictedPriceแทน

2. นั่นpredictPrice ไม่ได้แก้ไขItemแต่ส่งคืนราคาที่คาดการณ์ไว้

3. นั่นpredictPriceเป็นvoidวิธีการที่เรียกว่าsetPredictedPrice

4. ที่predictPriceส่งคืนthis(สำหรับวิธีการผูกมัดกับวิธีอื่นในอินสแตนซ์ของมัน) (และถูกเรียกsetPredictedPrice)

ภายในกระบวนทัศน์การออกแบบเชิงวัตถุสิ่งที่ไม่ควรปรับเปลี่ยนวัตถุนอกวัตถุเอง การเปลี่ยนแปลงสถานะของวัตถุใด ๆ ควรกระทำผ่านวิธีการบนวัตถุ

ดังนั้นvoid predictPrice(Item item)ในฐานะที่เป็นฟังก์ชั่นสมาชิกของชั้นเรียนอื่น ๆ บางอย่างที่ไม่ถูกต้อง อาจเป็นที่ยอมรับในยุคของ C แต่สำหรับ Java และ C ++ การดัดแปลงของวัตถุหมายถึงการมีเพศสัมพันธ์ที่ลึกซึ้งกับวัตถุที่อาจนำไปสู่ปัญหาการออกแบบอื่น ๆ ตามถนน (เมื่อคุณปรับโครงสร้างห้องเรียนและเปลี่ยนฟิลด์ ตอนนี้จำเป็นต้องเปลี่ยน 'คาดการณ์ราคา' เป็นไฟล์อื่น

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

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

มาดูกันว่าจะเกิดอะไรขึ้นถ้าคนที่เล่นซอกับฟิลด์ของบางอย่างในแฮช ให้ใช้รหัส:

import java.util.*;

public class Main {
    public static void main (String[] args) {
        Set set = new HashSet();
        Data d = new Data(1,"foo");
        set.add(d);
        set.add(new Data(2,"bar"));
        System.out.println(set.contains(d));
        d.field1 = 2;
        System.out.println(set.contains(d));
    }

    public static class Data {
        int field1;
        String field2;

        Data(int f1, String f2) {
            field1 = f1;
            field2 = f2;
        }

        public int hashCode() {
            return field2.hashCode() + field1;
        }

        public boolean equals(Object o) {
            if(!(o instanceof Data)) return false;
            Data od = (Data)o;
            return od.field1 == this.field1 && od.field2.equals(this.field2);

        }
    }
}

^ideone

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

ผลลัพธ์ของรหัสนี้คือ:

true
false

สิ่งที่เกิดขึ้นคือ hashCode ที่ใช้เมื่อมันถูกแทรกอยู่ที่ที่วัตถุอยู่ในแฮช การเปลี่ยนค่าที่ใช้ในการคำนวณ hashCode จะไม่คำนวณ hash อีกครั้ง นี่คืออันตรายของการวางวัตถุที่ไม่แน่นอนใด ๆเป็นกุญแจสำคัญในการแฮช

ดังนั้นกลับไปที่ลักษณะดั้งเดิมของคำถามวิธีการที่เรียกว่า "ไม่รู้" ว่าวัตถุได้รับอย่างไรเมื่อมีการใช้พารามิเตอร์ ให้ "ช่วยให้กลายพันธุ์วัตถุ" เป็นวิธีเดียวที่จะทำสิ่งนี้หมายความว่ามีจำนวนของข้อบกพร่องที่สามารถคืบคลานเข้ามา_{^{เช่นค่าสูญเสียในแฮช ... ถ้าคุณเพิ่มมากขึ้น นั่นเป็นข้อผิดพลาดที่น่ารังเกียจในการตามล่า (ฉันสูญเสียค่าจนกว่าฉันจะเพิ่ม 20 รายการเพิ่มเติมใน hashMap แล้วทันใดนั้นมันก็ปรากฏขึ้นอีกครั้ง)}}

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

ที่เกี่ยวข้อง: เขียนทับและส่งคืนค่าของอาร์กิวเมนต์ที่ใช้เป็นเงื่อนไขของคำสั่ง if ภายในคำสั่ง if เดียวกัน

ฉันมักจะทำตามแบบฝึกหัดที่จะไม่กลายพันธุ์วัตถุของคนอื่น กล่าวคือเพียงแค่ผ่าเหล่าวัตถุที่เป็นของ class / struct / whathaveyou ที่คุณอยู่ข้างใน

รับคลาสข้อมูลต่อไปนี้:

class Item {
    public double price = 0;
}

นี่โอเค:

class Foo {
    private Item bar = new Item();

    public void predictPrice() {
        bar.price = bar.price + 5; // or something
    }
}

// Elsewhere...

Foo foo = Foo();
foo.predictPrice();
System.out.println(foo.bar.price);
// Since I called predictPrice on Foo, which takes and returns nothing, it's
// apparent something might've changed

และนี่ชัดเจนมาก:

class Foo {
    private Item bar = new Item();
}
class Baz {
    public double predictPrice(Item item) {
        return item.price + 5; // or something
    }
}

// Elsewhere...

Foo foo = Foo();
Baz baz = Baz();
foo.bar.price = baz.predictPrice(foo.bar);
System.out.println(foo.bar.price);
// Since I explicitly set foo.bar.price to the return value of predictPrice, it's
// obvious foo.bar.price might've changed

แต่นี่เป็นโคลนและลึกลับเกินไปสำหรับรสนิยมของฉัน:

class Foo {
    private Item bar = new Item();
}
class Baz {
    public void predictPrice(Item item) {
        item.price = item.price + 5; // or something
    }
}

// Elsewhere...

Foo foo = Foo();
Baz baz = Baz();
baz.predictPrice(foo.bar);
System.out.println(foo.bar.price);
// In my head, it doesn't appear that to foo, bar, or price changed. It seems to
// me that, if anything, I've placed a predicted price into baz that's based on
// the value of foo.bar.price

ไวยากรณ์แตกต่างกันระหว่างภาษาต่าง ๆ และมันไม่มีความหมายที่จะแสดงรหัสที่ไม่เฉพาะเจาะจงกับภาษาเพราะมันหมายถึงสิ่งที่แตกต่างอย่างสิ้นเชิงในภาษาที่แตกต่างกัน

ใน Java Itemเป็นชนิดอ้างอิง - Itemมันเป็นชนิดของตัวชี้ไปยังวัตถุที่มีกรณีของ ใน C ++ ประเภทนี้จะถูกเขียนเป็นItem *(ไวยากรณ์สำหรับสิ่งเดียวกันแตกต่างกันระหว่างภาษา) ดังนั้นItem predictPrice(Item item)ใน Java จึงเท่ากับItem *predictPrice(Item *item)ใน C ++ ในทั้งสองกรณีมันเป็นฟังก์ชั่น (หรือวิธีการ) ที่ใช้ตัวชี้ไปยังวัตถุและส่งกลับตัวชี้ไปยังวัตถุ

ใน C ++, Item(ไม่มีสิ่งใด) เป็นประเภทวัตถุ (สมมติว่าItemเป็นชื่อของคลาส) ค่าประเภทนี้ "คือ" วัตถุและItem predictPrice(Item item)ประกาศฟังก์ชั่นที่ใช้วัตถุและส่งกลับวัตถุ เนื่องจาก&ไม่ได้ใช้จะถูกส่งและส่งคืนโดยค่า นั่นหมายความว่าวัตถุจะถูกคัดลอกเมื่อผ่านและคัดลอกเมื่อส่งคืน Java ไม่เทียบเท่าเนื่องจาก Java ไม่มีประเภทวัตถุ

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

การประชุมที่ฉันเห็น codebases เป็นไปตามคือชอบสไตล์ที่ชัดเจนจากไวยากรณ์ หากฟังก์ชั่นการเปลี่ยนแปลงค่าชอบ pass by pointer

void predictPrice(Item * const item);

สไตล์นี้ส่งผลให้:

• เรียกว่าคุณเห็น:

  predictPrice (& my_item);

และคุณรู้ว่ามันจะถูกปรับเปลี่ยนโดยยึดมั่นในสไตล์ของคุณ

• มิฉะนั้นจะชอบ pass โดย const ref หรือค่าเมื่อคุณไม่ต้องการให้ฟังก์ชันแก้ไขอินสแตนซ์

ในขณะที่ฉันไม่ได้ตั้งค่าที่แข็งแกร่งฉันจะลงคะแนนว่าการคืนออบเจ็กต์จะทำให้มีความยืดหยุ่นในการใช้ API

โปรดทราบว่ามีความรู้สึกเฉพาะในขณะที่วิธีการมีอิสระในการส่งคืนวัตถุอื่น ๆ หาก javadoc ของคุณบอกว่า@returns the same value of parameter aมันไร้ประโยชน์ แต่ถ้า javadoc ของคุณพูดว่า@return an instance that holds the same data than parameter aให้ส่งคืนอินสแตนซ์เดียวกันหรืออีกอันหนึ่งเป็นรายละเอียดการใช้งาน

ตัวอย่างเช่นในโครงการปัจจุบันของฉัน (Java EE) ฉันมีเลเยอร์ธุรกิจ เพื่อจัดเก็บใน DB (และกำหนดรหัสอัตโนมัติ) ให้กับพนักงาน, พูด, พนักงานที่ฉันมีบางอย่างเช่น

 public Employee createEmployee(Employee employeeData) {
   this.entityManager.persist(employeeData);
   return this.employeeData;
 }

แน่นอนว่าไม่มีความแตกต่างกับการใช้งานนี้เนื่องจาก JPA ส่งคืนออบเจ็กต์เดียวกันหลังจากกำหนดรหัส ตอนนี้ถ้าฉันเปลี่ยนเป็น JDBC

 public Employee createEmployee(Employee employeeData) {
   PreparedStatement ps = this.connection.prepareStatement("INSERT INTO EMPLOYEE(name, surname, data) VALUES(?, ?, ?)");
   ... // set parameters
   ps.execute();
   int id = getIdFromGeneratedKeys(ps);
   ??????
 }

ตอนนี้ที่ ????? ฉันมีสามตัวเลือก

1. กำหนดตัวกำหนดรหัสและฉันจะคืนค่าวัตถุเดียวกัน น่าเกลียดเพราะsetIdจะสามารถใช้ได้ทุกที่

2. ทำการสะท้อนแสงอย่างหนักและตั้ง id ในEmployeeวัตถุ สกปรก แต่อย่างน้อยก็มีการ จำกัด การcreateEmployeeบันทึก

3. จัดทำคอนสตรัคเตอร์ที่คัดลอกต้นฉบับEmployeeและยอมรับการidตั้งค่า

4. ดึงวัตถุจากฐานข้อมูล (อาจจำเป็นถ้ามีการคำนวณค่าของเขตข้อมูลในฐานข้อมูลหรือถ้าคุณต้องการเติมข้อมูล realtionship)

ตอนนี้สำหรับ 1 และ 2 คุณอาจส่งคืนอินสแตนซ์เดียวกัน แต่สำหรับ 3 และ 4 คุณจะส่งคืนอินสแตนซ์ใหม่ หากคุณสร้างจาก API ของคุณว่าค่า "ของจริง" จะเป็นค่าที่ส่งคืนโดยวิธีนี้คุณจะมีอิสระมากขึ้น

ข้อโต้แย้งที่แท้จริงเพียงข้อเดียวที่ฉันคิดได้คือการใช้ implementatios 1 หรือ 2 คนที่ใช้ API ของคุณอาจมองข้ามการกำหนดผลลัพธ์และรหัสของพวกเขาจะแตกถ้าคุณเปลี่ยนเป็น 3 หรือ 4 การใช้งาน)

อย่างไรก็ตามอย่างที่คุณเห็นการตั้งค่าของฉันขึ้นอยู่กับการตั้งค่าส่วนตัวอื่น ๆ (เช่นห้าม setter สำหรับ Ids) ดังนั้นบางทีมันอาจไม่เหมาะกับทุกคน

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

1. เอนทิตีหนึ่งถือเป็น "เจ้าของ" ของวัตถุที่ไม่แน่นอนและพิจารณาสถานะของวัตถุนั้นเป็นส่วนหนึ่งของตัวเอง เอนทิตีอื่น ๆ อาจเก็บการอ้างอิง แต่ควรพิจารณาการอ้างอิงเป็นการระบุวัตถุที่เป็นของคนอื่น

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

ฉันไม่ชอบที่จะมีวิธีการกลายพันธุ์วัตถุต้นแบบและกลับการอ้างอิงเนื่องจากพวกเขาให้ลักษณะที่เหมาะสมของรูปแบบที่สองข้างต้น มีบางกรณีที่วิธีการอาจเป็นประโยชน์ แต่รหัสที่กำลังจะกลายพันธุ์วัตถุควรดูเหมือนว่ามันกำลังทำเช่นนั้น รหัสเช่นmyThing = myThing.xyz(q);รูปลักษณ์มากน้อยเหมือนมันแปรรูปวัตถุที่ระบุโดยกว่าจะเพียงแค่myThingmyThing.xyz(q);