“ วางวัตถุเกินไป”

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

TDD นั้นไม่ได้ฝึกฝนมากที่นี่ แต่ฉันต้องการมีรหัสที่สามารถทดสอบได้ การฝังตรรกะทางธุรกิจในวิธีส่วนตัวแบบคงที่ใน "คลาสพระเจ้า" ขนาดใหญ่ (ซึ่งดูเหมือนจะเป็นบรรทัดฐานสำหรับทีมนี้) นั้นไม่สามารถทดสอบได้มากนัก

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

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

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

ผู้คนสามารถและเขียนโค้ดแบบแยกส่วนที่มีประสิทธิภาพเป็นนามธรรมและปราศจากข้อบกพร่องในรูปแบบวิธีการทำงานตลอดเวลา Java เป็นทางเลือกที่แปลกของภาษาสำหรับร้านค้าดังกล่าว แต่ฉันสามารถเห็นมันเกิดขึ้นหากปัจจัยภายนอกตัดสินใจภาษาเช่นต้องการที่จะพัฒนาสำหรับ Android เช่น

ทุกคนเป็นอัจฉริยะ แต่ถ้าคุณตัดสินปลาด้วยความสามารถในการปีนต้นไม้มันจะใช้ชีวิตทั้งชีวิตของมันโดยเชื่อว่ามันโง่ - Albert Einstein

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

ในทางกลับกันหากรหัสนั้นยุ่งเหยิงในกระบวนทัศน์ทั้งสองคุณควรจะลดความสูญเสียของคุณ

เมื่ออ่านคำถามของฉันฉันจำได้ว่าหนังสือเคล็ดลับหนึ่งเล่มของ Pragmatic Programmer

หนึ่งในเคล็ดลับคือBe a Catalyst for Change:

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

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

ดังนั้นฉันคิดว่าถ้าคุณเริ่มทำงานได้ดีกับความรู้ OO และ TDD ของคุณเร็ว ๆ นี้พวกเขาจะเริ่มมองหาและถามเกี่ยวกับงานของคุณ

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

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

สิ่งที่ฉันเห็นบ่อยเกินไปใน "true OO" คือเทคนิคขั้นสูงใช้เพื่อแก้ปัญหาที่ง่ายมากในวิธีที่ซับซ้อนมากเกินไป

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

สงครามชนะการต่อสู้ครั้งละหนึ่งครั้ง

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

แน่นอนฉันคิดว่ามีกรณีของการใช้เกินนามธรรมในหลายรหัสฐานวันนี้ ใส่เฉพาะในสิ่งที่คุณต้องการและรวมถึง abstractions ด้วย