मैंने अभी "ग्रोइंग ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर" पुस्तक का एक अंश पढ़ा है जो कुछ कारणों की व्याख्या करता है कि कंक्रीट क्लास की सिफारिश क्यों नहीं की जाती है।
यहां म्यूज़िक वेबकैम क्लास के लिए यूनिट-टेस्ट के कुछ सैंपल कोड:
public class MusicCentreTest {
@Test public void startsCdPlayerAtTimeRequested() {
final MutableTime scheduledTime = new MutableTime();
CdPlayer player = new CdPlayer() {
@Override
public void scheduleToStartAt(Time startTime) {
scheduledTime.set(startTime);
}
}
MusicCentre centre = new MusicCentre(player);
centre.startMediaAt(LATER);
assertEquals(LATER, scheduledTime.get());
}
}और उनकी पहली व्याख्या:
इस दृष्टिकोण के साथ समस्या यह है कि यह अंतर्निहित वस्तुओं के बीच संबंध को छोड़ देता है। मुझे उम्मीद है कि हमने अब तक स्पष्ट कर दिया है कि मॉक ऑब्जेक्ट्स के साथ टेस्ट-ड्रिवेन डेवलपमेंट का उद्देश्य वस्तुओं के बीच संबंधों की खोज करना है। यदि मैं उपवर्ग करता हूं, तो इस तरह के संबंध को दृश्यमान बनाने के लिए डोमेन कोड में कुछ भी नहीं है, बस एक वस्तु पर तरीके। इससे यह देखना कठिन हो जाता है कि क्या इस रिश्ते का समर्थन करने वाली सेवा कहीं और प्रासंगिक हो सकती है और मुझे अगली बार कक्षा के साथ काम करने के बाद फिर से विश्लेषण करना होगा।
मैं ठीक-ठीक पता नहीं लगा सकता कि उसके कहने का क्या मतलब है:
इससे यह देखना कठिन हो जाता है कि क्या इस रिश्ते का समर्थन करने वाली सेवा कहीं और प्रासंगिक हो सकती है और मुझे अगली बार कक्षा के साथ काम करने के बाद फिर से विश्लेषण करना होगा।
मैं समझता हूँ कि सेवा MusicCentreनामक विधि से मेल खाती है startMediaAt।
"अन्यत्र" से उसका क्या अर्थ है?
पूरा अंश यहाँ है: http://www.mockobjects.com/2007/04/test-smell-mocking-concrete-classes.html