รายการพารามิเตอร์แบบยาวกับรายการตัวแปรสถานะแบบยาว


10

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


หนังสือต้นฉบับที่แสดงความคิดเห็นใน C ++ เป็นภาษาที่ใช้งานได้หรือไม่
Martin York

คำตอบ:


7

ขึ้นอยู่กับว่าคุณกำลังเขียนโปรแกรมในกระบวนทัศน์proceduralหรือ functionalจำเป็นต้องมีสภาวะที่ไม่แน่นอนสำหรับอดีตและคนพิการในภายหลัง นี่คือแอปเปิ้ลและส้ม พวกเขาถูกต้องทั้งคู่ใน bailiwicks!

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


: ขอบคุณ! หนังสือ << 97 สิ่งที่โปรแกรมเมอร์ทุกคนควรรู้ >> บอกว่าเราควรใช้หลักการเขียนโปรแกรมที่ใช้งานได้เช่นหลีกเลี่ยงผลข้างเคียง เราไม่สามารถใช้หลักการเขียนโปรแกรมเชิงฟังก์ชันในบริบทของรหัสที่จำเป็นได้หรือไม่?
TomCaps

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

@Marjan ทุกอย่างที่มีตัวแปรที่เปลี่ยนแปลงไม่ได้คือ state

@ Jarrod: ตอนนี้คุณทำให้ฉันสับสน อ่านคำตอบของคุณอีกครั้งฉันเห็นว่าฉันพลาด "ไม่แน่นอน" ใน "ต้องเปลี่ยนแปลงสถานะ" แต่ความคิดเห็นของคุณดูเหมือนจะบอกว่าการมีตัวแปรที่เปลี่ยนแปลงไม่ได้คือสถานะ ไม่เข้าใจ อาจเป็นเพราะฉันไม่คุ้นเคยกับการขว้างปาและคิดถึงความไม่แน่นอนและไม่เปลี่ยนรูปในเงื่อนไขเหล่านี้ มีการอ้างอิงใดให้ฉันอ่าน?
Marjan Venema

@MarjanVenema: ใช่การมีตัวแปรที่ไม่เปลี่ยนรูปคือสถานะ ความแตกต่างในการจัดการสถานะระหว่างโพรซีเดอร์และโพรซีเดอร์การทำงานไม่ใช่ proc.prog มีสถานะและการทำงานไม่ได้ - แต่ความแตกต่างคือ proc PROG มีการเปลี่ยนแปลงสถานะที่ในขณะที่รัฐมักไม่เปลี่ยนรูปแบบในการเขียนโปรแกรมการทำงาน (บริสุทธิ์) ดูเช่นen.wikipedia.org/wiki/PFE_functionalซึ่งอธิบายว่าภาษาที่ใช้งานได้จริงหลีกเลี่ยงการอัปเดต
sleske

1

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

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

นอกจากนี้:

  • วิธีอื่นสามารถใช้ประโยชน์จากตัวแปรคลาสได้หรือไม่? ถ้าใช่ให้ลองพิจารณาด้วยตัวแปรคลาส
  • วิธีการของคุณเป็นสาธารณะหรือไม่? หากเป็นสาธารณะให้ใช้พารามิเตอร์
  • รายการพารามิเตอร์ของคุณสามารถแสดงเป็น hash / map / array / collection / list / etc ได้อย่างเหมาะสมหรือไม่? ถ้าเป็นเช่นนั้นให้พิจารณาตัวเลือก
  • วิธีการของคุณคงที่? ถ้าใช่ใช้พารามิเตอร์

0

ไม่ตัวแปรสถานะต่อ se ไม่ก่อให้เกิดผลข้างเคียง

การเรียกใช้เมธอด setter (ในโครงสร้างข้อมูลที่มองเห็นได้จากที่อื่น) เป็นผลข้างเคียง

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

class ManyParams {
    final String theName = null;
    final int    theAge = 0:
    ManyParams() {}
    ManyParams(String a, int b) { theName=a; theAge = b; }
    public withName(String n) {
        return new ManyParams(n, this.theAge);
    }
    public withAge(int i) {
         return new ManyParams(theName, i);
    }
}
/// to be used like this
foo(new ManyParams.withName("John").withAge(42));

แน่นอนผู้สร้างของ ManyParams จะยังคงมีรายการพารามิเตอร์แบบยาว แต่มันซ่อนอยู่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.