มีสิ่งใดที่มีฟังก์ชั่น / เมธอดส่วนตัวมากเกินไปหรือไม่?


63

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

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

แน่นอนว่าตอนนี้การอ่านวิธีสาธารณะนั้นง่ายขึ้น แต่ฉันอดไม่ได้ที่จะคิดว่าการมีฟังก์ชั่นมากเกินไปนั้นเป็นการฝึกฝนที่ไม่ดี

[แก้ไข]

มีคนถามฉันว่าทำไมฉันคิดว่าการมีฟังก์ชั่นมากเกินไปนั้นเป็นการฝึกฝนที่ไม่ดี

คำตอบง่าย ๆ : มันเป็นความรู้สึกทางเดินอาหาร

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

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

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

ดังนั้นฉันขอให้สิ่งนี้สอนตัวเองเพื่อเลือกเส้นทางที่ถูกต้อง

[แก้ไข]

ด้านล่างฉันรวมสองรุ่นว่าฉันสามารถแก้ปัญหาของฉันได้อย่างไร คนแรกแก้มันโดยไม่แยกชิ้นใหญ่ของรหัส คนที่สองไม่สิ่งที่แยกจากกัน

รุ่นแรก:

public static int Main()
{
    // Displays the menu.
    Console.WriteLine("Pick your option");
    Console.Writeline("[1] Input and display a polynomial");
    Console.WriteLine("[2] Add two polynomials");
    Console.WriteLine("[3] Subtract two polynomials");
    Console.WriteLine("[4] Differentiate two polynomials");
    Console.WriteLine("[0] Quit");
}

รุ่นที่สอง:

public static int Main()
{
    DisplayMenu();
}

private static void DisplayMenu()
{
    Console.WriteLine("Pick your option");
    Console.Writeline("[1] Input and display a polynomial");
    Console.WriteLine("[2] Add two polynomials");
    Console.WriteLine("[3] Subtract two polynomials");
    Console.WriteLine("[4] Differentiate two polynomials");
    Console.WriteLine("[0] Quit");
}

ในตัวอย่างข้างต้นหลังเรียกฟังก์ชั่นที่จะใช้เพียงครั้งเดียวตลอดทั้งรันไทม์ทั้งหมดของโปรแกรม

หมายเหตุ: รหัสข้างต้นเป็นแบบทั่วไป แต่มีลักษณะเดียวกันกับปัญหาของฉัน

ตอนนี้นี่คือคำถามของฉัน: อันไหน ฉันเลือกอันแรกหรืออันที่สอง?


1
"การมีฟังก์ชั่นมากเกินไปเป็นการฝึกฝนที่ไม่ดี"? ทำไม? โปรดอัปเดตคำถามของคุณเพื่ออธิบายว่าทำไมสิ่งนี้ถึงไม่ดีสำหรับคุณ
S.Lott

ฉันขอแนะนำให้อ่านแนวคิดของ 'การติดต่อกันในชั้นเรียน' - Bob Martin อภิปรายเรื่องนี้ใน 'Clean Code'
JᴀʏMᴇᴇ

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

หากใครสามารถบอกฉันได้ว่าทำไม "คำตอบนี้ไม่มีประโยชน์" ฉันจะขอบคุณ หนึ่งสามารถเรียนรู้ได้เสมอ :-)
Pablo H

@PabloH คำตอบที่คุณให้ไว้เป็นข้อสังเกตที่ดีและมีความเข้าใจลึกซึ้งเกี่ยวกับ OP อย่างไรก็ตามไม่ได้ตอบคำถามที่ถาม ฉันย้ายมันไปที่ช่องแสดงความคิดเห็น
maple_shaft

คำตอบ:


36

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

นี่คือสิ่งที่เรียกว่าEncapsulationซึ่งสร้างControl Abstractionในระดับที่สูงขึ้น นี่เป็นสิ่งที่ดี

ซึ่งหมายความว่าทุกคนที่อ่านรหัสของคุณเมื่อพวกเขาได้รับการstartTheEngine()วิธีการในรหัสของคุณสามารถละเว้นทุกรายละเอียดระดับที่ต่ำกว่าเช่นopenIgnitionModule(), turnDistributorMotor(), sendSparksToSparkPlugs(), injectFuelIntoCylinders(), activateStarterSolenoid()และอื่น ๆ ทั้งหมดที่ซับซ้อนขนาดเล็กฟังก์ชั่นที่จะต้องทำงานเพื่อ startTheEngine()อำนวยความสะดวกที่มีขนาดใหญ่มากฟังก์ชั่นนามธรรมมากขึ้นของ

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

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

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

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


3
ดังนั้นคุณเชื่อว่า 'encapsulation' เป็นสิ่งที่ดีที่จะให้ตรรกะแก่ทั้งชั้นเรียนซึ่งเรียกเพียงแห่งเดียว
Steven Jeuris

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

2
@gablin: ฟังก์ชั่นส่วนตัวยังคงสามารถเข้าถึงได้จากภายในชั้นเรียนทั้งหมด ในบทความนี้ (เห็นได้ชัดว่าขัดแย้ง) ฉันอภิปรายว่า 'การอ่านทั่วโลก' หายไปอย่างไรเมื่อมีฟังก์ชั่นมากเกินไป จริงๆแล้วหลักการทั่วไปนอกเหนือจากฟังก์ชั่นนั้นควรทำเพียงสิ่งเดียวคือคุณไม่ควรมีมากเกินไป คุณจะได้รับ 'การอ่านในพื้นที่เท่านั้น' โดยการแยกเพียงเพื่อความสั้นซึ่งสามารถทำได้ด้วยการแสดงความคิดเห็นอย่างง่ายและ 'ย่อหน้าของโค้ด' ตกลงรหัสควรเป็นเอกสารด้วยตนเอง แต่ความคิดเห็นไม่ล้าสมัย!
Steven Jeuris

1
@Steven - ง่ายต่อการเข้าใจคืออะไร? myString.replaceAll(pattern, originalData);หรือฉันวางเมธอด replaceAll ทั้งหมดในรหัสของฉันรวมถึงอาร์เรย์ char สำรองที่แสดงถึงวัตถุสตริงต้นแบบทุกครั้งที่ฉันต้องใช้ฟังก์ชันการทำงานของสตริงหรือไม่
jmort253

7
@Steven Jeuris: คุณมีประเด็น หากคลาสมีฟังก์ชั่นมากเกินไป (สาธารณะหรือส่วนตัว) แสดงว่าคลาสทั้งหมดพยายามทำมากเกินไป ในกรณีเช่นนี้อาจเป็นการดีกว่าที่จะแบ่งออกเป็นคลาสย่อย ๆ หลายคลาสเช่นเดียวกับที่คุณแบ่งขนาดใหญ่เกินไปของฟังก์ชันออกเป็นฟังก์ชันขนาดเล็กหลาย ๆ
gablin

22

ใช่และไม่. หลักการพื้นฐานคือ: วิธีการควรทำสิ่งหนึ่งและสิ่งหนึ่งเท่านั้น

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

หากคุณมีวิธี / คลาสที่ยิ่งใหญ่จริงๆแล้วมันเป็นสัญญาณที่บ่งบอกว่ามันทำอะไรได้มากมายและคุณต้องทำการปรับโครงสร้างใหม่เพื่อที่จะแยก "blob" ออก Perphaps ซ่อนความซับซ้อนบางอย่างในคลาสอื่นภายใต้สิ่งที่เป็นนามธรรมและใช้การฉีดแบบพึ่งพา


1
ดีใจที่ได้อ่านไม่ใช่ทุกคนติดตามกฎ 'สิ่งหนึ่ง' อย่างสุ่มสี่สุ่มห้า! ; p คำตอบที่ดี!
Steven Jeuris

16
ฉันมักจะแบ่งวิธีการขนาดใหญ่ออกเป็นวิธีที่เล็กกว่าแม้ว่าพวกเขาจะให้บริการเฉพาะวิธีที่ใหญ่กว่าเท่านั้น เหตุผลในการแบ่งเป็นเพราะมันง่ายต่อการจัดการและเข้าใจแทนที่จะมีเพียงหนึ่งหยดใหญ่ของรหัส
gablin

1
ไม่เป็นไรเช่นกันในบางกรณีที่คุณไม่สามารถหลีกเลี่ยงวิธีการขนาดใหญ่ได้ ตัวอย่างเช่นถ้าคุณมีวิธีการเริ่มต้นที่คุณอาจมีมันเรียก InitializeSystems, InitializePlugins ฯลฯ ฯลฯ หนึ่งควรให้ตรวจสอบตัวเอง refactoring ที่ไม่จำเป็นแม้ว่า
Homde

1
สิ่งสำคัญเกี่ยวกับทุกวิธี (หรือฟังก์ชั่น) คือมันจะต้องมีอินเทอร์เฟซแนวคิดที่ชัดเจนมันเป็น "สัญญา" หากคุณไม่สามารถปักหมุดลงมันจะเป็นปัญหาและคุณเข้าใจผิด (การจัดทำเอกสารสัญญาอย่างชัดเจนอาจเป็นสิ่งที่ดี - หรือใช้เครื่องมือในการบังคับใช้รูปแบบไอเฟล - แต่มันไม่สำคัญเท่ากับการมีไว้ในที่แรก)
Donal Fellows

3
@gablin: ประโยชน์อีกอย่างที่ควรพิจารณา: เมื่อฉันแบ่งสิ่งต่าง ๆ ออกเป็นฟังก์ชั่นเล็ก ๆ อย่าคิดว่า "พวกเขาให้บริการฟังก์ชั่นอื่นเพียงอย่างเดียว" คิดว่า "พวกเขาให้บริการอีกฟังก์ชั่นหนึ่งเท่านั้นในตอนนี้ " มีหลายครั้งที่วิธีการกู้คืนแฟคตอริ่งขนาดใหญ่ช่วยให้ฉันประหยัดเวลาได้มากเมื่อเขียนวิธีอื่นในอนาคตเนื่องจากฟังก์ชั่นขนาดเล็กมีความกว้างมากกว่าและใช้ซ้ำได้
GSto

17

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


10

คำตอบที่ยอดเยี่ยมของ jmort253 เป็นแรงบันดาลใจให้ฉันติดตามด้วยคำตอบ "ใช่ แต่"

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

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


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

8

เกือบทุกโครงการ OO ที่ฉันเคยเข้าร่วมได้รับความเดือดร้อนจากชั้นเรียนที่มีขนาดใหญ่เกินไปและวิธีการที่ยาวเกินไป

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


7

ชั้นเรียนที่มีวิธีการสาธารณะ 5 วิธีและวิธีการส่วนตัว 25 วิธีนั้นไม่ได้ใหญ่ไปสำหรับฉัน เพียงแค่ให้แน่ใจว่าชั้นเรียนของคุณมีความรับผิดชอบที่ชัดเจนและไม่ต้องกังวลมากเกินไปเกี่ยวกับจำนวนวิธีการ

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


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

4

ข้อความที่ตัดตอนมาจากรหัสสะอาดของอาร์มาร์ติน(หน้า 176):

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


3

ตัวเลือกบางอย่าง:

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

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


1

ฉันไม่คิดว่าจะมีปัญหากับ "วิธีการส่วนตัวที่มากเกินไป" หากรู้สึกเช่นนั้นอาจเป็นอาการของสถาปัตยกรรมรหัสที่ไม่ดี

นี่คือวิธีที่ฉันคิดเกี่ยวกับมัน ... หากสถาปัตยกรรมได้รับการออกแบบมาเป็นอย่างดีโดยทั่วไปแล้วจะชัดเจนว่ารหัสที่ควรเป็น X คืออะไร เป็นที่ยอมรับถ้ามีข้อยกเว้นสองสามข้อ - แต่สิ่งเหล่านี้จำเป็นต้องมีความพิเศษอย่างแท้จริงมิฉะนั้นปรับโครงสร้างสถาปัตยกรรมเพื่อจัดการสิ่งเหล่านี้เป็นมาตรฐาน

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

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


0

มีสิ่งใดที่มีฟังก์ชั่น / เมธอดส่วนตัวมากเกินไปหรือไม่?

ใช่.

ใน Python แนวคิดของ "private" (ตามที่ใช้โดย C ++, Java และ C #) ไม่มีอยู่จริง

มีรูปแบบการตั้งชื่อแบบ "เรียงลำดับส่วนตัว" แต่ก็เป็นแบบนั้น

ส่วนตัวสามารถนำไปสู่รหัสที่ยากต่อการทดสอบ นอกจากนี้ยังสามารถทำลาย "หลักการเปิดปิด" โดยการปิดรหัส

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


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