ओओपी और वस्तुओं की स्थिति पर विचार

प्रोग्राम कोड ऊपर से नीचे तक लिखा जाता है। निर्देशों को एक ही क्रम में पढ़ा और निष्पादित किया जाता है। यह तार्किक है और हर कोई लंबे समय से इसका इस्तेमाल कर रहा है। कुछ मामलों में, आप संचालन के क्रम को बदल सकते हैं। लेकिन कभी-कभी फ़ंक्शन कॉल का क्रम महत्वपूर्ण होता है, हालांकि वाक्यात्मक रूप से यह स्पष्ट नहीं है। यह पता चला है कि कॉल को फिर से व्यवस्थित करने के बाद भी कोड काम कर रहा है, और परिणाम अप्रत्याशित है।

एक बार, एक समान कोड ने मेरी आंख को पकड़ लिया।

समस्या

एक बार, एक संयुक्त परियोजना में किसी और के कोड में इधर-उधर ताकते हुए, मैंने एक फ़ंक्शन की खोज की:

public Product fill(Product product, Images images, Prices prices, Availabilities availabilities){ priceFiller.fill(product, prices); //do not move this line below availabilityFiller call, availabilities require prices availabilityFiller.fill(product, availabilities); imageFiller.fill(product, images); return product; } 

बेशक, सबसे "सुरुचिपूर्ण" शैली आपकी आंख को नहीं पकड़ती है: कक्षाएं स्टोर डेटा (पीओजेओ), फ़ंक्शन आने वाली वस्तुओं को बदल देती हैं ...

सामान्य तौर पर, यह कुछ भी नहीं लगता है। हमारे पास एक ऐसी वस्तु है जिसमें पर्याप्त डेटा नहीं है, और स्वयं डेटा है जो अन्य स्रोतों (सेवाओं) से आया है, जिसे अब हम इसे पूरा करने के लिए इस ऑब्जेक्ट में जगह देंगे।

लेकिन कुछ बारीकियां हैं।

1. मैं इस तथ्य की तरह नहीं हूं कि एफपी की शैली में एक भी फ़ंक्शन नहीं लिखा गया है और तर्क के रूप में पारित ऑब्जेक्ट को संशोधित करता है।
   
   • लेकिन बता दें कि ऐसा प्रसंस्करण समय और निर्मित वस्तुओं की संख्या को कम करने के लिए किया गया था।
2. कोड में केवल एक टिप्पणी कहती है कि कॉल का क्रम महत्वपूर्ण है, और नए Filler एम्बेड करते समय आपको सावधान रहना चाहिए
   
   • लेकिन प्रोजेक्ट पर काम करने वाले लोगों की संख्या 1 से अधिक है और हर कोई इस ट्रिक के बारे में नहीं जानता है। टीम में विशेष रूप से नए लोग (उद्यम में जरूरी नहीं)।

अंतिम बिंदु ने मुझे विशेष रूप से पहरा दिया। आखिरकार, एपीआई इस तरह से बनाया गया है कि हम यह नहीं जानते कि इस फ़ंक्शन को कॉल करने के बाद ऑब्जेक्ट में क्या बदलाव आया है। उदाहरण के लिए, पहले और बाद में हमारे पास एक Product::getImages विधि है, जो fill फ़ंक्शन को कॉल करने से पहले, एक खाली सूची का उत्पादन करेगी, और फिर हमारे उत्पाद के चित्रों के साथ एक सूची।

Filler साथ Filler चीजें और भी खराब हैं। AvailabilityFiller यह स्पष्ट नहीं करता है कि यह उम्मीद करता है कि माल की कीमत के बारे में जानकारी पहले से ही स्थानांतरित वस्तु में अंतर्निहित है।

और इसलिए मैंने सोचा कि मैं अपने सहयोगियों को कार्यों के गलत उपयोग से कैसे बचा सकता हूं।

प्रस्तावित समाधान

सबसे पहले, मैंने अपने सहयोगियों के साथ इस मामले पर चर्चा करने का फैसला किया। दुर्भाग्य से, उनके द्वारा प्रस्तावित सभी समाधान मुझे सही दृष्टिकोण नहीं लगते थे।

RuntimeException

प्रस्तावित विकल्पों में से एक था: और आप फ़ंक्शन Objects.requireNonNull(product.getPrices) की शुरुआत में Objects.requireNonNull(product.getPrices) और फिर किसी भी प्रोग्रामर को स्थानीय परीक्षणों के दौरान पहले से ही एक त्रुटि प्राप्त होगी।

• लेकिन कीमत वास्तव में नहीं हो सकती है, यदि सेवा अनुपलब्ध थी या कोई अन्य गलती थी, तो उत्पाद को "स्टॉक से बाहर" की स्थिति प्राप्त होनी चाहिए। हमें "किसी भी डेटा" को "अनुरोधित भी नहीं" से अलग करने के लिए सभी प्रकार के झंडे या कुछ भी विशेषता है।
  
  • यदि आप अपने आप को getPrices में एक अपवाद फेंक देते हैं, तो हम सूचियों के साथ आधुनिक जावा के समान समस्याएं पैदा करेंगे
    
    • मान लीजिए कि एक सूची एक फ़ंक्शन को दी गई है जो इसके एपीआई में विधि प्राप्त करती है ... मुझे पता है कि आपको स्थानांतरित वस्तुओं को बदलने की आवश्यकता नहीं है, लेकिन नए बनाएं। लेकिन लब्बोलुआब यह है कि एपीआई हमें इस तरह की एक विधि प्रदान करता है, लेकिन रनटाइम में एक त्रुटि हो सकती है यदि यह एक अपरिवर्तनीय सूची है, जैसे कि कलेक्टर से प्राप्त की गई।
• अगर किसी अन्य व्यक्ति द्वारा AvailabilityFiller का उपयोग किया जाता है, तो प्रोग्रामर जिसने कॉल लिखा है वह तुरंत समझ नहीं पाएगा कि समस्या क्या है। लॉन्च और डेब्यू के बाद ही। फिर उसे अभी भी कोड को समझना है कि डेटा कहां मिलेगा।

कसौटी

"और आप एक परीक्षण लिखते हैं जो कॉल के क्रम को बदलने पर टूट जाएगा।" यानी यदि सभी Filler एक "नया" उत्पाद लौटाते हैं, तो ऐसा कुछ होगा:

 given(priceFillerMock.fill(eq(productMock), any())).willReturn(productWithPricesMock); given(availabilityFillerMock.fill(eq(productMockWithPrices), any())).willReturn(productMockWithAvailabilities); given(imageFillerMock.fill(eq(productMockWithAvailabilities), any())).willReturn(productMockWithImages); var result = productFiller.fill(productMock, p1, p2, p3); assertThat("unexpected return value", result, is(productMockWithImages)); 

• मुझे ऐसे परीक्षण पसंद नहीं हैं जो "व्हाइट-बॉक्स" हैं
• हर नए Filler साथ ब्रेक
• यह स्वतंत्र कॉल के अनुक्रम को बदलते समय टूट जाता है
• दोबारा, यह AvailabilityFiller के पुन: उपयोग की समस्या को हल नहीं करता है

समस्या को हल करने के लिए स्वयं के प्रयास

विचार

मुझे लगता है कि आपने पहले ही अनुमान लगा लिया था कि मैं संकलन स्तर पर समस्या को हल करना चाहूंगा। खैर, मुझे क्यों आवश्यकता है, एक पूछता है, मजबूत टाइपिंग के साथ एक संकलित भाषा यदि मैं त्रुटि को रोक नहीं सकता हूं।

और मुझे आश्चर्य हुआ कि क्या अतिरिक्त डेटा के बिना कोई ऑब्जेक्ट और "विस्तारित" ऑब्जेक्ट एक ही वर्ग के हैं?

क्या किसी ऑब्जेक्ट के विभिन्न संभावित राज्यों को अलग-अलग वर्गों या इंटरफेस के रूप में वर्णित करना सही नहीं होगा?

तो मेरा विचार यह था:

 public Product fill(<? extends BaseProduct> product, Images images, Prices prices, Availabilities availabilities){ var p1 = priceFiller.fill(product, prices); var p2 = availabilityFiller.fill(p1, availabilities); return imageFiller.fill(p2, images); } PriceFiller public ProductWithPrices fill(<? extends BaseProduct> product, Prices prices) AvailabilityFiller public ProductWithAvailabilities fill(<? extends ProductWithPrices> product, Prices prices)  public <BaseProduct & PriceAware & AvailabilityAware> fill(<? extends BaseProduct & PriceAware> product, Prices prices) 

यानी मूल रूप से परिभाषित उत्पाद लौटाए गए वर्ग के अलावा एक वर्ग का एक उदाहरण है, जो पहले से ही डेटा परिवर्तन दिखाता है।

Filler , अपने API में, यह निर्दिष्ट करते हैं कि उन्हें किस डेटा की आवश्यकता है और वे क्या वापस करते हैं।

इस तरह आप गलत कॉल अनुक्रम को रोक सकते हैं।

कार्यान्वयन

जावा में वास्तविकता में इसका अनुवाद कैसे करें? (याद रखें कि जावा में कई वर्गों से विरासत में प्राप्त करना संभव नहीं है।)

जटिलता को स्वतंत्र संचालन द्वारा जोड़ा जाता है। उदाहरण के लिए, चित्रों को कीमतों को जोड़ने से पहले और बाद में जोड़ा जा सकता है, साथ ही फ़ंक्शन के बहुत अंत में भी।
तब शायद

 class ProductWithImages extends BaseProduct implements ImageAware{} class ProductWithImagesAndPrices extends BaseProduct implements ImageAware, PriceAware{} class Product extends BaseProduct implements ImageAware, PriceAware, AvailabilityAware{} 

यह सब कैसे वर्णन करें?

एडेप्टर बनाएं?

 public ProductWithImagesAndPrices(<? extends BaseProduct & PriceAware> base){ this.base = base; this.images = Collections.emptyList(); } public long getId(){ return this.base.getId(); } public Price getPrice(){ return this.base.getPrice(); } public List<Image> getImages(){ return this.images; } 

कॉपी डाटा / लिंक?

 public ProductWithImagesAndPrices(<? extends BaseProduct & PriceAware> base){ this.id = base.getId(); this.prices = base.getPrices(); this.images = Collections.emptyList(); } public List<Image> getImages(){ return this.images; } 

जैसा कि पहले से ही ध्यान देने योग्य है, यह सब कोड की एक बड़ी राशि के लिए नीचे आता है। और यह इस तथ्य के बावजूद कि उदाहरण में मैंने केवल 3 प्रकार के इनपुट डेटा को छोड़ दिया। वास्तविक दुनिया में, कई और भी हो सकते हैं।

यह पता चला है कि इस तरह के कोड को लिखने और बनाए रखने की लागत खुद को सही नहीं ठहराती है, हालांकि राज्य को अलग-अलग वर्गों में विभाजित करने का विचार मुझे बहुत आकर्षक लगा।

पीछे हटना

यदि आप अन्य भाषाओं को देखते हैं, तो कहीं न कहीं इस समस्या को हल करना आसान है, लेकिन कहीं नहीं।
उदाहरण के लिए, गो में आप "कॉपी" या "ओवरलोडिंग" विधियों के बिना एक एक्स्टेंसिबल क्लास के लिए एक संदर्भ लिख सकते हैं। लेकिन यह गो के बारे में नहीं है

एक और विषयांतर

इस लेख को लिखते समय, एक और संभावित समाधान Proxy साथ आया, जिसने केवल नए तरीकों को लिखने के लिए बुलाया, लेकिन इंटरफेस के एक पदानुक्रम की आवश्यकता थी। सामान्य तौर पर, डरावना, गुस्सा और उपयुक्त नहीं। अगर किसी को अचानक दिलचस्पी है:

 public class Application { public static void main(String[] args) { var baseProduct = new BaseProductProxy().create(new BaseProductImpl(100L)); var productWithPrices = fillPrices(baseProduct, BigDecimal.TEN); var productWithAvailabilities = fillAvailabilities(productWithPrices, "available"); var productWithImages = fillImages(productWithAvailabilities, List.of("url1, url2")); var product = productWithImages; System.out.println(product.getId()); System.out.println(product.getPrice()); System.out.println(product.getAvailability()); System.out.println(product.getImages()); } static <T extends BaseProduct> ImageAware fillImages(T base, List<String> images) { return (ImageAware) Proxy.newProxyInstance(base.getClass().getClassLoader(), new Class[]{ImageAware.class, BaseProduct.class}, new MyInvocationHandler<>(base, new ImageAware() { @Override public List<String> getImages() { return images; } })); } static <T extends BaseProduct> PriceAware fillPrices(T base, BigDecimal price) { return (PriceAware) Proxy.newProxyInstance(base.getClass().getClassLoader(), new Class[]{PriceAware.class}, new MyInvocationHandler<>(base, new PriceAware() { @Override public BigDecimal getPrice() { return price; } })); } static AvailabilityAware fillAvailabilities(PriceAware base, String availability) { return (AvailabilityAware) Proxy.newProxyInstance(base.getClass().getClassLoader(), new Class[]{AvailabilityAware.class}, new MyInvocationHandler<>(base, new AvailabilityAware() { @Override public String getAvailability() { return base.getPrice().intValue() > 0 ? availability : "sold out"; } })); } static class BaseProductImpl implements BaseProduct { private final long id; BaseProductImpl(long id) { this.id = id; } @Override public long getId() { return id; } } static class BaseProductProxy { BaseProduct create(BaseProduct base) { return (BaseProduct) Proxy.newProxyInstance(this.getClass().getClassLoader(), new Class[]{BaseProduct.class}, new MyInvocationHandler<>(base, base)); } } public interface BaseProduct { default long getId() { return -1L; } } public interface PriceAware extends BaseProduct { default BigDecimal getPrice() { return BigDecimal.ZERO; } } public interface AvailabilityAware extends PriceAware { default String getAvailability() { return "sold out"; } } public interface ImageAware extends AvailabilityAware { default List<String> getImages() { return Collections.emptyList(); } } static class MyInvocationHandler<T extends BaseProduct, U extends BaseProduct> implements InvocationHandler { private final U additional; private final T base; MyInvocationHandler(T base, U additional) { this.additional = additional; this.base = base; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { if (Arrays.stream(additional.getClass().getInterfaces()).anyMatch(i -> i == method.getDeclaringClass())) { return method.invoke(additional, args); } var baseMethod = Arrays.stream(base.getClass().getMethods()).filter(m -> m.getName().equals(method.getName())).findFirst(); if (baseMethod.isPresent()) { return baseMethod.get().invoke(base, args); } throw new NoSuchMethodException(method.getName()); } } } 

निष्कर्ष

क्या निकला? एक ओर, एक दिलचस्प दृष्टिकोण है जो अलग-अलग वर्गों को "ऑब्जेक्ट" में अलग-अलग राज्यों में लागू करता है और इस ऑब्जेक्ट को संशोधित करने वाले तरीकों को कॉल के गलत अनुक्रम के कारण त्रुटियों की रोकथाम की गारंटी देता है।

दूसरी ओर, यह दृष्टिकोण आपको इतना कोड लिखता है कि आप तुरंत इसे अस्वीकार करना चाहते हैं। इंटरफेस और कक्षाओं का ढेर केवल परियोजना को समझना मुश्किल बनाता है।

मेरी अन्य परियोजना में, मैंने अभी भी इस दृष्टिकोण का उपयोग करने की कोशिश की। और पहले इंटरफ़ेस स्तर पर, सब कुछ ठीक था। मैंने कार्य लिखे:

 <T extends Foo> List<T> firstStep(List<T> ts){} <T extends Foo & Bar> List<T> nStep(List<T> ts){} <T extends Foo> List<T> finalStep(List<T> ts){} 

इस प्रकार यह संकेत दिया गया है कि एक निश्चित डेटा प्रोसेसिंग कदम के लिए अतिरिक्त जानकारी की आवश्यकता होती है जो प्रसंस्करण की शुरुआत में या उसके अंत में आवश्यक नहीं है।

mock का उपयोग करके 'और, मैं कोड का परीक्षण करने में कामयाब रहा। लेकिन जब इसे लागू किया गया और डेटा और विभिन्न स्रोतों की मात्रा बढ़ने लगी, तो मैंने जल्दी से सब कुछ छोड़ दिया और सबकुछ "सामान्य" रूप में बदल दिया। सब कुछ काम करता है और कोई शिकायत नहीं करता है। यह पता चला है कि कोड की दक्षता और सरलता त्रुटियों की "रोकथाम" पर विजय पाती है, और आप मैन्युअल रूप से कॉल के सही अनुक्रम का पता लगा सकते हैं, भले ही त्रुटि मैन्युअल परीक्षण चरण में ही प्रकट हो।

शायद अगर मैंने एक कदम पीछे ले लिया और दूसरी तरफ से कोड को देखा, तो मेरे पास पूरी तरह से अलग समाधान होंगे। लेकिन ऐसा हुआ कि मुझे इस विशेष टिप्पणी लाइन में दिलचस्पी हो गई।

पहले से ही लेख के अंत में, इस तथ्य के बारे में सोचते हुए कि चूंकि इंटरफेस में बसने का वर्णन करना अच्छा नहीं है, आप Builder के रूप में उत्पाद डेटा की विधानसभा की कल्पना कर सकते हैं, जो परिभाषित डेटा को जोड़ने के बाद एक अलग इंटरफ़ेस देता है। फिर, यह सब वस्तुओं के निर्माण के तर्क की जटिलता पर निर्भर करता है। यदि आपने स्प्रिंग सिक्योरिटी के साथ काम किया है, तो आप इस तरह के समाधान से परिचित हैं।

मेरे उदाहरण के लिए, यह जाता है:

 public class Application_2 { public static void main(String[] args) { var product = new Product.Builder() .id(1000) .price(20) .availability("available") .images(List.of("url1, url2")) .build(); System.out.println(product.getId()); System.out.println(product.getAvailability()); System.out.println(product.getPrice()); System.out.println(product.getImages()); } static class Product { private final int price; private final long id; private final String availability; private final List<String> images; private Product(int price, long id, String availability, List<String> images) { this.price = price; this.id = id; this.availability = availability; this.images = images; } public int getPrice() { return price; } public long getId() { return id; } public String getAvailability() { return availability; } public List<String> getImages() { return images; } public static class Builder implements ProductBuilder, ProductWithPriceBuilder { private int price; private long id; private String availability; private List<String> images; @Override public ProductBuilder id(long id) { this.id = id; return this; } @Override public ProductWithPriceBuilder price(int price) { this.price = price; return this; } @Override public ProductBuilder availability(String availability) { this.availability = availability; return this; } @Override public ProductBuilder images(List<String> images) { this.images = images; return this; } public Product build(){ var av = price > 0 && availability != null ? availability : "sold out"; return new Product(price, id, av, images); } } public interface ProductBuilder { ProductBuilder id(long id); ProductBuilder images(List<String> images); ProductWithPriceBuilder price(int price); Product build(); } public interface ProductWithPriceBuilder{ ProductBuilder availability(String availability); } } } 

ताकि:

• साफ सुथरी विशेषताएँ लिखिए
• सुंदर और स्पष्ट कोड लिखें
• याद रखें कि संक्षिप्तता एक बहन है और सबसे महत्वपूर्ण बात यह है कि कोड काम करता है
• बेझिझक चीजों पर सवाल करें, अन्य तरीकों की तलाश करें, और यहां तक ​​कि वैकल्पिक समाधान भी फेंक दें
• चुप मत रहो! जब किसी समस्या को दूसरों को समझाते हैं, तो बेहतर समाधान पैदा होते हैं (रबर डक ड्रिवेन डेवलपमेंट)

आपका ध्यान के लिए धन्यवाद।