เหตุใดจึงถือว่าเป็นวิธีปฏิบัติที่ดีที่สุดในการจัดแพคเกจรหัสโปรแกรมและรหัสส่วนต่อประสานกราฟิกในคลาสที่ต่างกัน

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

ขอขอบคุณ!

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

แนวคิดที่ครูของคุณอ้างถึงคือสิ่งที่เรียกว่าการแบ่งแยกความกังวล

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

การควบคุมส่วนต่อประสานควรเกี่ยวข้องกับการวาดสิ่งที่มีการบอกเท่านั้นตรรกะตารางควรเกี่ยวข้องกับสิ่งที่อยู่ในตารางไม่ใช่วิธีการวาด

สิ่งนี้ช่วยได้ไหม?

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

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

นอกจากนี้ยังให้รหัสที่อ่านง่ายขึ้น ถ้ากริดของคุณทำหน้าที่ของ GUI เพียงอย่างเดียวจะเข้าใจหรือเปลี่ยนรหัสได้ง่ายขึ้น

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

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

เมื่อแยกความกังวลถูกนำไปใช้กับโครงสร้างการประยุกต์ใช้ผลที่ได้คือสถาปัตยกรรมแบบหลายชั้น (หรือสถาปัตยกรรม N-Tier) http://en.wikipedia.org/wiki/Multitier_architecture

เพื่อสร้างคำตอบอื่น ๆ และยกตัวอย่างให้กับคุณคุณควรอนุญาตให้ตัวเองฉีดตรรกะ / ข้อมูลลงในกริดหรือ vica ของคุณ

การควบคุมกริดของคุณสามารถแสดงRenderวิธีหรือDataBindเมธอดได้

class GridControl
{
    public Render(GridData data) { ... }
}

หรือ

class GridControl
{
    public DataBind(GridData data) { ... }
}

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

GridLogic ของคุณควรมีการอ้างอิงถึง GridControl เพื่อให้สามารถเชื่อมโยงกับอินพุต / เหตุการณ์ที่เกิดขึ้น

แนวคิดที่อยู่เบื้องหลังการผูกข้อมูลคือตัวควบคุมกริดของคุณเฝ้าดูข้อมูลสำหรับการเปลี่ยนแปลงและแสดงผลอีกครั้งเมื่อแสดงฟังก์ชั่นการเรนเดอร์หมายความว่าหน่วยตรรกะของคุณทำการเรนเดอร์การควบคุมด้วยตนเอง

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

ผมขอแนะนำให้คุณลองดูที่สถาปัตยกรรม MVC

เป็นการปรับแต่งแนวคิดที่คุณกล่าวถึง (การแยกรหัสโปรแกรมและส่วนต่อประสานกราฟิก) MVC ย่อมาจาก Model-View-Controller ที่นี่ Model คือข้อมูล, View คือรหัสอินเตอร์เฟสกราฟิกและ COntroller เป็นรหัสที่ประมวลผลข้อมูล

วิธีนี้คุณได้สร้างโปรแกรมสามส่วน สามารถเปลี่ยนชิ้นส่วนแต่ละชิ้นได้โดยไม่ต้องเปลี่ยนชิ้นส่วนอื่น ๆ

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

ตำแหน่งที่ MVC ชนะคือถ้าการเปลี่ยนแปลงถูก จำกัด เฉพาะส่วน V หรือ "มุมมอง"

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

if(deTextEdit(&sName)){
  // do XYZ
}

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

หากคุณไปที่ลิงก์นั้นคุณจะเห็นตัวอย่างที่ซับซ้อนมากขึ้น

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

มันไม่ฟรี มันแนะนำเส้นโค้งการเรียนรู้แบบครั้งเดียวสำหรับโปรแกรมเมอร์

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