কোন অনুষ্ঠানকে একটি খারাপ অভ্যাস বলার উপায় কি?

10

আমার কাছে নিম্নলিখিত কোড রয়েছে:

public void moveCameraTo(Location location){
    moveCameraTo(location.getLatitude(), location.getLongitude());
}

public void moveCameraTo(double latitude, double longitude){
    LatLng latLng = new LatLng(latitude, longitude);
    moveCameraTo(latLng);
}

public void moveCameraTo(LatLng latLng){
    GoogleMap googleMap =  getGoogleMap();
    cameraUpdate = CameraUpdateFactory.newLatLngZoom(latLng, INITIAL_MAP_ZOOM_LEVEL);
    googleMap.moveCamera(cameraUpdate);
}

আমি মনে করি যে এইভাবে আমি LatLngঅন্য শ্রেণিতে কী কী তা জানার দায়িত্বটি মুছে ফেলি , উদাহরণস্বরূপ।

এবং ফাংশনটি কল করার আগে আপনাকে ডেটা প্রস্তুত করার দরকার নেই।

আপনি কি মনে করেন?

এই পদ্ধতির একটি নাম আছে? এটা কি আসলেই খারাপ অভ্যাস?

— Tlaloc-এস
সূত্র

2

আমি মনে করি আপনি কেবল ভাষাটির অন্তর্নির্মিত পদ্ধতি ওভারলোডিং ব্যবহার করে এনক্যাপসুলেশন নিয়ে কাজ করছেন। এটা ভাল / খারাপ না। কেবলমাত্র একটি সরঞ্জাম যা আপনার কোডকে সহায়তা করতে বা ক্ষতি করতে পারে।

— বিটসফ্লোগিক

5

যদি আপনার লক্ষ্য LatLngএই Cameraশ্রেণীর ক্লায়েন্টদের থেকে গোপন করা হয় , তবে আপনি সম্ভবত তা হতে চান moveCameraTo(LatLng)না public।

— বিটসফ্লোগিক

উত্তরে প্রদত্ত পরামর্শ ছাড়াও এটি YAGNI উল্লেখ করার জন্য ভাল জায়গা বলে মনে হচ্ছে। তোমার দরকার নেই ভাল ব্যবহারের ক্ষেত্রে এপিআই পদ্ধতিগুলি সংজ্ঞায়িত করবেন না কারণ ... আপনার এটি দরকার নেই।

— প্যাট্রিক হিউজেস

moveCameraToLocationএবং moveCameraTo/ এর সাথে কোনও ভুল নেই moveCameraToCoords। অবশ্যই অবস্থান / ল্যাট / দীর্ঘ সব একই নামে পাস করতে চাইবে না।

— ইনসাইডিন

9

আপনি অবস্থানের তথ্যের উপর নির্ভরশীলতার পদ্ধতিগুলি সমাধানের কলারের বিকল্প উপায়গুলি সরবরাহ করতে আপনার ভাষা পদ্ধতি ওভারলোডিং বৈশিষ্ট্যটি ব্যবহার করছেন। তারপরে আপনি ক্যামেরা আপডেট করার বাকী কাজটি সমাধান করার জন্য অন্য কোনও পদ্ধতিতে প্রতিনিধিত্ব করছেন।

এখানে কোড গন্ধ হবে যদি আপনি কেবল কল করার পদ্ধতিগুলির শৃঙ্খলা প্রসারিত করেন। অবস্থান গ্রহণের পদ্ধতিটি ডাবল গ্রহণ পদ্ধতিকে কল করে যা ল্যাটলিং গ্রহণ পদ্ধতিটিকে কল করে যা শেষ পর্যন্ত এমন কিছু কল করে যা ক্যামেরা আপডেট করতে জানে।

দীর্ঘ চেইনগুলি কেবল তাদের দুর্বলতম লিঙ্কের মতোই শক্তিশালী। চেইনের প্রতিটি এক্সটেনশন কোডের পদচিহ্নগুলিকে বাড়ায় যা কাজ করে বা এই জিনিসটি ভেঙে যায়।

প্রতিটি পদ্ধতি যদি এটি উপস্থাপিত করা হয়েছে সমস্যা সমাধানের জন্য সবচেয়ে সংক্ষিপ্ততম পথ অবলম্বন করে তবে এটি অনেক উন্নত নকশা। এর অর্থ এই নয় যে প্রত্যেকের অবশ্যই ক্যামেরা আপডেট করতে হবে know প্রত্যেকেরই তাদের অবস্থানের প্যারামিটারের ধরনটি এক ইউনিফর্মের সাথে অনুবাদ করতে হবে যা এমন কোনও কিছুতে যেতে পারে যা এই ধরণের উপস্থাপনের সময় ক্যামেরা আপডেট করতে কীভাবে জানে does

এটি সেভাবে করুন এবং আপনি সমস্ত কিছুর অর্ধেক ভাঙা ছাড়াই একটি মুছতে পারেন।

বিবেচনা:

public void moveCameraTo(Location location){
    moveCameraTo( new LatLng(location) );
}

এটি অক্ষাংশ এবং দ্রাঘিমাংশের LatLngসমস্যা মোকাবেলা করে। খরচ এটি LatLngপ্রায় জ্ঞান ছড়িয়ে দেয় । এটি ব্যয়বহুল বলে মনে হতে পারে তবে আমার অভিজ্ঞতাতে এটি আদিম আবেগের একটি পছন্দনীয় বিকল্প যা প্যারামিটার অবজেক্টটি স্থাপন করা এড়িয়ে যাওয়া আপনাকে আটকে দেয়।

যদি Locationতা অপসারণযোগ্য তবে LatLngতা না হলে কারখানায় যুক্ত করে এটি সমাধান করার বিষয়টি বিবেচনা করুন Location:

moveCameraTo( location.ToLatLng() );

এটি সুন্দরভাবে আদিম আবেগ এড়ানো যায়।

— candied_orange
সূত্র

1

আমার কাছে এটি খারাপ মনে হয় না - এটি সত্যই ভোক্তার জন্য সহজ একটি সুবিধা। যদি এটি 10 বার বেঁধে রাখা হয় বা যদি গ্রাহককে সত্যই এই সমস্ত বিকল্পের প্রয়োজন না হয় তবে আমি এটিকে কোড গন্ধ বলব।

— mcknz

1

তবে বিকল্পটি প্রতিটি কার্যক্রমে ডাবলগুলিকে ল্যাংএলএঞ্জ বা লোকাল থেকে লগএলজে রূপান্তর করার জন্য সমস্ত যুক্তি রাখে কি?

— টালোক-ইএস

@ টালোক-ইএস আরও ভাল?

— candied_orange

@ ট্যালালোক-ইএস "ট্রান্সফর্ম" কেবল তখনই হওয়া দরকার যখন আদিমরা ডোমেন যুক্তিতে লোড করা হচ্ছে। আপনি যখন ডিটিও-কে deserialize করেন তখন এটি ঘটবে। তারপরে, আপনার সমস্ত ডোমেন যুক্তি চারপাশে LatLngবা Locationবস্তুগুলিতে চলে যেতে পারে । আপনি দুটি মধ্যে সম্পর্ক দেখাতে পারেন New LatLng(Location)বা Location.toLatLng()আপনি থেকে এক অন্য যেতে হবে।

— বিটসোফ্লোগিক

1

@ টালোক-ইএস সম্পর্কিত পাঠ: মার্টিন ফওলারের ফ্ল্যাগআরগমেন্ট । "জটযুক্ত বাস্তবায়ন" বিভাগটি পড়ুন।

— ২২7777২

8

আপনার সমাধানে বিশেষত কোনও ভুল নেই।

তবে আমার ব্যক্তিগত পছন্দটি হ'ল যে এই পদ্ধতিগুলি সেগুলি কার্যকর নয়। এবং কেবল যে বস্তুটি তারা বন্ধ রয়েছে তার ইন্টারফেসটিকে জটিল করুন।

void moveCameraTo(double latitude, double longitude)সত্যিই, কোড প্রক্রিয়া সহজ করে না আমি কোন সমস্যা সহজভাবে কলিং দেখতে moveCameraTo(new LatLng(latitude, longitude));এটা জায়গায়। এই পদ্ধতিতে আদিম আবেশের গন্ধও রয়েছে।

void moveCameraTo(Location location)ভাল প্রতিপাদন এটা ঠিক হয়ে যেতে পারে Location.ToLatLng()পদ্ধতি এবং কলিং moveCameraTo(location.ToLatLng())।

যদি এটি সি # হয় এবং যদি এই জাতীয় পদ্ধতিগুলি সত্যই প্রয়োজন হয় তবে আমি উদাহরণ পদ্ধতির পরিবর্তে তাদেরকে এক্সটেনশন পদ্ধতি হিসাবে পছন্দ করব। আপনি যদি বিমূর্তিটি দূরে সরিয়ে চেষ্টা করেন এবং এই উদাহরণটিকে ইউনিট-টেস্ট করে থাকেন তবে এক্সটেনশন পদ্ধতির ব্যবহার সত্যই স্পষ্ট হয়ে উঠবে। যেহেতু সহজ রূপান্তরগুলি সহ একাধিক ওভারলোডের পরিবর্তে কেবল একক পদ্ধতি নকল করা আরও সহজ হবে।

আমি মনে করি যে এইভাবে আমি অন্য ক্লাসে ল্যাটল্যাং কী তা জানার দায়িত্বটি মুছে ফেলি, উদাহরণস্বরূপ।

আমি কেন এই সমস্যা হবে তার কোনও কারণ দেখছি না। আপনার কোড রেফারেন্স ক্লাস যতক্ষণ থাকে void moveCameraTo(LatLng latLng), ততক্ষণ এটি পরোক্ষভাবে নির্ভর করে LatLng। এমনকি যদি class শ্রেণিটি কখনও সরাসরি তাত্ক্ষণিক না হয়।

এবং ফাংশনটি কল করার আগে আপনাকে ডেটা প্রস্তুত করার দরকার নেই।

তুমি কী বলতে চাচ্ছ আমি বুঝতে পারছি না। এর অর্থ যদি নতুন উদাহরণ তৈরি করা বা ক্লাসগুলি একে অপর থেকে রূপান্তরিত করা হয় তবে আমি এতে কোনও সমস্যা দেখছি না।

এ সম্পর্কে চিন্তাভাবনা করে, আমি অনুভব করি যে আমি যা বলছি তা নিজেই নেট নেট এর এপিআই ডিজাইন দ্বারা সমর্থিত। Orতিহাসিকভাবে, প্রচুর। নেট ক্লাসগুলি বিভিন্ন পরামিতিগুলির সাথে প্রচুর ওভারলোড এবং অভ্যন্তরে সরল রূপান্তরগুলি গ্রহণ করার পদ্ধতি অনুসরণ করে। তবে এটি ছিল এক্সটেনশন পদ্ধতিগুলির অস্তিত্বের আগে। আরও আধুনিক। নেট ক্লাসগুলি তাদের নিজস্ব এপিআইগুলিতে বেশি হালকা ওজনযুক্ত এবং যদি প্যারামিটার ওভারলোডগুলি নিয়ে কোনও পদ্ধতি থাকে তবে সেগুলি এক্সটেনশন পদ্ধতি হিসাবে সরবরাহ করা হয়। পুরানো উদাহরণ হ'ল এনলগ আইএলগার যা লগতে লেখার জন্য কয়েক ডজন ওভারলোড রয়েছে। এটি নতুন মাইক্রোসফ্টের সাথে তুলনা করুন x এক্সটেনশনগুলি.লগিং.আইএলওগারের সাথে মোট 3 টি পদ্ধতি রয়েছে (এবং আপনি যদি লগিং নিজেই গণনা করেন তবে কেবল 1 টি)। তবে সম্প্রসারণের পদ্ধতি হিসাবে প্রচুর সহায়ক এবং বিভিন্ন প্যারামিটারাইজেশন রয়েছে ।

আমি মনে করি এই উত্তরটি দেখায় যে কিছু ভাষার কাছে এই ভাল মতো নকশা তৈরির সরঞ্জাম থাকবে। আমি বেশি জাভা জানি না, সুতরাং এর সমতুল্যতা আছে কিনা তা আমি নিশ্চিত নই। এমনকি প্লেইন স্ট্যাটিক পদ্ধতি ব্যবহার করাও একটি বিকল্প হতে পারে।

— euphoric
সূত্র

নিশ্চিত না কেন তবে প্রতিযোগী হওয়া সত্ত্বেও আমি নিজেকে এই উত্তরের মূলটি খুঁজে পাচ্ছি। আমি মনে করি আপনি ঠিক পয়েন্টটি আরও ভালভাবে পরিচালনা করতে পেরেছেন। আমার একমাত্র প্রতিক্রিয়া মনে রাখতে হবে যে এই সমস্যাটি নিয়ে কাজ করা প্রত্যেকে .NET অন নয়। +1

— candied_orange

নিবন্ধন করুন এখন যেহেতু আমি ওপি-র প্রশ্নের দিকে আরও ভাল দেখছি, সেটিকে সি # এর চেয়ে আরও বেশি জাভা মনে হচ্ছে।

— ইউফোরিক

আমি মনে করি যে moveCameraTo(new LatLng(latitude, longitude));প্রকল্পের যে কোনও জায়গায় ব্যবহার করতে আসলেই সমস্যা নেই , তবে আমি মনে করি যে এটি আরও স্পষ্টভাবে ব্যবহারযোগ্যভাবে মুভক্যামেটাটো (ল্যাটল্যাং) জাভাতে থাকা একটি ফাইলের মতো যা আপনি স্ট্রিংয়ের মতো পথ পাস করতে পারেন, বা কোনও পথ শ্রেণির মতো

— টালোক-ইএস

1

আমি নিশ্চিত নই যে এর সঠিক নামটি কী, যদি এর একটি থাকে তবে এটি ভাল অনুশীলন। কলিং ক্লাসটি কোন প্যারামিটার সেটটি ব্যবহার করতে চায় তা নির্ধারণের জন্য আপনি একাধিক ওভারলোডগুলি প্রকাশ করেছেন। আপনি যেমনটি বলেছেন, অন্য শ্রেণি হয়ত LatLngঅবজেক্টটি কী তা জানেন না , তবে এটি এটি জানেন Location।

একটি পদ্ধতি অন্যকে কল করাও কী, কারণ আপনি এই পদ্ধতিগুলির মধ্যে নকল কোডটি চান না। আপনি যেমনটি করেছেন, কাজটি করে এমন একটি পদ্ধতি বেছে নিন এবং অন্য পদ্ধতিগুলি এটিকে কল করুন (প্রত্যক্ষ বা পরোক্ষভাবে)

— mmathis
সূত্র

1

যদি আপনি ধরণের পদ্ধতি ব্যবহারে আপত্তি করেন তবে এটি কেবল পদ্ধতি-ওভারলোডিং বৈশিষ্ট্যটি ভাল।

তবে ল্যাটল্যাং কী তা জানার দায়িত্বটি সরিয়ে নেই । কারণ আপনি আরম্ভ করছেন LatLng latLng = new LatLng(latitude, longitude)। এটি সম্পূর্ণরূপে নির্ভরতা LatLng। (কেন ইনিশিয়ালাইজিং নির্ভরশীল সমস্যা, তা বোঝার জন্য আপনি নির্ভরশীল ইনজেকশনটি পরীক্ষা করতে পারেন ) অতিরিক্ত লোড পদ্ধতি তৈরি করা কেবলমাত্র তাদের ক্লায়েন্টদেরই সহায়তা করে না যারা যত্ন নেন না LatLng। আপনি যদি এটি বোঝাতে চান তবে এটিও ভাল তবে আমি এটি একটি পদ্ধতির বলে মনে করি না। এটি ক্লায়েন্টদের জন্য কেবল অনেক পরিষেবা পদ্ধতি।

সুতরাং, আপনার আর্কিটেকচারটি ডিজাইনের জন্য দুটি বিকল্প রয়েছে:

অনেক বেশি বোঝা পদ্ধতি তৈরি করুন এবং তাদের ক্লায়েন্টকে সরবরাহ করুন।
ইন্টারফেস বা কংক্রিটের ক্লাস হিসাবে প্যারামিটারগুলির প্রয়োজন এমন কয়েকটি ওভারলোডেড পদ্ধতি তৈরি করুন।

প্যারামিটার হিসাবে প্রাথমিক ধরণের প্রয়োজন (এমন বিকল্প 1) এমন পদ্ধতি তৈরি থেকে আমি যতটা সম্ভব পলায়ন করি। কারণ যদি আপনার ব্যবসায়ের অনেক সময় পরিবর্তন হয় এবং আপনাকে পদ্ধতির পরামিতিগুলি খেলতে হয় তবে সমস্ত কলার ফাংশন পরিবর্তন এবং বাস্তবায়ন করা সত্যিই শক্ত।

এর পরিবর্তে ইন্টারফেস (ডিপেন্ডেন্সি ইনজেকশন) ব্যবহার করুন। যদি আপনি মনে করেন যে এটি ব্যয়বহুল এবং আরও বেশি সময় নেয়, তবে ক্লাসগুলি ব্যবহার করুন এবং তাদের ম্যাপার এক্সটেনশন পদ্ধতিগুলি সরবরাহ করুন (বিকল্প 2)।

— Engineert
সূত্র