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

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

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

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

সহজ গণিত:

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

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

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

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

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

UPD 1: I received so many great answers, can you guys please add comment somewhere or edit your answer with the link for reading list (not sure from which to start, DDD, Design Patterns, UML, Code Complete, Refactoring, Pragmatic ,... so many good books), of course with sequence, so that I can also start understanding and become senior as some of you do.

198
@ user1318496 এই উপরের প্রশ্নের একটি সদৃশ। আপনি কি আসলেই জিজ্ঞাসা করছেন তা সম্পর্কে আপনি অবগত নন। আপনার প্রশ্নের মূলত OO বনাম কার্যকরী প্রোগ্রামিং বা নকশা নিদর্শন এবং প্রতিষ্ঠানের সাথে সবকিছু করার সাথে কিছুই করার নেই। আপনি আসলে কোনও উত্তর চান এমন প্রশ্নটি হল, "আলাদা আল্টিক ইউনিটগুলিতে পৃথক কোড কেন?"। এখন, যদিও অনেক ডেভেলপার মনে করতে পারে যে এটির উত্তর স্ব-স্পষ্ট, আমি বিশ্বাস করি এটি একটি খুব বৈধ প্রশ্ন। অনেকগুলি বিকাশকারী একে অন্যের সাথে একত্রিত হওয়ার সাথে সাথেই এটি শুরু করছে।
যোগ লেখক Vassilis, উৎস
"হ্যাঁ এটা নোংরা হতে পারে, কিন্তু এটি অনেক বেশি রক্ষণযোগ্য এবং পাঠযোগ্য।" যদি এটি নোংরা, এটা কিভাবে পঠনযোগ্য এবং রক্ষণযোগ্য হতে পারে?
যোগ লেখক Bigballs, উৎস
@ জারেড: "পরীক্ষা করা কি সহজ?": সর্বদা হিসাবে, এটি কোন ধরণের পরীক্ষা উপর নির্ভর করে। যদি আপনার 100 টি তুচ্ছ ক্লাস থাকে এবং সমস্ত সিস্টেমের আচরণ একসঙ্গে কীভাবে যুক্ত হয় তা হলে, সাধারণভাবে ফলাফলের পদ্ধতি বলার পক্ষে কোন একীকরণ এবং QA পরীক্ষাগুলি নির্বাক একীকরণের চেয়ে সহজতর নয়। আপনার 100+ ইউনিট পরীক্ষা আছে যা জোর দিয়ে বলছে, "আপনি আপনার ডিজাইন পরিবর্তন করেননি", কিন্তু তাই কি? OP অপ্রচলিত এবং/অথবা কোডটি সূক্ষ্ম হতে পারে, কিন্তু যদি অনুপাতটি একই সমস্যা সমাধান করার জন্য নিখুঁত কোডের 6 টি রেখা 1 শ্রেণির হয় তবে তার উপর ভিত্তি করে বিবেচনা করা হয় যে এটি অতি-প্রকৌশলী :-)
যোগ লেখক TraumaPony, উৎস
এবং "একই সমস্যা সমাধান করুন" দ্বারা অবশ্যই আমি সম্পূর্ণরূপে সমাধান করতে চাই, যা অন্য কোনও ক্ষেত্র যা অপারেটিং সিস্টেমগুলি এই কোড বেসের লেখকদের দেখতে ব্যর্থ হয়েছে। কোডের 600 টি লাইন যা বেশিরভাগ সময় সাজানোর কাজটি এমন 100 ফ্রেমওয়ার্কের মতোই নয় যা বাহ্যিকভাবে কার্যকর তাত্ত্বিক প্রমাণগুলি প্রমাণ করে যা আপনাকে আসলেই কোডটি কমানোর অনুমতি দেয়!
যোগ লেখক TraumaPony, উৎস
@EricLippert: যদি 100 শ্রেণী সহ কোডটি সফটওয়্যারটির ব্যবহারকারীকে সহজেই ব্যাখ্যা করে তবে কোডটি অসাধারণ কোড নয়, তাহলে হ্যাঁ এটি একটি দুর্দান্ত উপমা। আমি মনে করি প্রাচীর এবং গ্ল্যাডেড উইন্ডোতে একটি গর্তের মধ্যে পার্থক্যটি শ্রেণিবদ্ধ করা খুবই সহজ, "নিঃস্ব সমাধানটি আসলে সমাধান নয় কারণ এটি আমাদের প্রকৃত ব্যবহারকারীর প্রয়োজনীয়তাগুলি সন্তুষ্ট করে না"। সুতরাং, যদি হ্যাকড একসাথে কোড এক দিনের মধ্যে কাজ করে তবে আপনার প্রকৃত ব্যবহারকারী মুখোমুখি পরিষেবাদি চালানোর সফটওয়্যার স্ট্যাকের মধ্যে একত্রিত করা যাবে না, তাহলে এটি আরও ক্লাস লেখার জন্য স্ল্যাম-ডক যুক্তি।
যোগ লেখক TraumaPony, উৎস
@ জেরেড: আপনি ইতিমধ্যে উপরে বাজি ধরছেন যে 100 শ্রেণী একত্রে তুলনায় পরীক্ষা করা সহজ। আমি শুধুমাত্র যে দাবি সাড়া ছিল। কোড পরিবর্তন স্বাচ্ছন্দ্য monoliths বিরুদ্ধে একটি সম্পূর্ণ ভিন্ন যুক্তি :-)
যোগ লেখক TraumaPony, উৎস
এটি লক্ষ্য করা উচিত যে ওওপি একটি সর্বজনীন সেরা হাতিয়ার নয়, তাই আরও ক্লাস যোগ করে সমস্যাটির প্রতিটি (অংশ) সমাধান করা, বিশেষ করে উত্তরাধিকারের সাথে, এটি দরিদ্র, অপ্রয়োজনীয় জটিল ডিজাইনগুলির দিকে পরিচালিত করে। সমস্যা একটি ভাল নকশা সঙ্গে আসছে সময় এবং অভিজ্ঞ বিকাশকারী লাগে, এবং উভয় ব্যয়বহুল। ঠিক এখন কাজ করলে এটি একটি নোংরা ডিজাইনের সাথে ব্যবসাটি ঠিক থাকে।
যোগ লেখক Rorick, উৎস
আপনি না করছেন, যদি না আপনি জাভা করছেন। যখন আপনার সব জাভা হয়, সবকিছু একটি বর্গ মত দেখায়।
যোগ লেখক Krzysztof Klimonda, উৎস
সহজভাবে রাখুন, এটি আরো কঠিন এবং মার্জিত কোড লিখতে আর সময় লাগে, তাই লোকেরা অসংলগ্ন কিন্তু অত্যন্ত গঠনযুক্ত কোডের জন্য স্থায়ী হয়।
যোগ লেখক Mr Rogers, উৎস
যোগ লেখক innaM, উৎস
@ পলিগনোম: আমি ঠিক একই মন্তব্য লিখতে যাচ্ছি। জুনিয়র ডেভেলপারদের আরেকটি পছন্দসই মন্তব্যের বৈশিষ্ট্যাবলী "আমি মনে করি এই ধরণের কোডটি খুব ধীরগতির পরে নোংরা কোডটি চালায়।" যদি আপনি অর্ধেক আপনার দেয়ালের মধ্যে চলমান সময় ব্যয় হিসাবে আপনি দ্রুত হিসাবে চালানোর জন্য ভাল না! ধীর মসৃণ, মসৃণ দ্রুত।
যোগ লেখক CodeCharming, উৎস
এই প্রশ্নটি জিজ্ঞেস করার মতো "কেন উইন্ডোটি তৈরির জন্য আমাদের অনেকগুলি অংশ দরকার? এই সব শব্দটি স্যাশ এবং স্যাশ কর্ড এবং ডাবল হ্যাং এবং ট্রিপল গ্লেজড ক্যাসমেন্ট এবং এটি খুব বিভ্রান্তিকর। যদি আমি প্রাচীরের মাধ্যমে দেখতে চাই একটি ড্রিল পান, প্রাচীর একটি গর্ত ড্রিল, সম্পন্ন। উইন্ডো নির্মাতা এত সহজ তাই আমি এটা করতে পারেন কেন এত জটিল করতে চান? "
যোগ লেখক CodeCharming, উৎস
আমি ব্যবহারকারী 1318496 হিসাবে সাধারণ ক্লাস সম্পর্কে একই ভাবে অনুভব করতে শুরু করছি। সম্ভবত অন্য কিছু চেয়ে একটি ব্যক্তিগত পছন্দ জিনিস এর আরো।
যোগ লেখক Graham, উৎস
@ গ্রাহাম ভাষা বৈশিষ্ট্য একটি নির্দিষ্ট ডিগ্রী ব্যক্তিগত পছন্দ, কিন্তু এই প্রশ্নের অর্থহীন। কার্যকরী কোড ঠিক যেমন সহজ পরিবর্তন বনাম সহজ তৈরি জন্য লেখা যেতে পারে।
যোগ লেখক R. Schmitz, উৎস
@ 9000 আমি মনে করি আপনি যা বলছেন সেটি সিওপ - "ক্লাস ভিত্তিক প্রোগ্রামিং" বলা হবে? যদি আপনি বস্তুগুলি সম্পর্কে হুট করে ক্লাস যোগ করেন তবে আপনি OOP করছেন না ...
যোগ লেখক R. Schmitz, উৎস
আমরা সত্যিই তাদের প্রয়োজন হয় না ...
যোগ লেখক Vector, উৎস
আমি কি কেবলমাত্র মনে করি যে একটি সাধারণ সমস্যা সমাধান করার জন্য EntityTransformationServiceImpl গুলি সহ ২0-30 টি ক্লাস ব্যবহার করা হয়? আমি অনুমান করছি আপনি জাভাটির কথা উল্লেখ করছেন, যার সংস্কৃতিটি কোড ভিত্তিক নকশা না হওয়া পর্যন্ত নকশা নিদর্শনগুলিতে নকশার নকশার নিক্ষেপ করা হয় ...
যোগ লেখক Solomonoff's Secret, উৎস
আমি এখানে একটি ভাল প্রশ্ন আছে কিন্তু এটি hyperbole এবং হতাশা পিছনে লুকিয়ে আছে। @ ব্যবহারকারী 1318496, আপনি আপনার প্রশ্নটি একটু রিফ্রেশ করার থেকে উপকৃত হতে পারেন।
যোগ লেখক Warpspace, উৎস
@ জেমস্কফ সম্ভবত আপনি এটি একটি ধর্মীয় রূপান্তর হিসাবে দেখতে। আমি এটি ধর্ম -> ধর্ম টাইপের ফাংশন হিসাবে দেখি।
যোগ লেখক Chad, উৎস
এই উত্তর এবং মন্তব্যের কিছু একে অপরের অতীত কথা বলা হয়। আমি মনে করি এটি দুটি স্বতন্ত্র প্রশ্ন সম্পর্কে চিন্তা করতে পারে, যেমন। "সাধারণ কোডটি সাধারণভাবে " (যাচাইযোগ্যতা, ডিকোপুলিং ইত্যাদি) ব্যবহার করে ডিডিডি/ডিজাইন-নিদর্শন/ইত্যাদি কেন ব্যবহার করবেন এবং কেন " এই বিশেষ কোডबेस ব্যবহার করছেন?" আমি আশা চেয়ে অনেক বেশি ক্লাস? " (ওভার-ইঞ্জিনিয়ারিং, ভাষা-নির্দিষ্ট কাজকর্ম (উদাঃ কোন lambdas), পুরানো শৈলী (উদাঃ জাভা এখন lambdas), cargo-culting, প্রযুক্তি ঋণ, ইত্যাদি)
যোগ লেখক Warbo, উৎস
আমি কোড লাইন এবং তাদের understantability কাছাকাছি আপনার গণিত খুঁজে পেতে বেশ হাস্যকর। আমি আপনার ব্যবহার করা সংখ্যা পিছনে আপনার যুক্তি বিস্তারিত লেখার দেখতে চাই।
যোগ লেখক Euphoric, উৎস
"600 নোংরা কোড লাইন = এক দিন পড়া"। এটা ভুল ... একটি ক্লাস পড়তে আমার সময় লাগে, দ্রুতগতিতে, সব শাখা এবং শাখা ভুল অনুমান ইত্যাদি ... 600 লাইনে আমি আমার সান্ত্বনা অঞ্চলের প্রান্তে আছি। 1000 এ এটি সাধারণত আমাকে এক মাসের জন্য পুরোপুরি বুঝতে বোঝায় ....
যোগ লেখক ArTs, উৎস
F22 Raptor ফিক্সারগুলির একটি আইকেইএ গুদাম গ্রহণ করে এবং একটি বিমানের আকারের ছাঁচে ঢুকিয়ে এটি তৈরি করে নি।
যোগ লেখক ArTs, উৎস
আপনার ডোমেইন বিদ্যমান যে ক্লাস ধারণা আছে? যদি না হয়, তারা কেন বিদ্যমান? তারা যদি থাকে, তাহলে তাদের ব্যবসায়িক মূল্য আছে, তাই না? আপনি যদি ডোমেন ধারণা প্রতিনিধিত্ব করে যে 20-30 ক্লাস বনাম 600 নোংরা কোড লিখুন যদি ভবিষ্যতে নমনীয়তা আপনি আলগা না?
যোগ লেখক Rob Crawford, উৎস
OOP প্রায়শই একটি বিরোধী-প্যাটার্ন, এবং বিশুদ্ধ OOP প্রায় সবসময় একটি বিরোধী-প্যাটার্ন। OOP আপনার কোডের সকল প্রকারের জায়গায় রক্তপাত করতে থাকে, বিশেষ করে পরীক্ষার যোগ্যতা। ডিজাইন নিদর্শনগুলি হ্যাকার (OOP) ব্যবহার করে আপনি এই সমস্ত নখগুলি চালানোর জন্য OOP এর অতিরিক্ত ব্যবহার সম্পর্কে বিক্ষিপ্ত হয়ে যান। যদি আপনার নাম সরবরাহকারী , entity , অথবা প্রসেসর সহ একটি বর্গ আছে, আপনি সম্ভবত OOP ব্যবহার করছেন, তবে আপনি অবশ্যই প্রচুর লোক খুঁজে পেতে পারেন যারা পেরেক OOP কিভাবে figured আছে।
যোগ লেখক Rich Remer, উৎস
উল্লেখ্য, লেখার কোডের এই বিশেষ পদ্ধতিটি নিদর্শনগুলির সাথে সমস্যা নয় তবে লোকেদের কোডটি লিখছে। আপনি অনেকগুলি নিদর্শন এবং সম্ভবত 40 বা 50 টি ক্লাসের সাথে সমৃদ্ধ সফটওয়্যার লিখতে পারেন; সহজ। কিন্তু যদি আপনি overengineer জিনিস ... ভাল, তাহলে আপনি 20 ক্লাসের সাথে এমন কিছু করার জন্য শেষ করেছেন যা 3 ক্লাসের সাথে বা 4 থেকে 5 পদ্ধতিগত ফাংশনগুলির সাথে সম্পন্ন হতে পারে। গুরুত্বপূর্ণ দক্ষতা স্বীকার করা হয় যখন কোন শ্রেণীটি খুব বড় একটি বিরতি পেতে চলেছে যাতে এটি একটি দেবতা শ্রেণী না হয়।
যোগ লেখক marstato, উৎস
ওপিএস প্রতিরক্ষা ক্ষেত্রে, সে যা উল্লেখ করছে তার একটি ভাল উদাহরণ হচ্ছে সর্বত্র 3/4 কম মূল্যের অবস্থার সরল সুইচ প্রতিস্থাপন করা। আমি এই ঘটতে দেখেছি এবং ফলাফল প্রকৃতপক্ষে কোড শত শত পরিবর্তে একটি শত ক্লাস হতে পারে। রক্ষণাবেক্ষণ খুব আপস করা হয়।
যোগ লেখক Sentinel, উৎস
বিশ্বাস করা যায় না যে কেউই একক দায়িত্বের নীতির উল্লেখ করেছে (যা আপনি এটি অনুসরণ করেন, বহু শ্রেণী উত্পাদনতে নেতৃত্ব দেয়) এবং সাধারণ নীতিগুলি সাধারণভাবে।
যোগ লেখক sizzlecookie, উৎস
@ ব্যবহারকারী 1318496 - আপনার চিন্তা করার দরকার নেই, আপনার মতামত ভাগ করে নেওয়ার অনেক সফল কোম্পানি রয়েছে। এবং তারা সব সময় নিয়োগ দিচ্ছে, কারণ আরো ডেভেলপারদের কোড দ্রুত বজায় রাখার জন্য প্রয়োজন বোধ করা হয় .. :)
যোগ লেখক Fabio, উৎস
কয়েক দশক আগে আমি একটি দোকানে কাজ করেছি যেখানে আমরা ডস 2.0 থেকে ডোএস 3.0 তে আপগ্রেড করেছি। প্রথম সংস্করণে, এটির মধ্যে কেবলমাত্র একটি একক ডিরেক্টরি ছিল। পরে, subfolders চালু করা হয়েছে। আমার বস জিজ্ঞেস করলো, "আমাদের এই সব সাবফোল্ডারদের কেন দরকার? কেন আমি শুধু এক ফোল্ডারে সবকিছু রাখি না যাতে আমি জানতে পারি কোথায় এটি খুঁজে পাব?" ভাল সময়। :)
যোগ লেখক David Lang, উৎস
নকশা নকশার শুধুমাত্র রক্ষণাবেক্ষণ সম্পর্কে নয়, কিন্তু এটি পুনর্ব্যবহারযোগ্যতা সম্পর্কেও।
যোগ লেখক Randy E, উৎস
পায়ের আঙ্গুল উপর ঝুলন্ত ঝুঁকি, কারণ আপনার ভাষা sucks। এটির চেয়ে আরও বেশি কিছু না নেবেন: একটি ক্ষুধার্ত ভাষা প্রায়শই বিভিন্ন কারনে সঠিক প্রযুক্তিগত পছন্দ হয় তবে এটি অচল করে না। আপনার প্রকৃত প্রশ্ন হিসাবে, সঠিকতা পাঠযোগ্যতা তুলনায় আরো গুরুত্বপূর্ণ। অথবা যে সামান্য ভিন্নভাবে রাখা: পঠনযোগ্যতা যেমন সঠিকতা সম্পর্কে যুক্তি সক্ষম হিসাবে insofar বিষয়। তাই পরীক্ষা করা কি সহজ, আপনার 100 ক্লাস বা আপনার একক দেবতা ক্লাস? আমি 100 টি সহজ ক্লাস বন্টন করছি।
যোগ লেখক Sujan, উৎস
@SteveJessop হ্যাঁ, সিস্টেম পরীক্ষা করা উভয় ক্ষেত্রে সমান জটিল। সম্ভবত আরও একাধিক ক্লাস ক্ষেত্রে তাই। পার্থক্যটি হল: একীকরণের সাথে যেখানে পরিবর্তন করতে সহজলভ্য হওয়া সহজতর হতে পারে, এটি তৈরি করতে পারে এমন স্টাফগুলিকে সংশোধন করার সম্ভাব্য অনির্দিষ্ট সময়। স্প্লিট-আপ কোডবেসে কোডের সঠিক অংশটি সনাক্ত করা কঠিন তবে একটি পরিচিত পরিমাণ, এবং পরিবর্তনটি ক্ষুদ্র। আমি বরং ডাইস রোল চেয়ে আত্মবিশ্বাসী হতে চাই, কিন্তু YMMV এবং এক আকার সব মাপসই করা হয় না। 10k লাইনের থেকে কম কিছু করার জন্য, আমি একীকরণকে অগ্রাধিকার দিতে পারি। হতে পারে.
যোগ লেখক Sujan, উৎস
@ থিওডোরাস চাতজিগিয়ানকনিস: এটি কেবল একটি ধর্মীয় রূপান্তর। সমস্যা একটি সফ্টওয়্যার উন্নয়ন পদ্ধতির অচল পূজা। আপনি শুধু দেবতা পরিবর্তন করুন, কিন্তু ধর্মানুষ্ঠান অচেনা সম্মতি রাখুন।
যোগ লেখক Ruks, উৎস
@ রব ক্রাউফোর্ড: আবার "... 600 টি লিংক কোড ২0-30 ক্লাস বনাম ...", এখানে আপনার দুটি সম্পর্কিত সম্পর্ক রয়েছে। স্পষ্ট, ভাল মন্তব্য কোডের 600 টি লাইন লিখতে এটি পুরোপুরি সম্ভব, ঠিক যেমন ২0-30 টি নোংরা ক্লাসে রূপান্তর করা সম্ভব।
যোগ লেখক Ruks, উৎস

10 উত্তর

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

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

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

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

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

জটিলতা সম্পর্ক থেকে আসে, উপাদান না

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

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

323
যোগ
@ jpmc26 অ-তুচ্ছ OOP প্রোগ্রামের একটি উদাহরণ (বলতে হবে> 10k লোকে) যা কম সংখ্যক ক্লাস ব্যবহার করে এবং এটি বজায় রাখা এবং পড়তে সহজ? এছাড়াও আমি কোড পড়ার জটিলতা জটিলতার সাথে একমত হতে হবে। আইডিই তে কোডটি লোড না করেই এটি RestoreRunner.RunAsync থেকে RestoreCommand এবং এভাবে অনুসরণ করা খুব সহজ মনে হয়। সমস্যাটি মনে হয় যে আপনি মিস করেছেন যে NuGets একটি সহজ তালিকা নয় কিন্তু প্যাকেজ রেফারেন্স এমন একটি গাছ যা আপনার মানসিক মডেলের মধ্যে একটি রেঞ্চ ছুঁড়ে ফেলে।
যোগ লেখক Kyle Hodgson, উৎস
@ হোলজার সোয়া যখন মজিলা ফায়ারফক্সে পুরনো ফায়ারফক্সে নতুন বৈশিষ্ট্য যুক্ত করতে বন্ধ করে দেয় তখন তাদের ব্রাউজারটি পুরোপুরি লেখার জন্য? তারা না। অবশ্যই আপনি কোডের অংশগুলি প্রতিস্থাপন করতে পারেন এবং একটি প্রাকৃতিক বিবর্তন আছে তবে একটি সম্পূর্ণ পুনঃলিখন বিষ (এটি যে অন্য কোম্পানি যা IE6 এবং 8 এর মধ্যে এমএস ছিল। .. এটি নেটস্কেপের তুলনায় তাদের জন্য আরও ভাল কাজ করে না)
যোগ লেখক Kyle Hodgson, উৎস
@ হোলজার আপনি দাবি করেন যে আজকে "কেবলমাত্র ব্রাউজারগুলিই স্ক্র্যাচ থেকে পুনঃলিখন করা হয়েছে অথবা এমনকি দীর্ঘদিনও বিদ্যমান নেই"। এটি patently মিথ্যা। আমি সন্দেহ করি যে কোনও জনপ্রিয় পণ্য যা স্ক্র্যাচ থেকে পুনঃলিখন করা হয়েছিল এবং এটি আগের মতোই সফল ছিল (যেহেতু আপনি উল্লিখিত উদাহরণটিকে সত্য বলে মনে হয় না, আমি সন্দেহ করছি যে আপনি একটি ভাল জানেন)। কেবলমাত্র ব্রাউজার বিক্রেতারাই একই রকম কাজ করেছেন, যেহেতু নেটস্কেপটি আই 6 এর পরে মাইক্রোসফ্ট ছিল। এবং তারা 90% সংখ্যাগরিষ্ঠ থেকে একটি ছোটখাট প্লেয়ারে গিয়েছিল এবং যেটি গ্রহের সর্বাধিক জনপ্রিয় অপারেটিং সিস্টেমের সাথে ব্রাউজারটি বান্ডিল করার সত্ত্বেও ... সফলতা অর্জন করেছিল।
যোগ লেখক Kyle Hodgson, উৎস
স্ক্র্যাচ এবং দ্বিতীয় সিস্টেম সিন্ড্রোম থেকে পুনর্বিবেচনা একটি পণ্য হত্যা করার নিশ্চিত উপায়, যার কারনে এখনও কেউ এটি করছে না। নতুন বৈশিষ্ট্য প্রয়োগ করার সময় আপনি বিদ্যমান কোডটি উন্নত করছেন। অথবা আপনি প্রয়োজন ভিত্তিতে (সুরক্ষা বা কর্মক্ষমতা সাধারণত, খুব কমই রক্ষণাবেক্ষণ) উপর ভিত্তি করে আবেদনটির ছোট অংশগুলি পুনর্লিখন করার সিদ্ধান্ত নিতে পারেন। কিন্তু স্ক্র্যাচ থেকে একটি পুনর্লিখন? জোয়েল প্রবন্ধটি এতটা খারাপ ধারণা কেন এমন অনেকগুলি কারণ দেয়।
যোগ লেখক Kyle Hodgson, উৎস
তবে, আমি মনে রাখবেন যে ক্লাস এবং অভিমুখে একটি অত্যধিকতা NOR রক্ষণাবেক্ষণ বুঝতে সাহায্য করে না। এবং না সমতল নিয়ন্ত্রণ প্রবাহ (উর, কলব্যাক জাহান্নাম)।
যোগ লেখক Owen, উৎস
"বিকল্পটি রক্ষণাবেক্ষণের জন্য অপ্টিমাইজ করা - সৃষ্টিকে আরও স্পর্শ করা কঠিন, তবে সংশোধনগুলি সহজ বা কম ঝুঁকিপূর্ণ করে তোলে। এটি গঠনযুক্ত কোডের উদ্দেশ্য।" আমি অন্তর্নিহিত ধারণার সাথে সমস্যা নিয়ে আরো বেশি ক্লাস/আরো দক্ষতা বজায় রাখি। বিশেষ করে, অনেক ক্লাস জুড়ে বিক্ষোভের যুক্তি প্রায়ই কোডের উচ্চতর লজিক্যাল ধারণাগুলি খুঁজে বের করা কঠিন করে তোলে (বিশেষত ধারণাগুলি খুব দৃঢ়ভাবে নিশ্চিত করার জন্য খুব ইচ্ছাকৃতভাবে নজর ছাড়া), যা প্রচুরভাবে রক্ষণাবেক্ষণকে হ্রাস করে।
যোগ লেখক jmibanez, উৎস
আমার এই উদাহরণটি সম্প্রতি NuGet এর পুনঃস্থাপন কমান্ড । পুনরুদ্ধারের তিনটি প্রাথমিক ধাপ রয়েছে: প্যাকেজগুলির তালিকায় পড়ে, ডাউনলোড করুন এবং তারপরে ডিস্কের উপর সেগুলি বের করুন। যদিও প্রতিটি ধাপে অবশ্যই জটিলতা রয়েছে, তবে কোডগুলি বাস্তবায়িত করার ক্ষেত্রে এটি অদক্ষভাবে কঠিন, বস্তুগতভাবে অপেক্ষাকৃত বৃহৎ সংখ্যক বস্তুর কারণে এবং কিছু অংশে এই ধারণাগুলি প্রকাশ করে না এমন কারণে নামকরণ এবং প্রতিষ্ঠানের মধ্যে অগ্রাধিকার হয়েছে।
যোগ লেখক jmibanez, উৎস
@ ভু আমি সমস্যা খুঁজে বের করতে সমস্যা ছিল, কোন বস্তুটি আদেশ শুরু করেছিল; যে সমস্ত কমান্ড লাইন প্যারিসিং OO পদ্ধতির সঙ্গে obfuscated হয়। একবার আপনি এটির RestoreRunner খুঁজে বের করলে আপনি তার "অনুরোধগুলি" কীভাবে তৈরি হয় তার মাধ্যমে ট্রেস করার চেষ্টা করেন, যা আপনাকে প্রায় 4 টি পদ্ধতির মাধ্যমে কল করে যা সরবরাহকারী বস্তুর কাছে কল করে শেষ হয়, যদি আমি পড়ি এটি ঠিক. একটি গাছ খোঁজা বিস্ময়কর নয়, তবে এটি কেবল অনেকগুলি স্তরের অন্তর্ভুক্ত রয়েছে। আমি চতুর না। আমি এমন কোড পছন্দ করি যা সাবধানতার সাথে এটির উদ্দেশ্যটি প্রকাশ করার জন্য তৈরি করা হয় এবং বস্তুর কেন্দ্রিক পদ্ধতিতে দরিদ্র বিমূর্ততাগুলি বাড়িয়ে দেয়।
যোগ লেখক jmibanez, উৎস
@JohnWu NuGet মডুলার হচ্ছে বেশ কঠিন ব্যর্থ। এর পাশের লাইব্রেরিগুলি (যেমন NuGet.Frameworks ) সম্পূর্ণ অননুমোদিত (আমি তাদের বিল্ডের জন্য উৎস খুঁজে পাচ্ছি না।), কমান্ড লাইন সরঞ্জামটি VS প্ল্যাগ-ইনের কার্যকারিতা অনেক হারিয়েছে এবং কোডটি দেখতে, কেবলমাত্র অনেকগুলি বস্তুর গঠন করার প্রয়োজন এক টুকরা কাজ করার অর্থ আপনাকে সম্পূর্ণ কোড বেসের এটির যে কোনও ব্যবহারের জন্য বিস্তৃত বোঝার দরকার আছে। এটি ইতিমধ্যে কার্যকরভাবে একীকরণ, তাই আমি আপনার যুক্তি কিনতে না।
যোগ লেখক jmibanez, উৎস
@JohnWu ব্যতীত যে বিস্তৃত নিদর্শনগুলির দিকে দেখুন। DI ধর্মীয়ভাবে গ্রহণ করা হয়। আমি জানি না ডি ডি প্রপোস্টেন্ট বলছেন, "ডিআইটি এমন সমস্যা যা এখানে সমাধান করার মতোই ভাল," তারা বলে, "আপনাকে OO কোড লিখতে হবে এবং এর অর্থ হল আপনার DI থাকা উচিত। এবং ওহ, বিটিউ, আপনাকে সোলোড নীতি অনুসরণ করা উচিত । " কার্যত কোন এক এই ধারণা আসলে সমাধান করা অনুমিত হয় কি বিষয়ে আলোচনা। তারা শুধু অনুমিত যে নিয়ম সব সময় প্রয়োগ করা হয়।
যোগ লেখক jmibanez, উৎস
@ আর। স্যাচমেজ সত্যিই ভাল প্রোগ্রামারদের প্রথম নিয়ম নিয়ম মনে হয় না। তারা সমস্যা সমাধানের শর্তাবলী মনে। এমনকি আরো গুরুত্বপূর্ণ বিষয় হল, ভাল প্রোগ্রামাররা যখন চিন্তিত হন যে অন্য প্রোগ্রামাররা ইতিমধ্যে সেই মানসিকতা নিয়ে চিন্তা করছেন না এবং নিয়ম মেনে চলার পরিবর্তে তাদের দিকে ধাক্কা দেয়।
যোগ লেখক jmibanez, উৎস
@ আর। শচীমেজ আমি সত্যিই ভাল প্রোগ্রামারদের চিন্তা ভাবনা বিপর্যস্ত করছি বলছি। তারা মনে করেন না, "আপনার পাঠযোগ্যতার জন্য আপনার কোডটি অপ্টিমাইজ করা উচিত।" তারা মনে করে, "সময় বা অন্যান্য ডেভেলপারদের দ্বারা পরিবর্তনগুলি করার জন্য কোড বুঝতে সক্ষম হওয়ার সমস্যাটির সমাধান করতে আমাদের প্রয়োজন।" প্রথম সমস্যাটি ব্যাখ্যা না করেই সমাধান করে। দ্বিতীয়টি সমস্যাটি বলে এবং এটি বিভিন্ন সমাধানগুলির জন্য খোলা থাকে এবং এটি এমন একটি লক্ষ্য যেখানে এটি সফল হয় বা না (যদিও এটি এখনও আধ্যাত্মিক হয়) এটি অনেক বেশি স্পষ্ট।
যোগ লেখক jmibanez, উৎস
আমি সমন্বয়কারীর জন্য পুরো 10 × 10 = 100 এর জন্য যাব: সেগুলি কার্যকরী হতে পারে এবং বিশেষ করে দরিদ্র কোডগুলিতে, নিরপেক্ষভাবে তাই নয়।
যোগ লেখক LessIsMore, উৎস
ভাল লেখা আছে, কিন্তু কেন এটা হয়তো অনুপস্থিত কেন "একবার তৈরি করা হয়েছে তবে অনেকগুলি সংশোধন করা হয়েছে" গুরুত্বপূর্ণ? (যদি সমস্ত কোড EntityTransformationServiceImpl থাকে তবে আপনি এটি ঠিক করতে পারার আগে পুরো জিনিসটি কীভাবে কাজ করে শিখতে বাধ্য হয় - কিন্তু উদাহরণস্বরূপ, যদি বিন্যাসে কিছু ভুল হয় এবং ফরম্যাট ক্লাস পরিচালনা করে, আপনাকে শুধুমাত্র কীভাবে এটি কাজ করে শিখতে হবে। প্লাসটি ~ 3 মাস পরে আপনার নিজের কোড পড়ার মতো একটি অপরিচিতের কোড পড়ার মতো।) আমাদের অবচেতনভাবে এই চিন্তা, কিন্তু যে অভিজ্ঞতা হতে পারে। না 100% এই সম্পর্কে নিশ্চিত।
যোগ লেখক R. Schmitz, উৎস
@ হোলগার নং, কারণ নতুন কোড যোগ করার সময় পূর্ববর্তী কোডটি আপনার লেখার মান হিসাবে গুরুত্বপূর্ণ নয়। যদি সফ্টওয়্যার কোডটিকে যুক্ত করার জন্য এটি অত্যন্ত ব্যয়বহুল করে তোলে তবে এটি কেবল নোংরা কোড। আপনি একটি পুরোপুরি মডুলার প্রকল্প থাকতে পারে, কিন্তু কিছু দ্রুত এবং সহজ কোড যোগ করুন। আপনি এক ঈশ্বর শ্রেণিতে একটি সম্পূর্ণ প্রোগ্রামও থাকতে পারেন তবে আপনার অতিরিক্ত পরবর্তীতে কীভাবে আরও কার্যকর করতে হবে তা নিয়ে কিছু চিন্তা করুন। আপনি যে কোম্পানিগুলির কথা বলছেন সে বিষয়ে আমি কেবল এক শুনেছি এবং এটি নেটস্কেপ ছিল।
যোগ লেখক R. Schmitz, উৎস
@ হোলজার যদি কোনও সংস্থা এমন একটি নতুন পণ্য তৈরি করে যা কোনও কোড বেসটি পুনর্বিবেচনা না করে তবে এটিই প্রথম স্থানে তৈরি করা । অন্যথায় আপনি যুক্তি দিচ্ছেন যে আজকের অটোক্যাড এবং 3DSMax ইত্যাদি 1968 ইউনিসেফ এবং "কল অফ ডিউটি" এর "পুনর্লিখন": আধুনিক ওয়ারফেয়ার 3 শুধুমাত্র DOOM এর একটি পুনঃলিখন। এছাড়াও আমি বলছি না যে এটি ঘটবে না, কেবলমাত্র সেই ক্ষেত্রে এটি যদি না হয় তবে এটি আরও ভাল হয়ে যায়।
যোগ লেখক R. Schmitz, উৎস
@ হোলগার আমি যা বললাম তার ব্যাখ্যা এবং কোনও পুনর্লিখন কি তা ভুল। কর্তব্যের ডাকটি নয় DOOM এর পুনঃলিখন। এটি একটি সম্পূর্ণ ভিন্ন বিকাশকারী দ্বারা একটি সম্পূর্ণ ভিন্ন পণ্য। অবশ্যই, আপনি বলতে পারেন কোডের প্রত্যেকটি অংশই শুধুমাত্র কোডের প্রথম অংশটির পুনঃলিখন, কিন্তু শব্দটি কেবল কোনও কার্যকর অর্থ হারিয়ে ফেলে এবং সম্ভবত আপনার এখানে একটি প্রশ্ন পোস্ট করুন তারপর।
যোগ লেখক R. Schmitz, উৎস
@ হোলগার লুক, ২004 সালে ফায়ারফক্স প্রকাশ করা হয়েছে, যা 14 বছর; 2007 এ অ্যান্ড্রয়েড, যে 11 বছর। আইটি তে, এটি পুরানো নয়, এটিই প্রাচীন । আপনার তত্ত্বের মতে, ফায়ারফক্সটি "পুরানো, প্যাচযুক্ত" (একই সময়ে), 2006 দ্বারা অযৌক্তিক জগাখিচুড়ি বা ২010 সালের কাছাকাছি অ্যানড্রয়েড হওয়া উচিত। এটি কেবল রক্ষণাবেক্ষণযোগ্য কোডের কার্যকারিতা অস্বীকার করে কারণ এটি এখন আরও ভালো প্রায় প্রতিটি দিক - নিরাপত্তা, ব্যবহারযোগ্যতা, বৈশিষ্ট্য সেট, আপনি এটি নাম। আপনি শুধু maintainable কোড বিরুদ্ধে একটি ব্যক্তিগত এজেন্ডা আছে মনে হচ্ছে।
যোগ লেখক R. Schmitz, উৎস
@ jpmc26 কারণ ভাল প্রোগ্রামাররা জানেন যে সমস্ত "নিয়ম" প্রয়োগগতভাবে প্রয়োগ করা উচিত; সমস্ত নিয়ম স্বয়ংক্রিয়ভাবে "শেষ পর্যন্ত আপনার কাছে সত্যিই একটি ভাল কারণ ছাড়া" পেতে পারে । যদি আপনি এমন ব্যক্তিদের সাথে কাজ করেন যা প্রগমেটিকের পরিবর্তে চেতনাগত, তবে এটি কোন নিয়মটির জন্য খারাপ হয়ে যাবে।
যোগ লেখক R. Schmitz, উৎস
@ হোলজার রাং আবার, আপনার প্রাথমিক বিবৃতি ছিল " সফ্টওয়্যারটি এমনভাবে ডিজাইন করা হয়েছে যা অত্যন্ত ব্যয়বহুল তৈরি করে, তাই আমাদের এটি রাখা এবং বজায় রাখা উচিত যতক্ষণ না আমরা পুরোপুরি পুরনো এই প্যাডেড জগতে মারা যাব। "আপনি যে প্রবন্ধটি লিঙ্ক করেছেন সেটি আপনাকে আরও অন্তর্দৃষ্টি দিতে পারে যদি আপনি আগ্রহী হন তবে পুনর্লিখনগুলি কেন খারাপ। আপনার প্রাথমিক বিবৃতি ফায়ারফক্স এবং অ্যান্ড্রয়েড দ্বারা ভুল প্রমাণিত হয়েছে। এর পরে সবকিছুই শুধু একটি আলোচনার বিষয় ছিল, যা মন্তব্যের জন্য নয়, তাই আসুন এখন এটিকে এখানেই বন্ধ করুন।
যোগ লেখক R. Schmitz, উৎস
@ হোলজার আপনি লিখেছেন [A] গুরুত্বপূর্ণ হতে পারে কারণ [B] কারণ [C] । যে আপনার "হয়তো" প্রয়োগ করা হয়। আপনার তত্ত্ব ছিল [বি] কারণ [সি]। দুটি বড় উদাহরণ যেখানে এটি প্রয়োগ করা হয় তা দ্রুত প্রমাণ করে না [B] কারণ করে না [সি]। যদি আপনার বিন্দু অন্য কিছু ছিল, তবে আমি তা খণ্ডন করিনি এবং শুধুমাত্র আপনার প্রাঙ্গনের একটি ভুল ছিল দেখিয়েছি।
যোগ লেখক R. Schmitz, উৎস
@ jpmc26 আমি উদ্ধৃতি চিহ্নগুলিতে "নিয়ম" রাখি কারণ তারা নির্দেশিকা । একটি নিয়ম "আপনি উচিত" সঙ্গে শুরু করতে পারবেন না। যদি কেউ এমনকি " পঠনযোগ্যতার জন্য আপনার কোডটি অপ্টিমাইজ করে" বা " আপনাকে টিমের কোড কনভেনশনগুলি অনুসরণ করে " অনুসরণ করতে হবে এমন একটি মৌলিক নির্দেশিকা অনুসরণ করে না, "যদি আপনার কাছে কোনও সত্যিকারের ভাল কারণ না থাকে তবে)", তারপরে তারা " বাস্তব প্রোগ্রামার "এর চেয়ে" প্রকৃত প্রোগ্রামার "
যোগ লেখক R. Schmitz, উৎস
@ জেএমপিসি 26 যথেষ্ট পরিমাণে পরিস্কার, কিন্তু 5 টি প্রশ্ন জিজ্ঞাসা করার পরে কেন আপনাকে বলা হয়েছে "আপনাকে অবশ্যই টিমের কোড কনভেনশন অনুসরণ করতে হবে" আপনার ক্যারিয়ারের জন্য ভাল নয়। কখনও কখনও এটা ব্যাখ্যা সবসময় যোগ খুব স্পষ্ট।
যোগ লেখক R. Schmitz, উৎস
@ জেএমপিসি 26 "আমি ধারণা দিয়ে আরও বেশি ক্লাস/আরো দক্ষতা বজায় রাখি।" অবশ্যই, "আরো" এর অপারেড কি উপর নির্ভর করে। এই ক্ষেত্রে, এটি "50 কে LOC লিংক কোড।" তাই আমি নিশ্চিত নই, আমি OP এর পোস্টের নির্দিষ্ট প্রসঙ্গে সম্মত।
যোগ লেখক John Wu, উৎস
নুগে সম্ভবত একটি দুর্দান্ত উদাহরণ নয়, কারন এটির মডুলারটি আর্কিটেক্টের ওভারেনথাসিউসিয়াসের চেয়ে বহিরাগত প্রয়োজনীয়তাগুলি দ্বারা আরো বেশি চালিত হতে পারে - এটি একটি সম্পূর্ণ ভিজ্যুয়াল স্টুডিও এক্সটেনশনের ভিতরে পাওয়ারশেল কমান্ডলেট হিসাবে চালানো এক্সটেনসিবল ফ্রেমওয়ার্কগুলি পরিচালনা করার জন্য একটি বিস্তৃত ফ্রেমওয়ার্ক। এখন আমি এটি সম্পর্কে চিন্তা করি, যদি ঐ সমস্ত বিষয়গুলি একত্রে লিখিত হয়, নুগেট এমনকি অস্তিত্বও ছিল না ..
যোগ লেখক John Wu, উৎস
@ হোলজার আমার পোস্টে আমি দুটি সম্ভাব্য অপ্টিমাইজেশান লক্ষ্য নিয়ে আলোচনা করেছি। অবশ্যই আপনি অন্যান্য লক্ষ্যের জন্য অপ্টিমাইজ করতে পারেন - উদাঃ "পুনর্লিখনের সংখ্যা কমিয়ে আনতে" (যা রক্ষণাবেক্ষণের জন্য অপ্টিমাইজেশনের মতো খুব অনুরূপ) বা "পুনঃলিখনের সহজতাকে সর্বাধিক" করতে, যা পণ্য সমৃদ্ধির জন্য অপ্টিমাইজেশান হিসাবে একই রকম (একই সাথে পূর্ববর্তী সামঞ্জস্যের জন্য অতিরিক্ত প্রয়োজনীয়তা এবং বৈশিষ্ট্য সমতা)। আমি একটি লক্ষ্য নির্ধারন করি না, আমি কেবলমাত্র ভেক্টরগুলিকে হাইলাইট করতে চাই, সাবধানে নকশার জন্য যুক্তিটি ব্যাখ্যা করার উপায় হিসাবে।
যোগ লেখক John Wu, উৎস
@ টাউ "সব উপায়ে নকশা নকশার এবং ধর্মীয়ভাবে সব খরচ খুঁজে।" যে একটি নকশা সিদ্ধান্ত (আউটপুট) মত একটি নকশা লক্ষ্য (ইনপুট) মত শোনাচ্ছে। যখন আপনি আপনার পছন্দসই আউটপুটগুলিকে অপ্টিমাইজেশান ইনপুট-এ লোড-লোড করছেন, তখন প্রক্রিয়াটি অনেক মান যোগ করে না (এটি একচেটিয়াতার পরীক্ষাটি ব্যর্থ হয়), a.k.a. আপনি এটি ভুল করছেন। আপনার আর্কিটেক্টের মতো শব্দটি কেবল একটি "পোষা NFR ," যা সবসময় খারাপ।
যোগ লেখক John Wu, উৎস
@JohnWu এই ব্যাখ্যাটি আমি যেটা পড়েছি তা বোঝার জন্য সর্বোত্তম এবং সহজ উপায়।
যোগ লেখক Les H, উৎস
যখন আমি প্রথম কোডিং শিখতে শুরু করি, তখন আমি এক ক্লাসের মধ্যে একটি প্রোগ্রাম লিখেছিলাম, এটি ভাল কাজ করে তবে সহজ পরিবর্তন আনতে যেখানে 4 বা 5 টি বাগ সংশোধন করা হয়েছিল, এটি ঠিক করতে কয়েক দিন সময় লাগবে। আমি নকশা গবেষণা শুরু এবং প্রায় 10 ক্লাসে সবকিছু ভেঙ্গে এবং আমার রক্ষণাবেক্ষণ সমস্যা অদৃশ্য। আমি এই রেফেক্টর পরে চালু 0 বাগ সঙ্গে অনেক পরিবর্তন করেছেন। আমি মনে করি এই পাঠটি কীভাবে বোঝার চেষ্টা করা যায় যে এটি কেন মূল্যবান?
যোগ লেখক reggaeguitar, উৎস
@Voo যে "ক্লাসের সর্বনিম্ন সংখ্যা" সংজ্ঞা উপর নির্ভর করে। আমাদের হাজার হাজার ক্লাসের একটি অ্যাপ্লিকেশন আছে, তবে আমি জানি যে আমরা সাধারণত সাধারণভাবে ব্যবহৃত ফ্রেমওয়ার্কগুলি এবং "সর্বোত্তম অনুশীলনগুলি" ব্যবহার করেছিলাম যে সংখ্যাটি ছিল ২0 গুণ।
যোগ লেখক Holger, উৎস
@ আর। স্যামিমেজ এটি একটি আকর্ষণীয় বিষয়। "একবার তৈরি করা হয়েছে তবে অনেকগুলি সংশোধন করা হয়েছে" গুরুত্বপূর্ণ হতে পারে কারণ সফ্টওয়্যারটি এমনভাবে ডিজাইন করা হয়েছে যা অত্যন্ত ব্যয়বহুল তৈরি করে, তাই আমাদের এটি রাখা এবং বজায় রাখতে হবে যতক্ষন না আমরা সম্পূর্ণরূপে এই পয়েন্টটি পৌঁছাই পুরাতন, প্যাচযুক্ত ময়লা মারা হয়েছে। সবাই এই প্যাটার্ন অনুসরণ করে না। কোম্পানিগুলি এমন একটি সফ্টওয়্যার প্রকাশেরও ছিল যা সবসময় নতুন সংস্করণটির শুরু থেকেই শুরু হয়েছিল, যা স্ক্র্যাচ থেকে লিখিত ছিল, পূর্ববর্তী সংস্করণটি তৈরি করে শিখে নেওয়া সব পাঠ্য এবং সেইসাথে নতুন আগত প্রযুক্তিগুলি অন্তর্ভুক্ত করেছিল।
যোগ লেখক Holger, উৎস
@ আর। শচিটেজ আপনি কি জানেন যে সেই সময়ের সমস্ত ব্রাউজার আসল মোজাইক ভিত্তিক ছিল, যেমন। ইন্টারনেট এক্সপ্লোরার, যে এখনও বিদ্যমান একটি নাম? আপনি কি মনে করেন, আজকের ব্রাউজারগুলির কতগুলি এখনও এটির উপর ভিত্তি করে রয়েছে? আজ, কেবলমাত্র এমন ব্রাউজার রয়েছে যা তখন থেকেই স্ক্র্যাচ (একাধিকবার) থেকে পুনঃলিখন করা হয়েছে অথবা এমনকি এগুলিও বিদ্যমান নেই। একটি তত্ত্ব বিশ্বের মধ্যে, যে প্রথম ব্রাউজার একটি মডুলার, এক্সটেনসিবল, ভবিষ্যতে প্রমাণ উপায়, ভবিষ্যতে যে কোন পরিবর্তন আনা জন্য প্রস্তুত হচ্ছে লেখা হতে পারে। আসলে, না। প্রয়োজনীয়তা এবং প্রযুক্তি খুব পরিবর্তন।
যোগ লেখক Holger, উৎস
@ আর এসচিম্জ তাই আপনি বলছেন যে এটি আরও ভালো হবে if "কল অফ ডিউটি: আধুনিক ওয়ারফেয়ার 3" ডুমের সোর্স কোডের উপর ভিত্তি করে ছিল এবং এটি ডুমের দুর্বল সফটওয়্যার ডিজাইনের একটি চিহ্ন যা এটি 'টি? অথবা আপনি আসলে আমার পয়েন্ট নিশ্চিত করছেন যে পুরানো সফটওয়্যারটি নতুন করে প্রতিস্থাপিত হবে, কেননা পুরানোটি পুরানো আপডেট করা একটি বিভ্রম?
যোগ লেখক Holger, উৎস
@ ভু আমি দেখি না যেখানে আমি দাবি করেছি যে সমস্ত সফটওয়্যার ডেভেলপাররা এটি করে। সম্ভবত আপনি ঠিকই আছেন এবং নেটস্কেপের জন্য পুনরায় ডিজাইন-থেকে-স্ক্র্যাচ প্রতিস্থাপন হিসাবে এটির জীবন শুরু করার পরে ফায়ারফক্সটি স্ক্র্যাচ থেকে পুনরায় ডিজাইন করা হয়নি। সম্ভবত এটি ফায়ারফক্স ডিজাইন করা কত ভাল একটি সাইন। অথবা সম্ভবত, আপনি একটি flamewar শুরু করতে চলেছেন, ফায়ারফক্স এর মান সত্যিই বিতর্কিত অনুভূত হয়। কীট যে খুলতে পারেন না।
যোগ লেখক Holger, উৎস
@ আর। স্যামিমিট মনে হচ্ছে আপনি সম্পূর্ণরূপে পয়েন্টটি অনুপস্থিত। নতুন সফ্টওয়্যার পুরানো এক বা সম্পূর্ণরূপে নতুন পণ্য একটি "পুনর্লিখন" কিনা তা কোন ব্যাপার না। বিন্দুটি হল, এটি নতুন সফ্টওয়্যার যা এটি পুরোনোটির রক্ষণাবেক্ষণ কতটা সহজ নয় তা কোন ব্যাপার না। আপনি এখন এটি পেতে পারি? ওল্ড সফ্টওয়্যার মারা হবে। পুরানো সফ্টওয়্যার নতুন এক দ্বারা প্রতিস্থাপিত হবে। এটি একটি অনিবার্য ঘটনা। আপনি শুধুমাত্র নতুন যে আপনার বা আপনার প্রতিযোগীদের যে শুধুমাত্র প্রভাবিত করতে পারেন। তবে আপনি রক্ষণাবেক্ষণের জন্য আপনার সফ্টওয়্যারটি অপ্টিমাইজ করতে, নতুন সফ্টওয়্যারের ব্যয়বহুল বিকাশ তৈরি করতে এবং সর্বদা নতুন একটি লিখতে এড়ানো চেষ্টা করতে পারেন ...
যোগ লেখক Holger, উৎস
@ ভু ঠিক আছে, মাইক্রোসফ্ট একমাত্র তাদের ব্রাউজারটি স্ক্র্যাচ থেকে পুনঃলিখন করেছে। এখন, যেকোন ব্রাউজারটি ছাড়াও যেটি মাইক্রোসফট থেকে (যে নেটস্কেপ 4 বা তার আগে) বিদ্যমান ছিল তা আজও বিদ্যমান রয়েছে (প্রধান পুনঃলিখন ছাড়াই, অন্য কথায়, এখনও মোজাইক কোডের উপর ভিত্তি করে)। আচ্ছা, প্রকৃতপক্ষে নেটস্কেপও একটি পুনর্লিখন করেছে, কিন্তু এটি মোজিলা ফাউন্ডেশনে আউটসোর্স করেছে, যা ফায়ারফক্সের উন্নয়নের দিকে পরিচালিত করেছিল। সুতরাং পুনর্লিখনের ফলে পণ্যটি "খুন" হয় কারণ এটি নতুনটিকে জন্ম দিয়েছে। আপনি কি মনে করেন যে পুরানো কোডের উপর ভিত্তি করে একটি নেটস্কেপ ব্রাউজার আজও বিদ্যমান থাকতে পারে? মজিলা একমত নন।
যোগ লেখক Holger, উৎস
@JohnWu অপ্টিমাইজেশান বর্ণনা করার আপনার উপায় বিভিন্ন লক্ষ্য একটি ফাংশন খুব ভাল, আমি যে বিরোধিতা করছি না। এটা সত্যিই একটি ভাল উত্তর।
যোগ লেখক Holger, উৎস
ফায়ারফক্সের প্রধান পৃষ্ঠপোষক একবার Chrome নামক নিজের ব্রাউজারটি লেখার সিদ্ধান্ত নিয়েছিলেন তবে ফায়ারফক্সের উপর ভিত্তি করে নয়, আপনি ঠিক আছেন। ফায়ারফক্স প্রাচীন। তবে, আপনি কি প্রমাণ করতে চান? আমার প্রাথমিক বিবৃতিটি ছিল যে, আজকের কোনও ব্রাউজার মোজাইক ভিত্তিক নয়, কারণ সমস্ত বিদ্যমান ব্রাউজারগুলি যেহেতু সম্পূর্ণভাবে পুনর্লিখন করা হয়েছে অথবা এর থেকে অনেক কম। মনে হচ্ছে যে মোজাইক 1993 থেকে, ফায়ারক্সফক্স হল এর তুলনায় অনেক কম। সুতরাং আপনি আমাকে ভুল প্রমাণিত হয়নি। এর পাশাপাশি, আমি রক্ষণযোগ্য কোডের বিরুদ্ধে নই, কখনও বলেনি। বরং, আমি কোডের বিরুদ্ধে যা শুধুমাত্র ক্রমবর্ধমান জানি।
যোগ লেখক Holger, উৎস
অনুবাদ মূল উক্তি @ আর। স্যামিমেজ আপনি এই শব্দটিকে প্রসঙ্গের বাইরে ঠেলে দিচ্ছেন। বাক্যটি "" একবার তৈরি হয়েছিল তবে অনেকগুলি 'বারবার' গুরুত্বপূর্ণ হতে পারে, কারণ সফ্টওয়্যার এমন ভাবে ডিজাইন করা হয়েছে যা অত্যন্ত ব্যয়বহুল তৈরি করে ... "। এটি এমন একটি প্যাটার্ন সম্পর্কে একটি ধারণা যা হতে পারে সফটওয়্যার প্রকল্পগুলির কিছু পরিমাণে প্রয়োগ করতে পারে। চেরি বাছাই করা সফ্টওয়্যার সম্পর্কে দুইটি উদাহরণ আইআইআরসি সম্পর্কে আলোচনা শুরু করার মাধ্যমে আপনি ইতিমধ্যে বিন্দুটি মিস করেছেন, যা অনেকদিন ধরে বজায় রাখা হয়েছে, যা সমস্ত বিলিয়ন সফটওয়্যারকে করেছে মরেছে তা উপেক্ষা করে। সেই ফটকাবাচক বিবৃতিটি কেবল দুটি উদাহরণের দ্বারা "প্রমাণিত ভুল" নয়।
যোগ লেখক Holger, উৎস
মহান উত্তর কিন্তু ..: বিকল্পটি রক্ষণাবেক্ষণের জন্য অপ্টিমাইজ করা এর মানে হল এটি কেবলমাত্র একমাত্র এবং একজন OP সম্পর্কে অভিযোগ করছে। সমস্ত উপায়ে নকশা নিদর্শন খুঁজে পেতে এবং যথাযথভাবে ব্যয়বহুলভাবে > অপ্টিমাইজেশান আছে। শব্দটি হল স্মার্ট এবং অনেকগুলি ক্লাস তৈরি করে এটি একটি প্রদত্ত নয়। DI একটি দুর্দান্ত/ভয়ানক উদাহরণ, যেখানে একজন জ্ঞানী ব্যক্তি লিখেছেন, আপনি 100 $ buzzwords এর জন্য 50c ধারণাটি পান।
যোগ লেখক pong, উৎস
একটি ভাল উত্তর, কিন্তু একটি ঝলকানি বিলোপ সঙ্গে: এটি অত্যন্ত সম্ভবত "600 লাইন নোংরা কোড" সঠিকভাবে পরীক্ষা করা যাবে না, এবং শুধুমাত্র OP অপেক্ষাকৃত পদ্ধতির জন্য একটি চুক্তি বিরতির যে।
যোগ লেখক Nath, উৎস

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

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

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

DDD

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

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

এই ব্যবস্থাটি objectively বজায় রাখা সহজ নয়। এটি, তবে, পরিমাপযোগ্য সহজে বজায় রাখা যখন প্রত্যেকে বুঝতে পারে যে তারা একটি DDD প্রেক্ষাপটে কাজ করছে।

ক্লাস

ক্লাস help with maintainability, readability, discoverability, etc... because they are a well known convention.

In Object Oriented settings, ক্লাস are typically used to group closely related behaviour and to encapsulate state that needs to be controlled carefully.

আমি জানি যে খুব বিমূর্ত শব্দ, কিন্তু আপনি এভাবে এটি নিয়ে ভাবতে পারেন:

With ক্লাস, you don't necessarily need to know how the code in them works. You just need to know what the class is responsible for.

ক্লাস allow you to reason about your application in terms of interactions between well defined components.

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

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

যে বেশ manageable মনে হয়।

সারাংশ

মূলত, আপনি যা দেখছেন সিনিয়র devs কি এই হল:

They are breaking down the application into easy to reason about ক্লাস.

তারপর তারা সম্পর্কে যুক্তিযুক্ত স্তরগুলিতে সংগঠিত হয়।

They are doing this because they know that, as the application grows, it becomes harder and harder to reason about it as a whole. Breaking it down into Layers and ক্লাস means that they never have to reason about the entire application. They only ever need to reason about a small subset of it.

64
যোগ
ছোট ক্লাস ছাড়াও প্রতিস্থাপন/প্রতিস্থাপন করা সহজ।
যোগ লেখক Pieter, উৎস
"ক্লাসগুলির সাথে, তাদের অবশ্যই কীভাবে কোডটি কাজ করে তা জানার দরকার নেই। আপনি কেবল ক্লাসের জন্য কী দায়ী তা জানতে হবে।" শ্রেণীগুলি অবশ্যই এটি অর্জনের একমাত্র উপায় নয়, যদিও তারা কিছু পরিস্থিতিতে একটি কার্যকর উপায় হতে পারে। আরো গুরুত্বপূর্ণ, যদিও, এটি এমন অর্জনের ক্লাস ব্যবহার করে না যা এটি অর্জন করে, এটি একটি বিকাশকারীর দ্বারা ভালো নকশা পছন্দগুলি । ক্লাসগুলি কোনও প্রসারিত দ্বারা আপনাকে এই জাদু সস দেয় না।
যোগ লেখক jmibanez, উৎস
ওপির মতে, কে "তাদের চিন্তাভাবনা বোঝার জন্য অনেক সংগ্রাম করে", মনে হচ্ছে যে কোডটি তৈরি করার পিছনে যুক্তিটি সম্পর্কে যুক্তিযুক্ত হওয়া এত সহজ নয়।
যোগ লেখক Erb, উৎস
হ্যাঁ, overengineering খারাপ। তাই কুকুরছানা হত্যা করা হয়। এখানে কেউ হয় জন্য সমর্থন করা হয় না। logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/169/ করছে & hellip;
যোগ লেখক Warpspace, উৎস
এছাড়াও, সফ্টওয়্যার ইঞ্জিনিয়ারিং প্রেক্ষাপটে "কমনীয়তা" প্রায়ই একটি ভিসেল শব্দ। en.wikipedia.org/wiki/Weasel_word
যোগ লেখক Warpspace, উৎস
একই কোড কোডিং কোনো পদ্ধতির বলা যেতে পারে। রক্ষণাবেক্ষণ দলটি কেন সবকিছু কোডকে সংগঠিত করে তা বোঝে তা সব কিছু। যে ভাল প্রতিষ্ঠিত এবং বোঝা সম্মেলন ব্যবহার সম্পূর্ণ পয়েন্ট।
যোগ লেখক Warpspace, উৎস
@ জেএমপিসি 26 আমি সম্মত, ক্লাস ম্যাজিক হয় না। তবে, তারা প্রায়ই এনক্যাপুলেশন এবং পাবলিক চুক্তি মতো জিনিসগুলির জন্য ভাষা-স্তরের সহায়তা প্রদান করে।
যোগ লেখক Warpspace, উৎস
@ আইসিসি 797 এটির মত আপনি অনুভব করছেন যে অভিজ্ঞতা, প্রসঙ্গ এবং সম্মেলন এবং নকশার জ্ঞান একটি বিশাল পার্থক্য সৃষ্টি করে। এবং যে একটি জুনিয়র dev তাদের এই বিষয় মনে সঙ্গে লেখা কোড গ্রোক করা কঠিন জন্য এই জিনিস অভাব থাকতে পারে।
যোগ লেখক Warpspace, উৎস
Overengineering আপনি যা দাবি করেন তার সত্ত্বেও, নয় আরো রক্ষণশীল বা বোঝার কোডটি দেয় - পুরোপুরি বিপরীত। যখন আপনি সমস্যাটিকে আরও সুন্দরভাবে সমাধান করতে পারেন তখন কে AddressServiceRepositoryProxyInjectorResolver কে প্রয়োজন? নকশা নিদর্শন অনুরোধের জন্য নকশা নিদর্শন শুধু অপ্রয়োজনীয় জটিলতা এবং verbosity বাড়ে।
যোগ লেখক Ian Yates, উৎস
মহান উত্তর! আমি আপনার সাথে মতবিরোধ মন্তব্য এ অবাক
যোগ লেখক reggaeguitar, উৎস
যদি তারা প্রথম সেগুলিকে শ্রেণীতে ভঙ্গ করে এবং তারপর স্তরগুলিকে স্তরগুলিতে সংযোজন করে তবে এতে অবাক হওয়ার কিছু নেই যে জিনিসগুলি নোংরা হয়ে যায়। আপনি এটি প্রায় অন্য উপায় করতে চান (এছাড়াও, আপনি ক্লাস শুরু করতে চান)।
যোগ লেখক Clearer, উৎস
এবং তারপর এটি সম্পূর্ণ প্যাটার্ন বিরতি শুধুমাত্র এক বানর রেঞ্চ লাগে
যোগ লেখক user2890248, উৎস

অনুগ্রহ করে আমাকে ব্যাখ্যা করুন, কেন আমাদের এই ডিডিডি শৈলী, প্রচুর প্যাটার্নস দরকার?

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

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

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

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

Additionally, you see a bit more attention paid to separation of concerns; and the notion of insulating consumers of some capability from the implementation details. See D. L. Parnas. The clear boundaries empower you to change or extend the implementation without the effects rippling throughout you entire solution.

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

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

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

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

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

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

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

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

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

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

প্রভাব অন্যান্য কার্যক্রম আছে:

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

পরীক্ষার কোড কোড লেখা চেয়ে কঠিন কারণ

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

However, there is another aspect to consider - testing can only be fine-grained as your original code.

আপনি যদি একত্রে সবকিছু লিখেন তবে আপনি লিখতে পারেন এমন একমাত্র কার্যকরী পরীক্ষা "এই ইনপুটগুলি দেওয়া হয়, আউটপুট সঠিক?"। এই যে কোন বাগ খুঁজে পাওয়া যায়, "কোড যে দৈত্য পিল মধ্যে কোথাও" scoped হয়।

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

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

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

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

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

19
যোগ
আপনার উত্তরটি কেবলমাত্র পরীক্ষার এবং পরীক্ষার যোগ্যতা সম্বোধন করে, এটি একক সর্বাধিক গুরুত্বপূর্ণ সমস্যা যা অন্য কয়েকটি উত্তর সম্পূর্ণভাবে উপেক্ষা করে +1।
যোগ লেখক Nath, উৎস

অনুগ্রহ করে আমাকে ব্যাখ্যা করুন, কেন আমাদের এই ডিডিডি শৈলী, প্রচুর প্যাটার্নস দরকার?

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

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

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

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

17
যোগ
আপনি কি বলছেন যে আপনার 20 বছরের অভিজ্ঞতার মধ্যে, কোন সমস্যাটি নিজেও একই সমস্যার সমাধান করতে পারে না? আপনি প্রতিটি সময় দুটি একে অপরের সঙ্গে মিথস্ক্রিয়া আছে যখন আপনি সবসময় একটি সম্পূর্ণ নতুন সমাধান তৈরি করেছেন? সুন্দরভাবে প্রত্যেকের উপর নিদর্শন ব্যবহার করা হয় এবং উপর, বই শুধুমাত্র সেখানে তাই আমরা তাদের সম্পর্কে কথা যখন আমরা তাদের একই ভাবে নাম।
যোগ লেখক Rob Hunter, উৎস
একটি বিশুদ্ধ স্তরের সময় এটি DDD এবং অন্যান্য প্যাটার্নগুলি ঠিক মত তত্ত্ব মত শোনাচ্ছে। তারা না। তারা পঠনযোগ্য এবং রক্ষণযোগ্য কোড অর্জন করার জন্য গুরুত্বপূর্ণ সরঞ্জাম।
যোগ লেখক Moogie, উৎস
@vikingsteve OP একটি প্রোগ্রামিং গুরু নয় যা নকশার নকশার সাধারণ ব্যবহার সম্পর্কে মন্তব্য করে। OP একজন শিক্ষানবিশ এবং মনে করে সে তার দোকানে ব্যবহার করা হয় । আমি জানি যে শিক্ষানবিস- আমি আজকাল লিখছি কোড সম্পর্কে একই ভাবতাম, কিন্তু শুরুতে আমার অনেক ব্যক্তিগত প্রকল্প ব্যর্থ হয়েছিল কারণ তারা খুব ধীরে ধীরে শেষ হয়ে গেছে।
যোগ লেখক R. Schmitz, উৎস
@ ভেক্টর আমি এগুলি কতটা ভাল ছিল তা নিয়ে একটু বিরক্ত। এই থেকে "মতামত বলে মনে হচ্ছে" আমার জন্য "100% সম্মত", স্পষ্টভাবে +1!
যোগ লেখক R. Schmitz, উৎস
@Luanan আপনি যদি ইতিমধ্যেই পরিকল্পিত, পরিকল্পিত, সংগঠিত, ওওপি-এর যত্ন নিয়ে থাকেন তবে আমি তাড়াতাড়িই সেই শিক্ষানবিশকে বলব-আপনি, কিন্তু হ্যাঁ অত্যধিক খারাপ। যাইহোক, প্রশ্নটি কীভাবে ওপ বুঝতে পারে না সেগুলি কীভাবে সমস্যার সমাধান করে। যদি আপনি কারণটি জানেন না তবে মনে হচ্ছে কোন কারণ নেই - তবে আসলে আপনি এটি এখনও জানেন না।
যোগ লেখক R. Schmitz, উৎস
@ জেনসচৌডার - আমি আপনার মন্তব্যের আলোকে উত্তরটি সম্পাদনা করেছি। আমি একমত যে সহজভাবে এটি "তত্ত্ব" কলিং সাধারণত ভুল। "পদ্ধতি" অনেক বেশি উপযুক্ত।
যোগ লেখক Vector, উৎস
@ আর। সচমেজ - আমি মন্তব্যগুলি পড়েছি এবং বুঝতে পেরেছি যে আমার ভাষা সত্যিই সঠিক ছিল না এবং আমার অবস্থানটি একটু চরম অনুভূত হয়েছিল।
যোগ লেখক Vector, উৎস
@PeteKirkham ওপিএস ডিল্মমা নকশা নকশার overuse । আপনি কি সত্যিই একটি অ্যাকাউন্টসerviceফ্যাকডইনজেক্টসেসলভার (প্রকৃত উদাহরণ আমি শুধু কাজের একটি সিস্টেমের মধ্যে খুঁজে পেয়েছি) প্রয়োজন - উত্তর সম্ভবত সম্ভবত নয়।
যোগ লেখক Ian Yates, উৎস
@ আর। শচীমেজ বলেন যে, আমার প্রারম্ভিক ব্যক্তিগত প্রকল্পগুলি ব্যর্থ হয়েছে কারণ তারা খুব ভালভাবে পরিকল্পিত, সংগঠিত, কাঠামোগত, ওওপি তৈরির জন্য কঠোর চেষ্টা করেছিল ... এগুলি সবই সরঞ্জাম। তারা সঠিকভাবে বুঝতে এবং ব্যবহার করা প্রয়োজন, এবং আপনি screwing সময়ে দরিদ্র জন্য হাতুড়ি দোষারোপ করতে পারেন। বিস্ময়করভাবে, এই সহজ জিনিসটি বোঝার জন্য এটি অনেক অন্তর্দৃষ্টি এবং অভিজ্ঞতা নিতে পারে বলে মনে হচ্ছে :)
যোগ লেখক Luaan, উৎস
আমার অভিজ্ঞতার অদ্ভুত জিনিসটি আমি AccountServiceFacadeInjectResolver টাইপ জিনিসগুলি প্রায়ই কোডে ডিডিডি ব্যবহার না করে টাইপ করি। স্প্রিং-ভিত্তিক অ্যাপ্লিকেশনগুলি প্রায় সম্পূর্ণরূপে শ্রেণী বলে মনে হয় যা সমস্যা ডোমেনের চেয়ে ফ্রেমওয়ার্কটি পূরণ করতে আরো বেশি কিছু করে।
যোগ লেখক Rob Crawford, উৎস

আপনার প্রশ্নটি প্রচুর পরিমাণে গ্রাউন্ডে আচ্ছাদিত, অনেক ধারনা নিয়ে, আমি আপনার প্রশ্নের বিষয়টিকে একক করবো:

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

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

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

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

কেন তাদের দুটি গুরুত্বপূর্ণ হতে হবে?

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

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

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

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

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

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

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

8
যোগ

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

  • কারণ ক্ষুদ্রতম প্রোগ্রামগুলি এবং ক্ল্যাসেস বৃদ্ধি পেতে শুরু করে, বিশেষ করে সফল ব্যক্তিরা। একটি সহজ স্তরে কাজ করা যে সহজ নিদর্শন স্কেল না।
  • কারন প্রতিটি অ্যাড/পরিবর্তনের জন্য বেশ কয়েকটি আর্টিফেক্ট যুক্ত করতে/পরিবর্তন করতে বোঝা কঠিন বলে মনে হয় তবে আপনি কী যোগ করতে পারেন তা জানেন এবং এটি করা সহজ। 3 মিনিটের টাইপ করা চতুর কোডিংয়ের 3 ঘন্টা।
  • ছোট ছোট ক্লাসগুলি কেবল "নোংরা" নয় কারণ আপনি বোঝেন না কেন ওভারহেড আসলে একটি ভাল ধারণা
  • ডোমেন জ্ঞান যুক্ত না করে, 'আমার কাছে স্পষ্ট' কোড প্রায়শই আমার দলের সঙ্গীদের সাথে রহস্যময় ... এবং ভবিষ্যতেরও আমার কাছে।
  • উপজাতীয় জ্ঞানগুলি দ্রুতগতিতে উত্পাদনশীল হওয়ার জন্য টিম সদস্যদেরকে সহজে এবং শক্তিতে যুক্ত করতে প্রকল্পগুলিকে অবিশ্বাস্যভাবে কঠিন করে তুলতে পারে।
  • কম্পিউটিংয়ে দুটি হার্ড সমস্যাগুলির মধ্যে নামকরণটি এখনও সত্য এবং অনেকগুলি ক্লাস এবং পদ্ধতি প্রায়ই নামকরণে একটি তীব্র অনুশীলন হয় যা অনেকগুলি দুর্দান্ত সুবিধা বলে মনে করে।
7
যোগ
@vikingsteve আপনি একটি ত্রুটিপূর্ণ বাস্তবায়নের এক উদাহরণের কথা উল্লেখ করছেন যা আশা করে যে এটি প্রমাণ করবে যে, গঠনমূলক কোডটি সাধারণভাবে একটি খারাপ ধারণা। যে শুধু ট্র্যাক না।
যোগ লেখক Warpspace, উৎস
@ ক্লিয়ারার আমি নিশ্চিত যে এখানে সবাই সবার সাথে একমত যে structured কোডের কল্পনাপ্রসূত অপব্যবহার একটি খারাপ জিনিস। ওপি বলেছে তারা জুনিয়র। এই কারণে মানুষ মনে করে সে কাঠামোগত কোডের সুবিধাগুলি সম্পর্কে অপরিচিত এবং তাদের পুনরাবৃত্তি করে।
যোগ লেখক Warpspace, উৎস
কিন্তু ওভারহেড প্রয়োজন? আমি দেখতে যে অনেক ক্ষেত্রে, নকশা নিদর্শন overused হয়। Overcompleity ফলাফল বোঝার, বজায় রাখা, টেস্টিং এবং ডিবাগিং কোড অসুবিধা বৃদ্ধি করা হয়। যখন আপনার একটি সাধারণ পরিষেবা শ্রেণির প্রায় 1২ টি ক্লাস এবং 4 মেনন মডিউল থাকে (একটি বাস্তব উদাহরণ যা আমি দেখেছি), তা দ্রুত মনে হয় তার চেয়ে কম কার্যকর হতে পারে।
যোগ লেখক Ian Yates, উৎস
@ মেটাফাইট ওপি স্ট্রাকচার কোড সম্পর্কে কথা বলছে না। সে কথা বলছে, সে যা দেখেছে, অনেকগুলি বিমূর্ততা। আপনার যদি অনেকগুলি বিমূর্ততা থাকে, তবে আমি তর্ক করে বলি, আপনি দ্রুত খুব অসঙ্গতিপূর্ণ কোড এবং প্রায় একই রকমের টুকরাগুলি পাবেন, কারণ লোকেরা তাদের সাথে যে পরিমাণে সমস্যার সমাধান করতে পারে তার সাথে সামঞ্জস্য করতে পারে না।
যোগ লেখক Clearer, উৎস

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

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

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

4
যোগ
দুঃখিত, কিন্তু আপনি কি বলছেন?
যোগ লেখক Shizam, উৎস
এই উত্তরটি স্পষ্টভাবে উপস্থাপন করতে হবে যে এটি স্পষ্ট ইংরেজীতে উপস্থাপন করার জন্য প্রতীয়মান হয়। মনে হচ্ছে যে মূল ধারণাটির উত্তরটি হল যে ছোট ক্লাসগুলি, প্রতিটি একটি ভাল সংজ্ঞায়িত কার্যকারিতা, এটি একটি ভাল ধারণা, তবে ভয়ানক ব্যাকরণটি বোঝা প্রায় অসম্ভব। এছাড়াও, নিজেই, এই দাবি যথেষ্ট নাও হতে পারে।
যোগ লেখক Stefan Kendall, উৎস
@ ডেডুপ্লিকারেটর জাভাতে একটি উদাহরণ নেব যদি আমরা ডিজাইন করি আমরা তাদের উত্তরাধিকারের জন্য jframes threads এবং ক্লাস ব্যবহার করি। শুধুমাত্র এক ক্লাস থেকে আমরা ডিজাইনের জন্য জাভা কিছু কাজ ব্যবহার করতে পারছি না তাই আমাদের আরও ক্লাস করতে হবে
যোগ লেখক David Farrell, উৎস

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

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

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

2
যোগ