คำถามติดแท็ก coupling

9
ฉันเปลี่ยนลายเซ็นวิธีหนึ่งและตอนนี้มีข้อผิดพลาดมากกว่า 25,000 ข้อ เกิดอะไรขึ้น
ฉันเพิ่งเริ่มงานใหม่เมื่อไม่นานมานี้ซึ่งฉันกำลังทำงานกับแอปพลิเคชันขนาดใหญ่มาก (15M loc) ในงานก่อนหน้าของฉันเรามีแอปพลิเคชั่นขนาดใหญ่คล้าย ๆ กัน แต่ (เพื่อให้ดีขึ้นหรือแย่ลง) เราใช้ OSGi ซึ่งหมายความว่าแอปพลิเคชันนั้นถูกแบ่งออกเป็นไมโครไซต์จำนวนมากที่สามารถเปลี่ยนแปลงรวบรวมและนำไปใช้ได้อย่างอิสระ แอปพลิเคชันใหม่เป็นเพียงฐานรหัสขนาดใหญ่เพียงฐานเดียว ดังนั้นฉันจึงต้องเปลี่ยนอินเทอร์เฟซของคลาสนี้เพราะนั่นคือสิ่งที่เจ้านายของฉันขอให้ฉันทำ ตอนแรกพวกเขาเขียนด้วยสมมติฐานบางอย่างที่ไม่ได้พูดคุยกันดีเกินไปและในขณะที่พวกเขาหลีกเลี่ยงปัญหาของการปรับโครงสร้างใหม่เพราะมันเชื่อมโยงอย่างแน่นหนา ฉันเปลี่ยนอินเทอร์เฟซและตอนนี้มีข้อผิดพลาดมากกว่า 25,000 ข้อ ข้อผิดพลาดบางอย่างอยู่ในคลาสที่มีชื่อการทำให้เกิดเสียงที่สำคัญเช่น "XYZPriceCalculator" ซึ่งได้รับการตรวจสอบใหม่ไม่ควรทำลาย แต่ฉันไม่สามารถเริ่มแอปพลิเคชันเพื่อตรวจสอบว่ามันทำงานได้หรือไม่จนกว่าข้อผิดพลาดทั้งหมดจะได้รับการแก้ไข และหน่วยทดสอบจำนวนมากทดสอบโดยตรงว่าอินเตอร์เฟสหรือเชื่อมต่อกับคลาสพื้นฐานซึ่งอ้างอิงอินเตอร์เฟสนั้นดังนั้นการแก้ไขสิ่งเหล่านั้นจึงเป็นงานที่ใหญ่มากในตัวมันเอง นอกจากนี้ฉันไม่ทราบว่าชิ้นส่วนเหล่านี้เข้ากันได้อย่างไรดังนั้นแม้ว่าฉันจะเริ่มต้นได้ฉันก็ไม่รู้จริงๆว่ามันจะเป็นอย่างไรถ้าสิ่งต่าง ๆ แตกหัก ฉันไม่เคยประสบปัญหาเช่นนี้ในงานสุดท้ายของฉัน ฉันจะทำอย่างไร

11
ฉันจะหลีกเลี่ยงการทำรีดักชั่นแบบเรียงซ้อนได้อย่างไร?
ฉันมีโครงการแล้ว ในโครงการนี้ฉันต้องการ refactor เพื่อเพิ่มคุณสมบัติและฉัน refactored โครงการเพื่อเพิ่มคุณสมบัติ ปัญหาคือเมื่อฉันเสร็จแล้วมันกลับกลายเป็นว่าฉันต้องการที่จะทำการเปลี่ยนแปลงอินเตอร์เฟซเล็กน้อยเพื่อรองรับมัน ดังนั้นฉันจึงทำการเปลี่ยนแปลง จากนั้นคลาสการบริโภคไม่สามารถนำไปใช้กับอินเทอร์เฟซปัจจุบันในแง่ของอินเทอร์เฟซใหม่ดังนั้นมันจึงต้องการอินเทอร์เฟซใหม่เช่นกัน ตอนนี้สามเดือนต่อมาและฉันต้องแก้ไขปัญหาที่ไม่เกี่ยวข้องอย่างมากมายนับไม่ถ้วนและฉันกำลังมองหาการแก้ปัญหาที่ถูกทำแผนที่สำหรับหนึ่งปีต่อจากนี้ อีกครั้ง ฉันจะหลีกเลี่ยงการปรับลดประเภทของการเรียงซ้อนในอนาคตได้อย่างไร มันเป็นแค่อาการของชั้นเรียนก่อนหน้าของฉันซึ่งขึ้นอยู่กับแต่ละคนแน่นเกินไปหรือไม่? การแก้ไขสั้น ๆ : ในกรณีนี้ refactor เป็นคุณลักษณะเนื่องจาก refactor เพิ่มความสามารถในการขยายของโค้ดบางส่วนและลดการเชื่อมต่อบางส่วน นั่นหมายความว่าผู้พัฒนาภายนอกสามารถทำอะไรได้มากกว่าซึ่งเป็นคุณลักษณะที่ฉันต้องการนำเสนอ ดังนั้นตัวปรับเปลี่ยนดั้งเดิมเองไม่ควรเปลี่ยนฟังก์ชัน แก้ไขที่ใหญ่กว่าที่ฉันสัญญาห้าวันที่ผ่านมา: ก่อนที่ฉันจะเริ่ม refactor นี้ฉันมีระบบที่ฉันมีอินเทอร์เฟซ แต่ในการนำไปใช้นั้นฉันเพิ่งdynamic_castผ่านการใช้งานที่เป็นไปได้ทั้งหมดที่ฉันจัดส่ง เห็นได้ชัดว่านั่นหมายความว่าคุณไม่สามารถสืบทอดจากอินเทอร์เฟซสำหรับสิ่งใดสิ่งหนึ่งและอย่างที่สองว่ามันจะเป็นไปไม่ได้สำหรับทุกคนที่ไม่มีการเข้าถึงเพื่อใช้งานอินเทอร์เฟซนี้ ดังนั้นฉันตัดสินใจว่าฉันต้องการแก้ไขปัญหานี้และเปิดอินเทอร์เฟซสำหรับการบริโภคสาธารณะเพื่อให้ทุกคนสามารถใช้งานได้และการใช้อินเทอร์เฟซนั้นเป็นสัญญาทั้งหมดที่จำเป็นต้องมี - การปรับปรุงอย่างชัดเจน เมื่อฉันค้นหาและฆ่าด้วยไฟในทุกสถานที่ที่ฉันได้ทำสิ่งนี้ฉันพบที่เดียวที่พิสูจน์แล้วว่าเป็นปัญหาเฉพาะ มันขึ้นอยู่กับรายละเอียดการใช้งานของคลาสที่ได้รับมาทั้งหมดและฟังก์ชั่นการทำซ้ำที่มีการใช้งานแล้ว แต่ดีกว่าที่อื่น มันอาจถูกนำมาใช้ในแง่ของอินเทอร์เฟซสาธารณะแทนและนำมาใช้ใหม่การใช้งานที่มีอยู่ของฟังก์ชั่นนั้น ฉันค้นพบว่ามันจำเป็นต้องใช้บริบทบางอย่างในการทำงานอย่างถูกต้อง พูดโดยประมาณการเรียกใช้งานก่อนหน้านี้ดูเหมือนจะเป็นไปได้ for(auto&& a : as) { f(a); } อย่างไรก็ตามเพื่อให้ได้บริบทนี้ฉันต้องเปลี่ยนมันเป็นอะไรที่มากกว่า std::vector<Context> contexts; for(auto&& a …

6
ทำไม“ การมีเพศสัมพันธ์อย่างแน่นหนาระหว่างฟังก์ชั่นและข้อมูล” ไม่ดี?
ฉันพบข้อความนี้ใน " ความสุขของ Clojure " บนหน้า 32 แต่มีบางคนพูดสิ่งเดียวกันกับฉันในมื้อค่ำเมื่อสัปดาห์ที่แล้วและฉันก็ได้ยินที่อื่นเช่นกัน: [A] ข้อเสียของการเขียนโปรแกรมเชิงวัตถุคือการมีเพศสัมพันธ์อย่างแน่นหนาระหว่างฟังก์ชั่นและข้อมูล ฉันเข้าใจว่าเหตุใดการเชื่อมต่อที่ไม่จำเป็นจึงไม่ดีในแอปพลิเคชัน นอกจากนี้ฉันรู้สึกสบายใจที่จะบอกว่าควรหลีกเลี่ยงสถานะและการสืบทอดที่ไม่แน่นอนแม้ในการเขียนโปรแกรมเชิงวัตถุ แต่ฉันล้มเหลวที่จะเห็นว่าทำไมการติดฟังก์ชั่นในชั้นเรียนจึงไม่ดีอย่างแท้จริง ฉันหมายถึงการเพิ่มฟังก์ชั่นในชั้นเรียนดูเหมือนว่าจะติดแท็กเมลใน Gmail หรือติดไฟล์ในโฟลเดอร์ เป็นเทคนิคขององค์กรที่ช่วยให้คุณค้นพบอีกครั้ง คุณเลือกเกณฑ์บางอย่างจากนั้นรวบรวมสิ่งต่าง ๆ เข้าด้วยกัน ก่อน OOP โปรแกรมของเรามีวิธีการมากมายในไฟล์ ฉันหมายความว่าคุณต้องใส่ฟังก์ชั่นบางแห่ง ทำไมไม่จัดระเบียบพวกเขา? หากนี่เป็นการโจมตีแบบ veiled ในประเภททำไมพวกเขาถึงไม่พูดว่าการ จำกัด ประเภทของอินพุตและเอาต์พุตไปยังฟังก์ชันนั้นผิด ฉันไม่แน่ใจว่าฉันจะเห็นด้วยกับเรื่องนี้หรือไม่ แต่อย่างน้อยฉันก็คุ้นเคยกับข้อโต้แย้งอย่างมืออาชีพและความปลอดภัยในการพิมพ์ ฟังดูเป็นเรื่องที่ฉันกังวลเป็นส่วนใหญ่ แน่นอนว่าบางครั้งผู้คนเข้าใจผิดและวางการทำงานผิดประเภท แต่เมื่อเทียบกับข้อผิดพลาดอื่น ๆ ดูเหมือนว่าจะเป็นความไม่สะดวกเล็กน้อย ดังนั้น Clojure มีเนมสเปซ การผสานฟังก์ชันกับคลาสใน OOP แตกต่างจากการผสานฟังก์ชันในเนมสเปซใน Clojure ได้อย่างไรและทำไมมันจึงไม่ดี โปรดจำไว้ว่าฟังก์ชั่นในชั้นเรียนไม่จำเป็นต้องทำงานกับสมาชิกของคลาสนั้นเสมอไป ดูที่ java.lang.StringBuilder - ทำงานกับประเภทการอ้างอิงใด …

5
คุณควรใส่ค่าคงที่ตรงไหนและทำไม?
ในแอปพลิเคชันขนาดใหญ่ส่วนใหญ่ของเราเรามักจะมีเพียงไม่กี่ตำแหน่งสำหรับ "ค่าคงที่": หนึ่งคลาสสำหรับ GUI และค่าคงที่ภายใน (ชื่อแท็บหน้า, ชื่อกลุ่มกล่อง, ปัจจัยการคำนวณ, การแจกแจง) หนึ่งคลาสสำหรับตารางและคอลัมน์ฐานข้อมูล (ส่วนนี้เป็นรหัสที่สร้างขึ้น) พร้อมชื่อที่อ่านได้สำหรับพวกเขา (กำหนดด้วยตนเอง) คลาสหนึ่งสำหรับข้อความแอปพลิเคชัน (การบันทึกกล่องข้อความ ฯลฯ ) ค่าคงที่มักจะถูกแยกออกเป็นส่วนต่าง ๆ ในคลาสเหล่านั้น ในแอปพลิเคชัน C ++ ของเราค่าคงที่จะถูกกำหนดเฉพาะในไฟล์. h และค่าจะถูกกำหนดในไฟล์. cpp ข้อดีอย่างหนึ่งก็คือสตริงทั้งหมด ฯลฯ อยู่ในจุดศูนย์กลางเดียวและทุกคนรู้ว่าจะต้องค้นหาสิ่งใดเมื่อต้องมีการเปลี่ยนแปลง นี่เป็นสิ่งที่ผู้จัดการโครงการดูเหมือนจะเป็นอย่างที่ผู้คนเข้ามาและด้วยวิธีนี้ทุกคนสามารถเปลี่ยนแปลงสิ่งเล็ก ๆ น้อย ๆ ได้โดยไม่ต้องขุดเข้าไปในโครงสร้างของแอปพลิเคชัน นอกจากนี้คุณสามารถเปลี่ยนชื่อของกลุ่มกล่อง / หน้าแท็บที่คล้ายกันได้อย่างง่ายดายในครั้งเดียว อีกแง่มุมหนึ่งคือคุณสามารถพิมพ์คลาสนั้นและมอบให้กับผู้ที่ไม่ใช่โปรแกรมเมอร์ซึ่งสามารถตรวจสอบคำอธิบายภาพว่าใช้งานง่ายหรือไม่และข้อความที่ส่งถึงผู้ใช้นั้นละเอียดเกินไปหรือสับสนเกินไป อย่างไรก็ตามฉันเห็นข้อเสียบางอย่าง: ทุกชั้นเรียนจะถูกผนวกเข้ากับชั้นเรียนอย่างต่อเนื่อง การเพิ่ม / ลบ / เปลี่ยนชื่อ / ย้ายค่าคงที่ต้องมีการคอมไพล์ใหม่อย่างน้อย 90% ของแอปพลิเคชัน …

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

3
วิธีการแยก UI จากตรรกะบนแอป Pyqt / Qt อย่างถูกต้อง?
ผมเคยอ่านค่อนข้างมากเกี่ยวกับเรื่องนี้ในอดีตและเฝ้าดูการเจรจาที่น่าสนใจบางเช่นเดียวจากนี้ลุงบ๊อบ ถึงกระนั้นฉันมักจะพบว่ามันยากที่จะออกแบบสก์ท็อปของฉันอย่างถูกต้องและแยกแยะความแตกต่างซึ่งควรเป็นความรับผิดชอบในด้านUIและสิ่งที่อยู่ในด้านตรรกะ สรุปโดยย่อเกี่ยวกับแนวทางปฏิบัติที่ดีคือสิ่งนี้ คุณควรออกแบบตรรกะของคุณแยกจาก UI ดังนั้นวิธีที่คุณสามารถใช้ (ในทางทฤษฎี) ไลบรารีของคุณไม่ว่าจะเป็นแบ็กเอนด์ / UI ใด ๆ สิ่งนี้หมายความว่าโดยพื้นฐานแล้ว UI ควรเป็นคนโง่ที่สุดและควรทำการประมวลผลอย่างหนักที่ด้านตรรกะ ถ้าอย่างนั้นฉันก็สามารถใช้ไลบรารี่ที่สวยงามของฉันกับแอพพลิเคชั่นคอนโซลเว็บแอพพลิเคชั่น นอกจากนี้ลุงบ๊อบแนะนำการอภิปรายที่แตกต่างกันของเทคโนโลยีที่ใช้จะให้ประโยชน์มากมาย (อินเทอร์เฟซที่ดี) แนวคิดการชะลอตัวนี้ช่วยให้คุณมีเอนทิตี้ที่ผ่านการทดสอบอย่างดีซึ่งฟังดูดี แต่ก็ยังยุ่งยาก ดังนั้นฉันรู้ว่าคำถามนี้เป็นคำถามที่ค่อนข้างกว้างขวางซึ่งมีการพูดคุยกันหลายครั้งผ่านอินเทอร์เน็ตทั้งหมดและในหนังสือที่ดีมากมาย ดังนั้นเพื่อให้ได้สิ่งที่ดีออกมาฉันจะโพสต์ตัวอย่างตัวอย่างเล็ก ๆ น้อย ๆ ที่พยายามใช้ MCV บน pyqt: import sys import os import random from PyQt5 import QtWidgets from PyQt5 import QtGui from PyQt5 import QtCore random.seed(1) class Model(QtCore.QObject): …
20 design  python  mvc  gui  coupling 

5
ทำไมประเภทจะควบคู่ไปกับการสร้าง?
ฉันเพิ่งลบคำตอบjavaของฉันในการตรวจสอบรหัสที่เริ่มต้นเช่นนี้: private Person(PersonBuilder builder) { หยุด. ธงแดง PersonBuilder จะสร้างบุคคล มันรู้เกี่ยวกับบุคคล คลาส Person ไม่ควรรู้อะไรเกี่ยวกับ PersonBuilder - เป็นเพียงประเภทที่ไม่เปลี่ยนรูป คุณสร้างคัปปลิ้งแบบวงกลมตรงนี้โดยที่ A ขึ้นอยู่กับ B ซึ่งขึ้นอยู่กับ A บุคคลนั้นควร จำกัด พารามิเตอร์ของตน ลูกค้าที่เต็มใจสร้างบุคคลโดยไม่สร้างมันควรจะสามารถทำเช่นนั้นได้ ฉันถูกตบด้วย downvote และบอกว่า (อ้างถึง) การตั้งค่าสถานะสีแดงทำไม? การใช้งานที่นี่มีรูปร่างเดียวกับที่ Joshua Bloch แสดงในหนังสือ "Effective Java" ของเขา (รายการ # 2) ดังนั้นดูเหมือนว่าวิธีที่ถูกต้องในการนำรูปแบบการสร้างมาใช้ใน Java คือการสร้างชนิดซ้อน (นี่ไม่ใช่สิ่งที่คำถามนี้เกี่ยวกับว่า) และจากนั้นสร้างผลิตภัณฑ์ (คลาสของวัตถุที่ถูกสร้างขึ้น ) ใช้การพึ่งพาผู้สร้างเช่นนี้ private …

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

3
decoupling คนที่กล้าหาญ DRY เป็น REST หรือไม่?
ฉันกำลังสร้าง REST API เพื่อแสดงการทำงานส่วนใหญ่ของ Java API ที่มีอยู่ API ทั้งสองมีไว้สำหรับใช้ภายในองค์กรของฉัน ฉันไม่ต้องออกแบบเพื่อใช้ภายนอก ฉันมีอิทธิพลเหนือ API ทั้งคู่ แต่กำลังใช้งาน REST อยู่ Java API จะยังคงใช้งานต่อไปสำหรับแอปพลิเคชันในพื้นที่ (ไม่ใช่ "เลิกใช้") แต่ REST API จะใช้สำหรับการพัฒนาใหม่ที่สำคัญ บางคลาส Java API เป็นเพียงข้อมูล (beans ที่มีคุณสมบัติ, getters, setters) และอย่างน้อยสิ่งเหล่านี้ก็เหมาะสมที่จะส่งผ่าน (ในบางรูปแบบ) ผ่าน REST API เป็นข้อมูล (ซึ่งจะถูกจัดให้อยู่ในรูปแบบ XML หรือ JSON) ตัวอย่างเช่นคลาสที่เก็บข้อมูลเกี่ยวกับเครื่องเซิร์ฟเวอร์ ฉันกำลังเผชิญกับตัวเลือกต่อไปนี้สำหรับคลาสข้อมูลเหล่านี้: ฉัน ... เปิดเผยคลาส Java ดั้งเดิม …
19 java  api  rest  coupling  dry 

8
การมีเพศสัมพันธ์กับสตริง“ คลาย” มากกว่าด้วยวิธีการเรียน?
ฉันเริ่มโครงการกลุ่มโรงเรียนใน Java โดยใช้ Swing มันเป็น GUI ที่เรียบง่ายบนแอปเดสก์ท็อปฐานข้อมูล อาจารย์ให้รหัสจากโครงการปีที่แล้วเพื่อให้เราเห็นว่าเขาทำสิ่งต่าง ๆ อย่างไร ความประทับใจครั้งแรกของฉันคือรหัสมีความซับซ้อนมากกว่าที่ควรจะเป็น แต่ฉันคิดว่าโปรแกรมเมอร์มักจะคิดอย่างนี้เมื่อดูรหัสพวกเขาไม่ได้แค่เขียน ฉันหวังว่าจะหาเหตุผลว่าทำไมระบบของเขาถึงดีหรือไม่ดี (ฉันถามอาจารย์และเขาบอกว่าฉันจะเห็นทีหลังว่าทำไมมันถึงดีกว่าซึ่งไม่พอใจฉัน) โดยทั่วไปเพื่อหลีกเลี่ยงการมีเพศสัมพันธ์ระหว่างวัตถุแบบจำลองที่มีอยู่ของเขา (ตรรกะทางธุรกิจ) และมุมมองทุกอย่างจะทำกับสตริง วัตถุที่ยังคงอยู่ที่เก็บไว้ในฐานข้อมูลนั้นคือแฮชของสตริงและโมเดลและมุมมอง "สมัครสมาชิก" ซึ่งกันและกันจัดเตรียมคีย์สตริงสำหรับ "เหตุการณ์" ที่พวกเขาสมัครสมาชิก เมื่อมีการทริกเกอร์เหตุการณ์มุมมองหรือรูปแบบจะส่งสตริงไปยังสมาชิกทั้งหมดของผู้ตัดสินใจว่าจะทำอย่างไรกับเหตุการณ์นั้น ตัวอย่างเช่นในหนึ่งในวิธีการฟังการกระทำมุมมอง (ฉันเชื่อว่านี่เป็นเพียงการตั้งค่า bicycleMakeField บนวัตถุที่คงอยู่): else if(evt.getSource() == bicycleMakeField) { myRegistry.updateSubscribers("BicycleMake", bicycleMakeField.getText()); } ในที่สุดการโทรนั้นถึงวิธีนี้ในโมเดลรถ: public void stateChangeRequest(String key, Object value) { ... bunch of else ifs ... else …
18 java  coupling 

6
ข้อต่อหลวมในการออกแบบเชิงวัตถุ
ฉันพยายามเรียนรู้ GRASP และฉันพบสิ่งนี้อธิบาย ( ที่หน้า 3 ) เกี่ยวกับการมีเพศสัมพันธ์ต่ำและฉันรู้สึกประหลาดใจมากเมื่อฉันพบสิ่งนี้: พิจารณาวิธีการaddTrackสำหรับAlbumชั้นเรียนสองวิธีที่เป็นไปได้คือ: addTrack( Track t ) และ addTrack( int no, String title, double duration ) วิธีใดลดข้อต่อ อย่างที่สองทำเนื่องจากคลาสที่ใช้คลาส Album ไม่จำเป็นต้องทราบคลาส Track โดยทั่วไปพารามิเตอร์สำหรับเมธอดควรใช้ประเภทฐาน (int, char ... ) และคลาสจากแพ็กเกจ java. * ฉันมักจะพูดพล่ามกับเรื่องนี้; ฉันเชื่อว่าaddTrack(Track t)ดีกว่าaddTrack(int no, String title, double duration)เนื่องจากเหตุผลหลายประการ: มันจะดีกว่าเสมอสำหรับวิธีการที่จะทำให้พารามิเตอร์น้อยลงที่สุดเท่าที่จะเป็นไปได้ (ตาม Clean Code ของลุงบ็อบไม่มีหรืออย่างใดอย่างหนึ่งที่ดีกว่า, 2 ในบางกรณีและ …

3
พฤติกรรมการทดสอบหน่วยโดยไม่ต้องเชื่อมต่อกับรายละเอียดการใช้งาน
ในการพูดคุยของเขาTDD มันผิดพลาดที่ไหนเอียนคูเปอร์ผลักดันความตั้งใจดั้งเดิมของเบ็คเบ็คหลังการทดสอบหน่วยใน TDD (เพื่อทดสอบพฤติกรรม ในกรณีของพฤติกรรมเช่นsave X to some data sourceในระบบที่มีชุดบริการและที่เก็บทั่วไปเราจะทดสอบการบันทึกข้อมูลบางอย่างในระดับการบริการผ่านที่เก็บโดยไม่ต้องเชื่อมต่อการทดสอบกับรายละเอียดการใช้งาน (เช่นการเรียกวิธีการเฉพาะ )? การหลีกเลี่ยงการมีเพศสัมพันธ์แบบนี้จริง ๆ แล้วไม่คุ้มค่าความพยายาม / ไม่ดีในบางวิธี?

5
เป็นไปได้ไหมที่จะใช้ DRY โดยไม่ต้องมีเพศสัมพันธ์เพิ่มขึ้น?
สมมติว่าเรามีโมดูลซอฟต์แวร์ A ที่ใช้ฟังก์ชั่น F. โมดูล B อื่นใช้ฟังก์ชั่นเดียวกับ F ' มีหลายวิธีในการกำจัดรหัสที่ซ้ำกัน: ให้ใช้ F 'จาก B ให้ B ใช้ F จาก A ใส่ F ลงในโมดูล C ของตัวเองและปล่อยให้ทั้ง A และ B ใช้งาน ตัวเลือกเหล่านี้ทั้งหมดสร้างการพึ่งพาเพิ่มเติมระหว่างโมดูล พวกเขาใช้หลักการ DRY ที่ค่าใช้จ่ายของการมีเพศสัมพันธ์ที่เพิ่มขึ้น เท่าที่ฉันเห็นการมีเพศสัมพันธ์จะเพิ่มขึ้นเสมอหรือเมื่อถูกเช่าไปในระดับที่สูงขึ้นเมื่อใช้ DRY ดูเหมือนจะมีข้อขัดแย้งระหว่างหลักการพื้นฐานสองข้อที่สำคัญที่สุดของการออกแบบซอฟต์แวร์ (ที่จริงแล้วฉันไม่คิดว่ามันน่าแปลกใจที่มีความขัดแย้งเช่นนั้นนี่อาจเป็นสิ่งที่ทำให้การออกแบบซอฟต์แวร์ที่ดีเป็นเรื่องยากมากฉันรู้สึกประหลาดใจที่โดยทั่วไปแล้วความขัดแย้งเหล่านี้ไม่ได้ระบุไว้ในตำราเบื้องต้น) แก้ไข (เพื่อความกระจ่าง): ฉันคิดว่าความเท่าเทียมกันของ F และ F 'ไม่ใช่แค่เรื่องบังเอิญ หาก F ต้องได้รับการแก้ไข F 'จะต้องได้รับการแก้ไขในลักษณะเดียวกัน

3
การมีเพศสัมพันธ์ของรหัสแนะนำโดย DRY และ OOD
ฉันกำลังมองหาคำแนะนำเกี่ยวกับ DRY กับการแต่งงานกันของ Code ฉันไม่ชอบที่จะทำซ้ำรหัสของฉันและฉันก็ไม่ชอบการเชื่อมต่อโค้ดระหว่างโมดูลที่ไม่เกี่ยวข้อง ดังนั้นฉันจึง refactor รหัสที่ซ้ำกันถ้าฉันพบรหัสที่ซ้ำกันเหมือนกันหนึ่งปีหลังจากที่มีการแนะนำการทำซ้ำ อย่างไรก็ตามฉันมีประสบการณ์ที่มากขึ้นซึ่งโลกแห่งความจริงนั้นไม่อาจคาดเดาได้มากขึ้นและหลังจากการปรับรหัสให้ใหม่แล้ว ตัวอย่างเช่นหากฉันมีรหัสเพื่อจัดการรถยนต์เบนซิน SUV เบนซินรถยนต์ไฟฟ้าและ SUV ไฟฟ้าสมมติว่าฉันได้รับรหัสซ้ำลงในลำดับชั้น "น้ำมัน" และลำดับชั้น "ไฟฟ้า" ทั้งคู่ลงมาจากลำดับ "ยานพาหนะ" จนถึงตอนนี้ดีมาก จากนั้น บริษัท ของฉันแนะนำรถยนต์ไฮบริดและไฮบริดกึ่งซึ่งจะต้องมีการเปลี่ยนแปลงหลักในลำดับชั้นดั้งเดิมของฉันเอง อาจจะต้องมี "องค์ประกอบ" ระหว่างน้ำมันเบนซินและลำดับชั้นไฟฟ้า เห็นได้ชัดว่าการทำสำเนารหัสไม่ดีเพราะเพิ่มเวลาในการดำเนินการเปลี่ยนแปลงร่วมกับผลิตภัณฑ์ทั้งหมดข้างต้น แต่การปรับเปลี่ยนรหัสทั่วไปทำให้ยากที่จะแนะนำรูปแบบเฉพาะของผลิตภัณฑ์และนำไปสู่ ​​"การกระโดดแบบคลาส" เป็นจำนวนมากเมื่อต้องค้นหาบรรทัดของรหัสเพื่อแก้ไขข้อบกพร่อง - การเปลี่ยนแปลงในระดับผู้ปกครองระดับสูงขึ้นสามารถทำได้ ทริกเกอร์การถดถอยข้อบกพร่องในหมู่ลูกหลานทั้งหมด หนึ่งจะสมดุลระหว่าง DRY และการมีเพศสัมพันธ์รหัสที่ไม่พึงประสงค์ได้อย่างไร
14 design  dry  coupling 

5
วิธีการใช้การฉีดพึ่งพาและหลีกเลี่ยงการมีเพศสัมพันธ์ชั่วคราว?
สมมติว่าฉันมีสิ่งServiceที่ได้รับการอ้างอิงผ่านตัวสร้าง แต่ยังต้องเริ่มต้นด้วยข้อมูลที่กำหนดเอง (บริบท) ก่อนจึงจะสามารถใช้: public interface IService { void Initialize(Context context); void DoSomething(); void DoOtherThing(); } public class Service : IService { private readonly object dependency1; private readonly object dependency2; private readonly object dependency3; public Service( object dependency1, object dependency2, object dependency3) { this.dependency1 = dependency1 ?? throw new ArgumentNullException(nameof(dependency1)); …

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