การปรับเปลี่ยนพารามิเตอร์ขาเข้าเป็น antipattern หรือไม่? [ปิด]

ฉันกำลังเขียนโปรแกรมใน Java และฉันมักจะทำเช่นนี้:

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

ในที่ทำงานใหม่รูปแบบคือ:

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

สำหรับฉันมันส่งกลิ่นนิดหน่อยเพราะฉันคุ้นเคยกับการไม่เปลี่ยนพารามิเตอร์ขาเข้า การแก้ไขพารามิเตอร์ขาเข้านี้เป็น antipattern หรือไม่ มันมีข้อบกพร่องร้ายแรงบ้างไหม?

มันไม่ใช่ปฏิปักษ์ แต่เป็นวิธีปฏิบัติที่ไม่ดี

ความแตกต่างระหว่าง antipattern และการปฏิบัติที่ไม่ดีเพียงอยู่ที่นี่: นิยาม antipattern

รูปแบบการทำงานแบบใหม่ที่คุณแสดงคือการปฏิบัติที่ไม่ดีครั้งที่ร่องรอยหรือ pre-OOP อ้างอิงจาก Clean Code ของลุงบ็อบ

อาร์กิวเมนต์จะถูกตีความอย่างเป็นธรรมชาติมากที่สุดเป็นอินพุตไปยังฟังก์ชัน

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

การอ้างอิงหนังสือที่มีชื่อเสียงของ Robert C. Martin "Clean Code":

ควรหลีกเลี่ยงอาร์กิวเมนต์เอาต์พุต

ฟังก์ชั่นควรมีอาร์กิวเมนต์จำนวนน้อย

รูปแบบที่สองละเมิดกฎทั้งสองโดยเฉพาะ "อาร์กิวเมนต์เอาท์พุท" หนึ่ง ในแง่นี้มันแย่กว่ารูปแบบแรก

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

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

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

มันขึ้นอยู่กับภาษาจริงๆ

ใน Java รูปแบบที่สองอาจเป็น anti-pattern แต่บางภาษาจะปฏิบัติต่อพารามิเตอร์ที่ส่งผ่านต่างกัน ในอาดาและ VHDL สำหรับตัวอย่างเช่นแทนที่จะผ่านค่าหรือการอ้างอิงพารามิเตอร์สามารถมีโหมดin, หรือoutin out

เป็นข้อผิดพลาดในการแก้ไขinพารามิเตอร์หรืออ่านoutพารามิเตอร์ แต่การเปลี่ยนแปลงใด ๆ กับin outพารามิเตอร์จะถูกส่งกลับไปยังผู้เรียก

ดังนั้นทั้งสองรูปแบบใน Ada (เหล่านี้ยังเป็น VHDL ตามกฎหมาย)

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

และ

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

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

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

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

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

แน่นอนว่าโดยปกติจะได้รับการจัดการโดยใช้ข้อยกเว้น อย่างไรก็ตามแม้ว่าจะต้องหลีกเลี่ยงข้อยกเว้นไม่ว่าด้วยเหตุผลใดก็ตามมีวิธีที่ดีกว่าในการทำเช่นนี้ - รูปแบบ TryParseเป็นตัวเลือกหนึ่ง

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

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

เหตุผลความมั่นคงค่อนข้างง่อย แต่น่าเศร้าที่มันเป็นเรื่องธรรมดาที่สุด

• บางทีสไตล์ตำรวจในที่ทำงานของคุณ (หรือโค้ดเบส) มาจากพื้นหลังที่ไม่ใช่จาวาและลังเลที่จะเปลี่ยนแปลง
• รหัสของคุณอาจเป็นพอร์ตจากภาษาที่สไตล์นี้มีความหมายมากกว่า
• องค์กรของคุณอาจต้องรักษาความสอดคล้องของ API ในภาษาต่าง ๆ และนี่เป็นรูปแบบที่ใช้กันน้อยที่สุด (มันเป็นเรื่องที่แย่มาก แต่มันเกิดขึ้นได้แม้กับ Google )
• หรืออาจมีสไตล์ที่เหมาะสมกว่าในอดีตอันไกลโพ้นและปรับเปลี่ยนให้อยู่ในรูปแบบปัจจุบัน (ตัวอย่างเช่นมันอาจเป็นรูปแบบ TryParse แต่ผู้บุกเบิกบางคนตั้งใจเอาค่าส่งคืนออกหลังจากค้นพบว่าไม่มีใครตรวจสอบเลย)

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

ข้อเสียของวิธีนี้คือ:

1. ไม่สามารถใช้เป็นวิธีการจากโรงงานผู้โทรจะต้องทราบชนิดย่อยที่แน่นอนของOtherObjectความต้องการและสร้างไว้ล่วงหน้า
2. MyObjectไม่สามารถใช้กับวัตถุที่ต้องใช้พารามิเตอร์ในตัวสร้างของพวกเขาหากพารามิเตอร์เหล่านั้นมาจาก OtherObjectต้อง constructable MyObjectโดยไม่ต้องรู้เกี่ยวกับ

คำตอบจะขึ้นอยู่กับประสบการณ์ของฉันใน c # ฉันหวังว่าตรรกะแปลเป็น Java

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

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