“ การประชุมเรื่องการตั้งค่า” ไม่ละเมิดหลักการเขียนโปรแกรมพื้นฐานใช่หรือไม่

ผมกำลังมองไปที่ WPF MVVM กรอบCaliburn.Microและอ่านที่มากของสิ่งที่มาตรฐานจะขึ้นอยู่กับการตั้งชื่อ

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

แก้ไข:

ดังนั้นวิธีนี้เรียกว่าการประชุมเรื่องการตั้งค่า เนื่องจากฉันไม่พบคำถามใด ๆ เกี่ยวกับเรื่องนี้ฉันจึงเปลี่ยนคำถามของฉัน:

คำถามของฉันคือ:

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

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

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

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

ตัวอย่างที่ดีที่การประชุมช่วยโปรแกรมเมอร์คือเมื่อเขียนปลั๊กอิน Eclipse เมื่อดูปลั๊กอินที่ฉันไม่เคยเห็นฉันรู้ทันทีว่ามีหลายสิ่ง รายการการพึ่งพาอยู่ใน MANIFEST.MF จุดส่วนขยายอยู่ใน plugin.xml ซอร์สโค้ดอยู่ภายใต้ "src" และอื่น ๆ หากสิ่งเหล่านี้ขึ้นอยู่กับโปรแกรมเมอร์ที่จะกำหนดปลั๊กอิน Eclipse ทุกอันจะแตกต่างกันและการนำรหัสจะทำได้ยากขึ้น

ให้ +1 กับ @JesperE และต้องการเพิ่มบางสิ่ง:

มันละเมิดหลักการเขียนโปรแกรมบางอย่างหรือไม่

ใช่ "การประชุมเรื่องการกำหนดค่า" ละเมิดหลักการ "ชัดเจนดีกว่าโดยนัย" (ดูตัวอย่างเช่นที่"Zen-Of-Python" )

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

"การประชุมผ่านการตั้งค่า" บางอย่างเพียงแค่ย่อลงมาเป็นค่าเริ่มต้นที่สมเหตุสมผล คุณควรกำหนดค่าสิ่งที่จะใช้เพื่อจุดประสงค์ที่ไม่ได้มาตรฐานเท่านั้น ฉันต้องเปรียบเทียบ Struts กับ Rails ที่นี่ ใน Rails คุณต้องใส่ "การกระทำ / หน้าจอ" ของคุณลงในโฟลเดอร์แล้วก็ใช้งานได้ ใน Struts คุณยังคงต้องใส่ไว้ในโฟลเดอร์ แต่คุณต้องมีชื่อการกระทำและไฟล์ JSP และชื่อฟอร์มและฟอร์มถั่วและระบุว่าสามสิ่งเหล่านี้ทำงานร่วมกันใน Struts-config ได้อย่างไร xml และระบุว่าแบบฟอร์มนั้นเป็นของคำขอ (RESTful) หากยังไม่เพียงพอการแม็พ form / form-bean จะมีส่วนของตัวเองใน Struts-config ซึ่งจะถูกแมปอย่างอิสระกับส่วนการดำเนินการในไฟล์เดียวกันและทั้งหมดนั้นอาศัยสตริงที่เขียนด้วยลายมือในไฟล์ JSP เพื่อทำงาน อย่างถูกต้อง สำหรับแต่ละหน้าจอ อย่างน้อย 6 สิ่งที่คุณไม่ควรทำและมีโอกาสมากที่จะทำผิดพลาด ฉันคิดว่าคุณสามารถตั้งค่าส่วนใหญ่หรือทั้งหมดของสิ่งเหล่านั้นด้วยตนเองใน Rails หากคุณต้องการ แต่ 2/3 ของเวลาในการพัฒนา Struts นั้นสร้างขึ้นและรักษาความซับซ้อนที่ไม่จำเป็น

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

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

ฉันไม่สามารถจินตนาการได้ว่าการมีค่าเริ่มต้นที่สมเหตุสมผลเป็นการละเมิดหลักการทางทฤษฎีใด ๆ เกี่ยวกับความสามารถในการขยายและโมดุล โปรแกรมเมอร์ Ruby / Rails เร็ว ๆ นี้จะแทงโป๊กเกอร์ร้อนในตาของพวกเขากว่าเปลี่ยนเป็นกรอบเช่น Struts 1 ที่การกำหนดค่าทั้งหมดจะทำอย่างชัดเจนในหลายไฟล์ XML ฉันไม่ได้เถียงกับ Rails vs. Struts IN GENERAL แต่การประชุมนั้นสามารถสร้างผลงานที่ยอดเยี่ยมได้ เทคโนโลยีทั้งสองนี้เป็นการเปรียบเทียบที่แท้จริงที่สุดในโลกที่ฉันเคยเจอ

หากคุณทำงานใน Java ลองดูที่ Joshua Bloch "Java ที่มีประสิทธิภาพ" รายการที่ 2: "พิจารณาตัวสร้างเมื่อต้องเผชิญกับพารามิเตอร์ตัวสร้างจำนวนมาก" pp. 11-16 สำหรับวัตถุประสงค์ส่วนใหญ่จำเป็นต้องใช้พารามิเตอร์บางอย่าง (การกำหนดค่า) และบางอย่างเป็นทางเลือก แนวคิดพื้นฐานคือต้องการเพียงการกำหนดค่าที่จำเป็นและทำให้ผู้ใช้ (ซึ่งอาจเป็นโปรแกรมอื่น) ระบุตัวเลือกเพิ่มเติมตามต้องการ ฉันล้างโค้ดจำนวนมากด้วยลวดลายนี้เมื่อเดือนที่แล้วและมันก็เป็นประกายในเชิงบวก

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

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

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

ตัวอย่างเช่นสมมติว่าในกรอบบางเหตุการณ์ที่ก่อให้เกิดการเรียกไปยังFooBar handleFooBarในเฟรมเวิร์ก B อื่นความสัมพันธ์นี้ถูกกำหนดค่าไว้ใน XMLfile

ดังนั้นใน A มันเป็นเพียงแค่

handleFooBar() {
   ...
}

และถ้าคุณไม่ได้สะกดผิด FooBar มันจะถูกเรียกเมื่อใดก็ตามที่ FooBar เกิดขึ้น

ใน B มันเป็นอีกครั้ง

handleFooBar() {
   ...
}

แต่ยัง

<eventconfiguration>
  <event>
    <type>FooBar</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

ด้วยหลายร้อยสิ่งที่จะกำหนดค่าด้วยวิธีนี้มันง่ายเกินไปที่จะบังเอิญสร้างบั๊กที่ละเอียดอ่อนเช่น

<eventconfiguration>
  <event>
    <type>BarFoo</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

เพราะหลังจากการคัดลอกวางเราได้เปลี่ยนเพียงแต่ลืมที่จะเปลี่ยน<type><handler>

เนื่องจากไฟล์การกำหนดค่าเหล่านั้นมีขนาดใหญ่และน่าเบื่อจึงมีโอกาสน้อยที่บางคนจะพบข้อผิดพลาดโดยการพิสูจน์อักษรมากกว่าที่เขาจะพบข้อบกพร่องที่คล้ายกันในรหัสโปรแกรมจริง

อาจเป็นการละเมิดหลักการบางอย่าง แต่ในขณะเดียวกันก็ปฏิบัติตามหลักการออกแบบขั้นพื้นฐานที่สำคัญที่สุดอย่างหนึ่งคือ SRP (Single Responsibility Principle)