ডিজাইনের নিদর্শনগুলিতে কেন আমাদের এত ক্লাসের প্রয়োজন?

Question

আমি সিনিয়রদের মধ্যে জুনিয়র বিকাশকারী এবং তাদের চিন্তাভাবনা, যুক্তি বোঝার সাথে অনেক লড়াই করছি।

আমি ডোমেন-ড্রাইভড ডিজাইন (ডিডিডি) পড়ছি এবং বুঝতে পারি না কেন আমাদের এত ক্লাস তৈরি করা দরকার। আমরা যদি সফ্টওয়্যার ডিজাইনের সেই পদ্ধতিটি অনুসরণ করি তবে আমাদের 20-30 ক্লাস শেষ হয় যা বেশিরভাগ দুটি ফাইল এবং 3-4 ফাংশন দিয়ে প্রতিস্থাপন করা যায়। হ্যাঁ, এটি অগোছালো হতে পারে তবে এটি অনেক বেশি রক্ষণাবেক্ষণযোগ্য এবং পঠনযোগ্য।

যে কোনও সময় আমি দেখতে চাই যে কোন ধরণের কী EntityTransformationServiceImplকরে, আমাকে প্রচুর ক্লাস, ইন্টারফেস, তাদের ফাংশন কল, কনস্ট্রাক্টর, তাদের তৈরি এবং আরও অনেক কিছু অনুসরণ করতে হবে।

সাধারণ গণিত:

• 10 ক্লাস এক্স 10 বনাম ডামি কোডের 60 লাইন (ধরা যাক যে আমাদের কাছে এ জাতীয় লজিকগুলি সম্পূর্ণ আলাদা) = 600 টি লাইন অগোছালো কোড বনাম 100 ক্লাস + আরও কয়েকটি আরও মোড়ানো এবং পরিচালনা করতে; নির্ভরতা ইনজেকশন যোগ করতে ভুলবেন না।
• অগোছালো কোডের 600 লাইন পড়ছে = একদিন
• ১০০ ক্লাস = এক সপ্তাহ, এখনও ভুলে যান কোনটি কখন, কখন করে

সবাই বলছে এটি বজায় রাখা সহজ তবে কিসের জন্য? প্রতিবার আপনি নতুন কার্যকারিতা যুক্ত করার সময় আপনি কারখানা, সত্তা, পরিষেবা এবং মান সহ আরও পাঁচটি ক্লাস যুক্ত করেন। আমি মনে করি এই জাতীয় কোডটি অগোছালো কোডের চেয়ে অনেক ধীর গতিতে চলেছে moves

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

এক বছরে, আপনি প্রচুর অগোছালো কোড লিখেন এবং এমনকি এটি একাধিকবার নতুন করে লিখতে পারেন তবে ডিডিডি শৈলীর সাথে আপনার কাছে এখনও অগোছালো কোডের সাথে প্রতিযোগিতা করার মতো যথেষ্ট বৈশিষ্ট্য নেই।

দয়া করে ব্যাখ্যা করুন. আমাদের কেন এই ডিডিডি স্টাইল এবং প্রচুর নিদর্শনগুলির প্রয়োজন?

ইউপিডি ১ : আমি অনেক দুর্দান্ত উত্তর পেয়েছি, আপনি কি দয়া করে কোথাও মন্তব্য যুক্ত করতে পারেন বা পড়ার তালিকার লিঙ্কটি দিয়ে আপনার উত্তরটি সম্পাদনা করতে পারেন (কোনটি শুরু করবেন তা নিশ্চিত নন, ডিডিডি, ডিজাইন প্যাটার্নস, ইউএমএল, কোড সম্পূর্ণ, রিফ্যাক্টরিং, প্র্যাকমেটিক,। .. এতগুলি ভাল বই) অবশ্যই যথাক্রমে, যাতে আমি বুঝতে শুরু করতে পারি এবং আপনার কয়েকজনের মতো সিনিয়রও হতে পারি।

Comments

আমি মনে করি এখানে একটি ভাল প্রশ্ন আছে তবে এটি হাইপারবোলে এবং হতাশার আড়ালে রয়েছে। @ ব্যবহারকারী 1318496, আপনি আপনার প্রশ্নটি কিছুটা পুনরায় চাপিয়ে উপকৃত হতে পারেন।

— মেটাফাইট

পায়ের আঙ্গুলের পা বাড়ানোর ঝুঁকিতে, কারণ আপনার ভাষা সফল হয়। এটি তার চেয়ে বেশি হিসাবে গ্রহণ করবেন না: বিভিন্ন কারণে বিভিন্ন স্তন্যপায়ী ভাষা প্রায়শই সঠিক প্রযুক্তিগত পছন্দ, তবে এটি এটিকে দুধহীন করে তোলে না। আপনার আসল প্রশ্ন হিসাবে, নির্ভুলতার পাঠযোগ্যতার চেয়ে গুরুত্বপূর্ণ। বা এটিকে কিছুটা আলাদাভাবে বলা যায়: পঠনযোগ্যতার বিষয়টি ইনফার যেমন সঠিকতা সম্পর্কে যুক্তি সক্ষম করে। তাহলে কোনটি পরীক্ষা করা সহজ, আপনার 100 টি ক্লাস বা আপনার একক গড ক্লাস? আমি 100 টি সহজ ক্লাস বাজি দিচ্ছি।

— জারেড স্মিথ

"হ্যাঁ এটি অগোছালো হতে পারে, তবে এটি অনেক বেশি রক্ষণাবেক্ষণযোগ্য এবং পাঠযোগ্য।" যদি এটি অগোছালো হয় তবে এটি কীভাবে পাঠযোগ্য এবং বজায় রাখা যায়?

— বহুভুজ করুন

@ পলিগনোম: আমি ঠিক একই মন্তব্যটি টাইপ করতে চলেছি। জুনিয়র বিকাশকারীদের আরও একটি পছন্দ মন্তব্য বৈশিষ্ট্য "আমার মনে হচ্ছে এই ধরণের কোডটি তখন অনেক ধীর গতিযুক্ত অগোছালো কোডের দিকে চলে যায়" " দেওয়ালে দৌড়ানোর জন্য যদি আপনি অর্ধেক সময় ব্যয় করেন তবে আপনার পক্ষে যত দ্রুত সম্ভব চালানো ভাল নয়! আস্তে মসৃণ, মসৃণ দ্রুত।

— এরিক লিপার্ট

আপনি জাভা করছেন না, আপনি না। আপনার সমস্ত জাভা হলে সমস্ত কিছু বর্গের মতো লাগে।

— hobbs

Answer 1

এটি একটি অপ্টিমাইজেশান সমস্যা

একজন ভাল ইঞ্জিনিয়ার বুঝতে পারে যে একটি অপ্টিমাইজেশান সমস্যা লক্ষ্য ছাড়াই অর্থহীন। আপনি কেবল অনুকূল করতে পারবেন না, আপনাকে কোনও কিছুর জন্য অপ্টিমাইজ করতে হবে। উদাহরণস্বরূপ, আপনার সংকলক বিকল্পগুলির মধ্যে গতির জন্য অনুকূলকরণ এবং কোড আকারের জন্য অনুকূলকরণ অন্তর্ভুক্ত রয়েছে; এগুলি কখনও কখনও বিপরীত লক্ষ্য হয়।

আমি আমার স্ত্রীকে বলতে চাই যে আমার ডেস্ক অ্যাডগুলির জন্য অনুকূলিত। এটি কেবল একটি গাদা এবং স্টাফ যুক্ত করা খুব সহজ। আমি পুনরুদ্ধারের জন্য অনুকূলিত হলে আমার স্ত্রী এটিকে পছন্দ করবেন, অর্থাত্ আমার জিনিসগুলি কিছুটা সংগঠিত করেছেন যাতে আমি জিনিসগুলি খুঁজে পাই। এটি যোগ করা অবশ্যই শক্ত করে তোলে।

সফটওয়্যার একই ভাবে। আপনি অবশ্যই পণ্য তৈরির জন্য অনুকূল করতে পারেন - এটিকে সংগঠিত করার চিন্তা না করেই যত তাড়াতাড়ি সম্ভব এক টন একবর্ণ কোড তৈরি করুন । আপনি ইতিমধ্যে লক্ষ্য করেছেন, এটি খুব দ্রুত হতে পারে। বিকল্পটি রক্ষণাবেক্ষণের জন্য অনুকূলিতকরণ - সৃষ্টিটিকে আরও স্পর্শ করা আরও কঠিন, তবে পরিবর্তনগুলি সহজ বা কম ঝুঁকিপূর্ণ করা। এটি কাঠামোগত কোডের উদ্দেশ্য।

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

জটিলতা উপাদান থেকে আসে, উপাদান থেকে নয়

আমি আপনার বিশ্লেষণে লক্ষ্য করেছি যে আপনি পরিমাণের দিকে তাকিয়ে আছেন - কোডের পরিমাণ, শ্রেণীর সংখ্যা ইত্যাদি While এগুলি আকর্ষণীয় হলেও, আসল প্রভাবটি উপাদানগুলির মধ্যে সম্পর্কের ফলে আসে, যা সংহতভাবে বিস্ফোরিত হয়। উদাহরণস্বরূপ, যদি আপনার 10 টি ফাংশন থাকে এবং কোন ধারণা নির্ভর করে যা কোনটির উপর নির্ভর করে, আপনার 90 টি সম্ভাব্য সম্পর্ক রয়েছে (নির্ভরতা) আপনার সম্পর্কে চিন্তিত হতে হবে - দশটি ক্রিয়াকলাপের প্রত্যেকটি নয়টি অন্য 9 টি কার্যের উপর নির্ভর করে এবং 9 x 10 = 90. আপনার কোন ধারণা নেই যে কোন ফাংশনগুলি কোন ভেরিয়েবলগুলি পরিবর্তন করতে পারে বা কীভাবে ডেটাটি পাস হয়ে যায়, তাই কোডারদের কোনও নির্দিষ্ট সমস্যা সমাধান করার সময় চিন্তা করার জন্য প্রচুর পরিমাণে জিনিস থাকতে হবে। বিপরীতে, আপনার যদি 30 টি ক্লাস থাকে তবে সেগুলি চতুরতার সাথে সজ্জিত করা হয় তবে তাদের 29 টির মতো সম্পর্ক থাকতে পারে, উদাহরণস্বরূপ যদি তারা স্তরযুক্ত বা স্ট্যাকে সাজানো থাকে।

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

Comments

তবে আমি খেয়াল করব যে ক্লাস এবং ইন্ডিরিয়েশনের একটি অত্যধিক পরিমাণে NOR রক্ষণাবেক্ষণ বুঝতে সহায়তা করে না। এবং তেমনি সংশ্লেষিত নিয়ন্ত্রণ প্রবাহিত হয় না (ওরফে, কলব্যাক হেল)।

— ম্যাথিউ এম।

@ জোহানউইউ এই ব্যাখ্যাটি আমি যা পড়েছি তা বোঝার উপায় সবচেয়ে ভাল এবং সহজ।

— অ্যাড্রিয়ানো রেপিটি

ভাল লিখেছেন, তবে এটি কি অনুপস্থিত যে কেন "একবার তৈরি হয়েছিল তবে অনেক বার সংশোধিত" গুরুত্বপূর্ণ? (সমস্ত কোড যদি EntityTransformationServiceImplথাকে তবে আপনি এটি ঠিক করার আগে পুরো জিনিসটি কীভাবে কাজ করে তা শিখতে বাধ্য করা হয় - তবে উদাহরণস্বরূপ যদি কোনও ফর্ম্যাট এবং কোনও Formatterশ্রেণি হ্যান্ডল করে থাকে তবে আপনাকে কেবল সেই অংশটি কীভাবে কাজ করবে তা শিখতে হবে । প্লাস আপনার নিজের কোডটি 3 মাস পরে পড়া অপরিচিত ব্যক্তির কোড পড়ার মতো)) আমাদের বেশিরভাগ অবচেতনভাবে এটি সম্পর্কে ভাবা হয়েছে বলে মনে হয় তবে এটি অভিজ্ঞতার কারণে হতে পারে। এটি সম্পর্কে 100% নিশ্চিত নয়।

— আর স্মিটজ

আমি সম্মিলনের জন্য পুরো 10 × 10 = 100 এর জন্য যাব: এই ফাংশনগুলি অবশ্যই পুনরাবৃত্ত হতে পারে এবং বিশেষত দুর্বল কোডে, সম্ভবত খুব সম্ভবত তাই নয়।

— কেআরয়ান

"রক্ষণাবেক্ষণের জন্য বিকল্পটি হ'ল - নির্মাণকে আরও স্পর্শ করা আরও কঠিন, তবে পরিবর্তনগুলি সহজ বা কম ঝুঁকিপূর্ণ করা। এটি কাঠামোগত কোডের উদ্দেশ্য the" আরও ক্লাস = আরও রক্ষণাবেক্ষণের অন্তর্ভুক্ত ধারণাটি নিয়ে আমি বিষয়টি গ্রহণ করি। বিশেষত, অনেকগুলি ক্লাস জুড়ে বিক্ষিপ্ত যুক্তি প্রায়শই কোডের মধ্যে অতিমাত্রায় যুক্তিসঙ্গত ধারণাগুলি খুঁজে পাওয়া কঠিন করে তোলে (বিশেষত ধারণাগুলি খুব দৃশ্যের সাথে নিশ্চিত হওয়ার বিষয়ে খুব ইচ্ছাকৃত চোখ ছাড়া), যা রক্ষণাবেক্ষণকে ব্যাপকভাবে হ্রাস করে।

— jpmc26

Answer 2

ঠিক আছে, প্রথমত, পাঠযোগ্যতা এবং রক্ষণাবেক্ষণযোগ্যতা প্রায়শই দর্শকের চোখে থাকে।

আপনার কাছে যা পাঠযোগ্য তা আপনার প্রতিবেশীর কাছে নাও থাকতে পারে।

রক্ষণাবেক্ষণ প্রায়শই আবিষ্কারযোগ্যতার দিকে ফোটে (কোডবেসে আবিষ্কার করা কোনও আচরণ বা ধারণাটি কত সহজেই পাওয়া যায়) এবং আবিষ্কারযোগ্যতা অন্য বিষয়গত বিষয়।

DDD

ডিডিডি বিকাশকারীদের দলগুলিকে যেভাবে সহায়তা করে তার মধ্যে একটি হ'ল আপনার কোড ধারণা এবং আচরণগুলি সংগঠিত করার একটি নির্দিষ্ট (এখনও এখনও বিষয়গত) পরামর্শ দেওয়া। এই সম্মেলনটি জিনিসগুলি আবিষ্কার করা সহজ করে এবং তাই অ্যাপ্লিকেশন বজায় রাখা সহজ করে তোলে।

• ডোমেন ধারণাগুলি সত্তা এবং সমষ্টি হিসাবে এনকোড করা হয়
• ডোমেন আচরণ সত্ত্বা বা ডোমেন পরিষেবাগুলিতে থাকে
• সামঞ্জস্যতা সমষ্টিগত মূলগুলি দ্বারা নিশ্চিত করা হয়
• অধ্যবসায় উদ্বেগগুলি সংগ্রহস্থলগুলি পরিচালনা করে

এই ব্যবস্থা বজায় রাখা উদ্দেশ্যমূলকভাবে সহজ নয় । যাইহোক, যখন সবাই বুঝতে পারে যে তারা ডিডিডি প্রসঙ্গে কাজ করছে তখন এটি বজায় রাখা পরিমিতরূপে সহজ।

ক্লাস

শ্রেণিগুলি রক্ষণাবেক্ষণযোগ্যতা, পাঠযোগ্যতা, আবিষ্কারযোগ্যতা ইত্যাদিতে সহায়তা করে ... কারণ তারা একটি পরিচিত সম্মেলন ।

অবজেক্ট ওরিয়েন্টেড সেটিংসে, ক্লাসগুলি সাধারণত ঘনিষ্ঠভাবে সম্পর্কিত আচরণের গোষ্ঠীকরণের জন্য এবং রাষ্ট্রকে আবশ্যকভাবে সাবধানে নিয়ন্ত্রণ করা দরকার used

আমি জানি এটি খুব বিমূর্ত লাগে, তবে আপনি এটি সম্পর্কে এইভাবে ভাবতে পারেন:

ক্লাস সহ, আপনার প্রয়োজনীয় কোডগুলি কীভাবে কাজ করে তা আপনার জানা দরকার । আপনার কেবল ক্লাসটি কী জন্য দায়বদ্ধ তা জানতে হবে ।

শ্রেণিগুলি আপনাকে আপনার প্রয়োগ সম্পর্কে ভাল সংজ্ঞায়িত উপাদানগুলির মধ্যে মিথস্ক্রিয়তার ক্ষেত্রে যুক্তি দেয় ।

আপনার অ্যাপ্লিকেশনটি কীভাবে কাজ করে তা যুক্তিযুক্ত যখন এটি জ্ঞানীয় বোঝা হ্রাস করে। Of০০ টি লাইন কোড কী সম্পাদন করে তা মনে রাখার পরিবর্তে , আপনি কীভাবে 30 উপাদানগুলি ইন্টারেক্ট করে তা ভাবতে পারেন ।

এবং এই 30 টি উপাদানগুলি সম্ভবত আপনার অ্যাপ্লিকেশনটির 3 টি স্তর বিস্তৃত বিবেচনা করে আপনি সম্ভবত প্রত্যেককে একযোগে 10 টি উপাদান সম্পর্কে যুক্তিযুক্ত হতে হবে।

এটি বেশ পরিচালনাযোগ্য বলে মনে হচ্ছে।

সারাংশ

মূলত, আপনি সিনিয়র দেবগণ যা করছেন তা হ'ল:

তারা ক্লাস সম্পর্কে সহজেই যুক্তিযুক্ত অ্যাপ্লিকেশনটিকে ভেঙে ফেলছে ।

তারপরে তারা স্তরগুলি সম্পর্কে সহজেই যুক্তিযুক্ত হিসাবে এগুলি সংগঠিত করছেন ।

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

Comments

ছোট ক্লাস ছাড়াও রিফেক্টর প্রতিস্থাপন করা সহজ।

— যালোমন

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

— ভাইকিংস্টিভ

হ্যাঁ, ওভাররেঞ্জাইনিং খারাপ। তাই কুকুরছানা মারা হচ্ছে। এখানে কেউ কেউ পক্ষেও পরামর্শ দিচ্ছেন না। লজিক্যালিফ্যালাসিয়াস.টুলস

— স্প

এছাড়াও, সফ্টওয়্যার ইঞ্জিনিয়ারিং প্রসঙ্গে "কমনীয়তা" প্রায়শই একটি ওয়েসেল ওয়ার্ড হয়। en.wikipedia.org/wiki/Weasel_word

— MetaFight

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

— মেটাফাইট

Answer 3

দয়া করে আমাকে ব্যাখ্যা করুন, আমাদের কেন এই ডিডিডি স্টাইলের প্রচুর প্যাটার্ন দরকার?

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

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

কৌতুকপূর্ণভাবে, যদি আপনার ডোমেনে দুটি ভিন্ন ধারণা থাকে তবে তাদের মেমরির উপস্থাপনায় ভাগ করে নেওয়ার পরেও তারা মডেলটিতে পৃথক হওয়া উচিত ।

কার্যত, আপনি এমন একটি ডোমেন নির্দিষ্ট ভাষা তৈরি করছেন যা ব্যবসায়ের ভাষায় আপনার মডেলকে বর্ণনা করে, যেমন কোনও ডোমেন বিশেষজ্ঞ এটি দেখতে এবং ত্রুটিগুলি চিহ্নিত করতে সক্ষম হন spot

তদাতিরিক্ত, আপনি উদ্বেগ পৃথক করতে আরও কিছুটা মনোযোগ দিতে দেখেন; এবং প্রয়োগের বিশদ থেকে গ্রাহকদের কিছু সক্ষমতা অন্তরক করার ধারণা। ডিএল পার্নাস দেখুন । স্পষ্ট সীমানা আপনাকে পুরো সমাধানে প্রভাবগুলি ছড়িয়ে দেওয়া ছাড়াই বাস্তবায়ন পরিবর্তন বা প্রসারিত করার ক্ষমতা দেয়।

এখানে অনুপ্রেরণা: কোনও ব্যবসায়ের মূল দক্ষতার অংশ হিসাবে এমন একটি অ্যাপ্লিকেশনের জন্য (যার অর্থ এটি এমন একটি জায়গা যেখানে এটি একটি প্রতিযোগিতামূলক সুবিধা অর্জন করে), আপনি আরও ভাল পরিবর্তনের সাথে সহজেই এবং সস্তাভাবে একটি ডোমেন আচরণ প্রতিস্থাপন করতে সক্ষম হতে চাইবেন। বাস্তবে, আপনার কাছে প্রোগ্রামের কিছু অংশ রয়েছে যা আপনি দ্রুত বিকশিত করতে চান (সময়ের সাথে সাথে কীভাবে রাষ্ট্রের বিবর্তন ঘটে) এবং আপনি যে অংশগুলি ধীরে ধীরে পরিবর্তন করতে চান (রাষ্ট্র কীভাবে সংরক্ষণ করা হয়); বিমূর্ততার অতিরিক্ত স্তরগুলি অজান্তে অন্যের সাথে সংযুক্ত হওয়া এড়াতে সহায়তা করে।

ন্যায্যতায়: এর কয়েকটি হ'ল অবজেক্ট ওরিয়েন্টেড ব্রেন ড্যামেজ। মূলত ইভান্স দ্বারা বর্ণিত নিদর্শনগুলি 15+ বছর আগে তিনি অংশ নিয়েছিলেন এমন জাভা প্রকল্পগুলির উপর ভিত্তি করে; রাষ্ট্র এবং আচরণ দৃ that়ভাবে সেই স্টাইলে মিলিত হয়, যা এমন জটিলতা বাড়ে যা আপনি এড়াতে পছন্দ করতে পারেন; দেখতে উপলব্ধি এবং অ্যাকশন স্টুয়ার্ট Halloway, অথবা দ্বারা ইনলাইনিং কোড জন Carmack দ্বারা।

আপনি কোন ভাষায় কাজ করেন না কেন, কার্যকরী শৈলীতে প্রোগ্রামিং সুবিধা দেয়। যখনই এটি সুবিধাজনক তখন আপনার এটি করা উচিত এবং যখন সিদ্ধান্তটি সুবিধাজনক নয় তখন আপনার কঠোর চিন্তা করা উচিত। কারম্যাক, ২০১২

Comments

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

— সেন্টিনেল

জন কারম্যাক আইএমওর এক দুর্দান্ত উদাহরণ, যেহেতু তিনি খুব ভাল পারফরম্যান্স করছেন এমন সময় কোডটি লেখার জন্য সুপরিচিত যা পরিষ্কার এবং সহজে বোঝা যায়। এটি উন্নত প্রযুক্তির সাথে তার কোডটি ট্র্যাক করার সময় এটি বিশেষভাবে দৃশ্যমান - আরও ভাল সিপিইউ এবং মেমরির সাহায্যে আপনি "এটি সত্যিকারের সংশ্লেষিত হওয়া দরকার" থেকে "এটিকে সত্যিই পরিষ্কার / বিচ্ছিন্ন / হওয়া দরকার ... থেকে প্রচুর পরিমাণে ঠেলাঠেলি করতে পারেন ... "। আমি চিনি এমন সবচেয়ে বাস্তববাদী প্রোগ্রামারগুলির মধ্যে একটি :)

— লুয়ান

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

— jpmc26

Answer 4

অন্যান্য উত্তরগুলিতে অনেকগুলি ভাল পয়েন্ট রয়েছে তবে আমার মনে হয় তারা আপনার করা একটি গুরুত্বপূর্ণ ধারণাগত ভুলকে মিস করে বা জোর দেয় না:

আপনি সম্পূর্ণ প্রোগ্রামটি বোঝার চেষ্টাটির সাথে তুলনা করছেন।

এটি বেশিরভাগ প্রোগ্রাম সহ বাস্তবসম্মত কাজ নয়। এমনকি সাধারণ প্রোগ্রামগুলিতে এমন অনেকগুলি কোড থাকে যা কোনও নির্দিষ্ট সময়ে এগুলি সমস্ত পরিচালনা করা কেবল অসম্ভব। আপনার একমাত্র সুযোগ হ'ল কার্যের সাথে প্রাসঙ্গিক কোনও প্রোগ্রামের অংশটি খুঁজে পাওয়ার (একটি বাগ ঠিক করা, একটি নতুন বৈশিষ্ট্য বাস্তবায়ন করা) এবং সেটির সাথে কাজ করা।

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

এর সাথে একটি ছোট ফাংশন / পদ্ধতি / ক্লাসযুক্ত একটি কোড বেসের সাথে তুলনা করুন এবং প্যাকেজ / নেমস্পেসগুলিতে সংগঠিত হয়েছে যা প্রদত্ত যুক্তিটির কোনও টুকরো কোথায় পাবে / রাখবে তা স্পষ্ট করে তোলে। অনেক ক্ষেত্রে ডান হয়ে গেলে আপনি নিজের সমস্যা সমাধানের জন্য সঠিক জায়গায় ডানদিকে ঝাঁপিয়ে পড়তে পারেন, বা কমপক্ষে এমন একটি জায়গায় যেতে পারেন যেখানে আপনার ডিবাগারকে গুলি চালানো আপনাকে দু'পক্ষের মধ্যে সঠিক জায়গায় পৌঁছে দেবে।

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

এর অন্যান্য ক্রিয়াকলাপগুলিতে এর প্রভাব রয়েছে:

• ছোট ইউনিটগুলির সাথে টেস্টিং অনেক সহজ হয়ে যায়
• কম মার্জার দ্বন্দ্ব কারণ দুটি বিকাশকারী একই কোড টুকরা উপর কাজ করার সম্ভাবনা কম হয়।
• কম সদৃশ কারণ টুকরো পুনরায় ব্যবহার করা সহজ (এবং টুকরোটি প্রথম স্থানে খুঁজে পাওয়া)।

Answer 5

কারণ টেস্টিং কোড লেখার কোডের চেয়ে শক্ত

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

তবে, বিবেচনার জন্য আরও একটি দিক রয়েছে - পরীক্ষাটি কেবলমাত্র আপনার মূল কোড হিসাবে সূক্ষ্ম-দানাযুক্ত হতে পারে।

আপনি যদি একঘরে সমস্ত কিছু লিখেন তবে আপনি কার্যকরভাবে পরীক্ষা করতে পারেন "এই ইনপুটগুলি দেওয়া কি আউটপুটটি সঠিক?" এর অর্থ যে কোনও বাগ পাওয়া যায়, সেগুলি "কোডের সেই বিশালাকার স্তূপের কোথাও" এ স্কোপ করা হয়।

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

সমাধান: অনেকগুলি ছোট পরীক্ষা যা একটি নির্দিষ্ট, সম্ভাব্য ব্যর্থতার প্রতিটি নির্দিষ্ট করে।

এই ছোট পরীক্ষাগুলি (উদাহরণস্বরূপ ইউনিট টেস্টস), কোডবেসের একটি নির্দিষ্ট ক্ষেত্রটি পরীক্ষা করার এবং সীমিত সুযোগের মধ্যে ত্রুটিগুলি খুঁজে পেতে সহায়তা করার সুবিধা রয়েছে। এটি যখন পরীক্ষা ব্যর্থ হয় তখন কেবল ডিবাগিংকে গতি দেয় না, তবে এর অর্থ হ'ল যদি আপনার সমস্ত ছোট পরীক্ষা ব্যর্থ হয় - তবে আপনি আরও সহজেই আপনার বৃহত্তর পরীক্ষাগুলিতে ব্যর্থতাটি খুঁজে পেতে পারেন (যেমন যদি এটি কোনও নির্দিষ্ট পরীক্ষামূলক ক্রিয়ায় না থাকে তবে এটি অবশ্যই ইন্টারঅ্যাকশনটিতে থাকতে হবে) তাদের মধ্যে).

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

পার্শ্ব-নোটের মতো: এটি লোকেরা জিনিসগুলিকে "খুব বেশি দূরে" নেবে না তা বলার অপেক্ষা রাখে না। তবে কোডবেসগুলি ছোট / কম সংযুক্ত অংশগুলিতে পৃথক করার বৈধ কারণ রয়েছে - যদি সংবেদনশীলভাবে করা হয়।

Comments

যদিও আপনার উত্তরটি কেবল পরীক্ষার এবং পরীক্ষার জন্য সম্বোধন করে, এটিই একক অতি গুরুত্বপূর্ণ সমস্যা, যা অন্য কয়েকটি উত্তর পুরোপুরি উপেক্ষা করে +1 করে।

— স্কোমিসা

Answer 6

দয়া করে আমাকে ব্যাখ্যা করুন, আমাদের কেন এই ডিডিডি স্টাইলের প্রচুর প্যাটার্ন দরকার?

আমাদের মধ্যে বেশিরভাগ (বেশিরভাগ ...) তাদের প্রয়োজন নেই। তাত্ত্বিক এবং খুব উন্নত, অভিজ্ঞ প্রোগ্রামাররা প্রচুর গবেষণার ফলে এবং তাদের গভীর অভিজ্ঞতার ফলস্বরূপ তত্ত্বগুলি এবং পদ্ধতিগুলি সম্পর্কে বই লেখেন - এর অর্থ এই নয় যে তারা যা লিখেছেন তা তাদের প্রতিদিনের অনুশীলনে প্রতিটি প্রোগ্রামারের ক্ষেত্রে প্রযোজ্য।

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

আপনার প্রতিদিনের বিকাশে, আপনি যদি একাডেমিক না হন তবে আপনার কাজটি কার্যক্ষম, রক্ষণাবেক্ষণযোগ্য সমাধান খুঁজে বের করা। আপনি যদি কোনও বইয়ে পাওয়া ধারণাগুলি যদি সেই লক্ষ্য অর্জনে সহায়তা না করে তবে আপনার কাজটি ততক্ষণ সন্তোষজনক বলে মনে করা হয়, তবে এখনই এটি সম্পর্কে চিন্তা করবেন না।

এমন একটি সময় আসতে পারে যখন আপনি আবিষ্কার করবেন যে আপনি যা পড়েছিলেন তার কিছু ব্যবহার করতে পারেন তবে প্রথমে বেশিরভাগই "পেয়েছেন", না হতে পারে।

Comments

খাঁটি স্তরে এটি সঠিক হলেও এটি ডিডিডি এবং অন্যান্য প্যাটার্নগুলি কেবল তত্ত্বের মতো শোনাচ্ছে। তারা না। পাঠযোগ্য ও রক্ষণাবেক্ষণযোগ্য কোড অর্জনের জন্য এগুলি গুরুত্বপূর্ণ সরঞ্জাম।

— জেনস স্কাউডার

@ পেটকিরখাম ওপিএসের দ্বিধা হ'ল ডিজাইনের নিদর্শনগুলির অত্যধিক ব্যবহার । আপনার কি সত্যিই একটি দরকার AccountServiceFacadeInjectResolver(বাস্তব উদাহরণ আমি সবেমাত্র একটি সিস্টেমে কাজের সময় পেয়েছি) - উত্তর সম্ভবত সম্ভবত না।

— ভাইকিংস্টিভ

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

— আর স্মিটজ

@ আর.শ্মিটজ বলেছেন যে, শিক্ষানবিশ আমার কাছে প্রচুর ব্যক্তিগত প্রকল্প ব্যর্থ হয়েছিল কারণ তারা জিনিসগুলি সু-নকশিত, সংগঠিত, কাঠামোগত, ওওপি বানানোর জন্য খুব চেষ্টা করেছিলেন ... এগুলি সবই সরঞ্জাম tools এগুলি বুঝতে এবং সঠিকভাবে ব্যবহার করা দরকার এবং আপনি স্ক্রু করার ক্ষেত্রে হাতুড়ি দরিদ্র হওয়ার জন্য খুব কমই দোষ দিতে পারেন। আশ্চর্যজনকভাবে, এই সহজ জিনিসটি বুঝতে এটি অনেক অন্তর্দৃষ্টি এবং অভিজ্ঞতা গ্রহণ করেছে বলে মনে হচ্ছে :)

— লুয়ান

@ লুয়ান যদি আপনি ইতিমধ্যে ভাল-ডিজাইন, সংগঠিত, কাঠামোগত, ওওপি সম্পর্কে যত্নশীল হন তবে আমি খুব সহজেই সেই শিক্ষানবিশকে আপনাকে কল করতাম, তবে হ্যাঁ অতিরিক্ত ব্যবহার খারাপ। যাইহোক, ওপ কীভাবে আসলে এই সমস্যাগুলি সমাধান করে কোন সমস্যাগুলি বুঝতে পারে না সে সম্পর্কে প্রশ্নটি আরও। যদি আপনি কারণটি না জানেন তবে মনে হয় এর কোনও কারণ নেই - তবে বাস্তবে আপনি কেবল এটি এখনও জানেন না।

— আর স্মিটজ

Answer 7

আপনার প্রশ্নটি প্রচুর অনুমানের সাথে অনেকগুলি আচ্ছাদিত হওয়ায় আমি আপনার প্রশ্নের বিষয়টি একত্র করব:

ডিজাইনের নিদর্শনগুলিতে আমাদের এত ক্লাস কেন দরকার

আমরা করিনা. সাধারণত কোনও গ্রহণযোগ্য নিয়ম নেই যা বলে যে ডিজাইনের ধরণগুলিতে অবশ্যই অনেকগুলি শ্রেণি থাকতে হবে।

কোডটি কোথায় রাখবেন এবং কীভাবে আপনার কার্যগুলিকে কোডের বিভিন্ন ইউনিটে কাটা যায় সে সিদ্ধান্ত নেওয়ার জন্য দুটি মূল গাইড রয়েছে:

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

কেন এই দুটি গুরুত্বপূর্ণ হওয়া উচিত?

• সংহতি: একটি পদ্ধতি যা প্রচুর পরিমাণে কাজ করে (উদাহরণস্বরূপ, একটি পুরানো ধাঁচের সিজিআই স্ক্রিপ্ট যা জিইউআই, যুক্তি, ডিবি অ্যাক্সেস ইত্যাদি সবই কোডের দীর্ঘস্থায়ী জবাবদিহি করে) অনর্থক হয়ে যায়। লেখার সময়, আপনার চিন্তাভাবনার ট্রেনটি দীর্ঘ পদ্ধতিতে সরিয়ে দেওয়ার জন্য এটি লোভনীয়। এটি কাজ করে, উপস্থাপন করা সহজ এবং এ জাতীয়, এবং আপনি এটি দিয়ে কাজটি করতে পারেন। পরে সমস্যা দেখা দেয়: কয়েক মাস পরে, আপনি যা করতে ভুলে যেতে পারেন। শীর্ষে কোডের একটি লাইন নীচে একটি লাইন থেকে কয়েক পর্দা দূরে হতে পারে; সমস্ত বিবরণ ভুলে যাওয়া সহজ। পদ্ধতির যে কোনও জায়গায় যে কোনও পরিবর্তন জটিল জিনিসের আচরণের পরিমাণকে ভেঙে দিতে পারে। এটি পদ্ধতির অংশগুলি রিফ্যাক্টর বা পুনরায় ব্যবহার করা বেশ জটিল হবে। ইত্যাদি।
• সংযুক্তকরণ: যে কোনও সময় আপনি কোডের একটি ইউনিট পরিবর্তন করেন, আপনি সম্ভবত এটির উপর নির্ভরশীল অন্যান্য সমস্ত ইউনিটগুলি ভেঙে ফেলেন। জাভা এর মতো কঠোর ভাষায়, আপনি সংকলনের সময় ইঙ্গিত পেতে পারেন (অর্থাত্ প্যারামিটার সম্পর্কে, ব্যতিক্রম ঘোষিত হওয়া ইত্যাদি)। তবে অনেকগুলি পরিবর্তন (যেমন আচরণগত পরিবর্তনগুলি) ট্রিগার করছে না এবং অন্যান্য, আরও গতিময়, ভাষাগুলির এ জাতীয় কোনও সম্ভাবনা নেই। সংযুক্তি যত বেশি হবে, যে কোনও কিছু পরিবর্তন করতে ততই কঠোর হয় এবং আপনি হয়তো থামতে পারেন, যেখানে কোনও লক্ষ্য অর্জনের জন্য একটি সম্পূর্ণ পুনর্লিখনের প্রয়োজন।

এই দুটি দিক হ'ল যে কোনও প্রোগ্রামিং ভাষায় "কোথায় কী রাখবেন", এবং যে কোনও দৃষ্টান্ত (কেবল ওও নয়) এর যে কোনও নির্বাচনের বেস "ড্রাইভার"। প্রত্যেকে এগুলি সম্পর্কে স্পষ্টভাবে অবগত নয়, এবং কীভাবে এই প্রভাবিত সফ্টওয়্যারটি সম্পর্কে সত্যিকারের একটি অন্তর্নিহিত, স্বয়ংক্রিয় অনুভূতি পেতে সময় লাগে, বেশিরভাগ বছর সময় লাগে।

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

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

কিছু লোক কেবল সেভাবে কাজ করে না। তারা যে কোনও কিছুতে সাধারণত ব্যবহৃত হতে পারে তার জন্য ইন্টারফেস (বা আরও সাধারণভাবে বিমূর্ত বেস ক্লাস) তৈরি করে; এটি দ্রুত একটি শ্রেণিবদ্ধ বিস্ফোরণ বাড়ে।

আবার এর পক্ষে এবং বিপক্ষে যুক্তি রয়েছে এবং আমি বা আপনি যেটিকে পছন্দ করেন তা বিবেচ্য নয়। আপনি, সফ্টওয়্যার বিকাশকারী হিসাবে আপনার জীবনে, দীর্ঘ স্প্যাগেটি পদ্ধতি থেকে, আলোকিত, সর্বাধিক-পর্যাপ্ত শ্রেণীর নকশার মাধ্যমে, অবিশ্বাস্যভাবে ফুটিয়ে তোলা শ্রেণির স্কিমগুলি যা অনেক বেশি পরিমাণে ওভাররেইনারেড হয়ে থাকবে, সমস্ত চূড়ান্ত মুখোমুখি হবেন। আপনি আরও অভিজ্ঞ হওয়ার সাথে সাথে আপনি "আর্কিটেকচারাল" ভূমিকায় আরও বৃদ্ধি পাবেন এবং আপনি যে দিকনির্দেশনা চান তাতে এটি প্রভাবিত করতে শুরু করতে পারেন। আপনি নিজের জন্য একটি সোনার মাঝের সন্ধান পাবেন এবং আপনি এখনও দেখতে পাবেন যে আপনি যা কিছু করেন না কেন অনেকে আপনার সাথে একমত নন।

সুতরাং, খোলামেলা দৃষ্টি রাখা এখানে সবচেয়ে গুরুত্বপূর্ণ বিষয় এবং এটি আপনার কাছে আমার প্রাথমিক পরামর্শ হবে, কারণ আপনার বাকী প্রশ্নটি বিচার করে আপনি সমস্যাটি নিয়ে অনেক কষ্ট পেয়েছেন বলে মনে করছেন ...

Answer 8

অভিজ্ঞ কোডাররা শিখেছেন:

• কারণ এই ছোটখাটো প্রোগ্রাম এবং অনুমানগুলি বাড়তে শুরু করে, বিশেষত সফল। যে সাধারণ নিদর্শনগুলি একটি সাধারণ স্তরে কাজ করেছিল তা স্কেল করে না।
• কারণ প্রতিটি অ্যাড / চেঞ্জের জন্য বেশ কয়েকটি শিল্পকলা যুক্ত / পরিবর্তন করা ভারী মনে হতে পারে তবে আপনি কী যুক্ত করবেন তা জানেন এবং এটি করা সহজ। টাইপিংয়ের 3 মিনিট চতুর কোডিংয়ের 3 ঘন্টা প্রহার করে।
• ছোট্ট অনেকগুলি ক্লাস কেবল "অগোছালো" নয় কারণ আপনি বুঝতে পারেন না যে ওভারহেডটি আসলে একটি ভাল ধারণা
• ডোমেন জ্ঞান যুক্ত না করে, 'আমার কাছে সুস্পষ্ট' কোডটি প্রায়শই আমার দলের সঙ্গীদের ... এবং ভবিষ্যতে আমার কাছে রহস্যজনক।
• উপজাতীয় জ্ঞান প্রকল্পগুলির অবিশ্বাস্যরূপে কঠিন করে তুলতে পারে যা সহজেই এবং দ্রুত উত্পাদনশীল হওয়ার জন্য দলের সদস্যদের যোগ করতে পারে।
• নামকরণ হ'ল কম্পিউটিংয়ের দুটি কঠিন সমস্যার মধ্যে একটি এখনও সত্য এবং প্রচুর ক্লাস এবং পদ্ধতিগুলি নামকরণে প্রায়শই একটি তীব্র অনুশীলন যা অনেকের পক্ষে একটি দুর্দান্ত উপকার বলে মনে হয়।

Comments

তবে ওভারহেড কি প্রয়োজনীয়? আমি দেখতে পেলাম এমন অনেক ক্ষেত্রে ডিজাইনের নিদর্শনগুলি অতিরিক্ত ব্যবহৃত হয়েছে। অতিরিক্ত কমপ্লিটটির ফলাফল কোড বোঝা, রক্ষণাবেক্ষণ, পরীক্ষা এবং ডিবাগিংয়ে অসুবিধা বৃদ্ধি করে। আপনার যদি একটি সাধারণ পরিষেবা শ্রেণীর চারপাশে 12 টি ক্লাস এবং 4 টি মভেন মডিউল থাকে (একটি বাস্তব উদাহরণ আমি স্রেফ দেখেছি), এটি আপনার ভাবার চেয়ে দ্রুত পরিচালনাযোগ্য হয়ে ওঠে।

— ভাইকিংস্টিভ

@ লাইকিংস্টিভ আপনি ত্রুটিযুক্ত বাস্তবায়নের একক উদাহরণ উল্লেখ করে আশা করছেন যে এটি প্রমাণ করবে যে কাঠামোগত কোডটি সাধারণভাবে, একটি খারাপ ধারণা। এটি ঠিক ট্র্যাক করে না

— মেটাফাইট

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

— ক্লিয়ারার

@ ক্লেয়ার আমি নিশ্চিত যে এখানে সকলেই একমত যে কাঠামোগত কোডের অনুমানমূলক অপব্যবহার একটি খারাপ জিনিস। ওপি বলছে তারা জুনিয়র। সে কারণেই লোকেরা ধরে নিচ্ছে যে সে কাঠামোগত কোডের সুবিধাগুলি সম্পর্কে অপরিচিত এবং সেগুলি পুনরায় জানাচ্ছে।

— মেটাফাইট

Answer 9

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

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

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

Answer 10

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

একাধিক ক্লাস তাদের মূল কাজ হিসাবে চিহ্নিত করতে সহায়তা করে এবং যে কোনও ক্লাসকে যে কোনও সময় ডাকা যেতে পারে।

তবে আপনি যদি তাদের ক্লাসযোগ্য নাম থেকে অনেক ক্লাস এবং ফাংশন করেন তবে তাদের কল করা এবং পরিচালনা করা সহজ। একে ক্লিন কোড বলা হয়।

Comments

দুঃখিত, তবে আপনি কি বলছেন?

— হস্তান্তরকারী

@ ডিডুকিপেটর আসুন আমরা জাভাতে একটি উদাহরণ নিই যদি আমরা তাদের উত্তরাধিকারের জন্য jframes থ্রেড এবং ক্লাস ব্যবহার করি। শুধুমাত্র একটি শ্রেণি থেকে আমরা জাভা কিছু কাজ ডিজাইনের জন্য ব্যবহার করতে পারি না তাই আমাদের আরও ক্লাস করা দরকার

— সঞ্জীব চৌহান

এই উত্তরটি এমন ধারণা (গুলি) উপস্থাপন করতে হবে যা এটি পরিষ্কার ইংরেজিতে উপস্থাপনের জন্য পূর্বসূত্র। দেখে মনে হচ্ছে যে উত্তরের মূল ধারণাটি হ'ল ছোট ক্লাসগুলি, যার মধ্যে একটি সু-সংজ্ঞায়িত কার্যকারিতা রয়েছে, এটি একটি ভাল ধারণা, তবে ভয়ঙ্কর ব্যাকরণ এটি বুঝতে প্রায় অসম্ভব করে তোলে। এছাড়াও, নিজেই, এই দাবিটি যথেষ্ট নাও হতে পারে।

— টালোনেক্স