রিফ্যাক্টরিং এবং ওপেন / ক্লোজড নীতি

Question

আমি সম্প্রতি ক্লিন কোড বিকাশ সম্পর্কে একটি ওয়েবসাইট পড়ছি (আমি এখানে একটি লিঙ্ক রাখি না কারণ এটি ইংরেজিতে নেই)।

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

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

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

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

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

Answer 1

আমি ওপেন-ক্লোজড নীতিটিকে একটি ডিজাইনের লক্ষ্য হিসাবে মনে করি । যদি আপনি এটি লঙ্ঘন করেই শেষ করেন তবে এর অর্থ হল আপনার প্রাথমিক নকশাটি ব্যর্থ হয়েছে, যা অবশ্যই সম্ভব এবং সম্ভবত।

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

আপনি এটা সম্ভব আপনার পরবর্তী বৈশিষ্ট্য বাস্তবায়ন করতে একটি refactoring করছেন করা যেতে পারে ছাড়া OCP লঙ্ঘনের যখন আপনি এটি না।

Comments

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

— টি। সর

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

— তুলিনস কর্ডোভা

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

— টি। সর

@ টি.এসআর এমন অনেকগুলি জিনিস রয়েছে যা আপনি কোনও ক্লায়েন্টের কাছে বিক্রি করতে পারবেন না ... অন্যদিকে, আমি আপনার সাথে একমত যে প্রকল্পের লক্ষ্যগুলি থেকে বিরত হওয়া জিনিসগুলি অবশ্যই করা উচিত নয়।

— তুলিনাস কর্ডোভা

Answer 2

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

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

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

যথাযথ স্তরে ওসির খুব ঘন ঘন লঙ্ঘন প্রস্তাব দিচ্ছে যে সম্ভবত রিফ্যাক্টর করার সময় এসেছে । "উপযুক্ত স্তর" একটি রায় কল যা আপনার সামগ্রিক ডিজাইনের সাথে সম্পর্কিত everything

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

Comments

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

— জর্জিও

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

— রডারবব

নতুন পদ্ধতি যুক্ত করা ওএসপি নয়, এলএসপি লঙ্ঘন করে।

— তুলিনস কর্ডোভা

নতুন পদ্ধতি যুক্ত করা এলএসপি লঙ্ঘন করে না । আপনি যদি একটি পদ্ধতি যুক্ত করুন, তাহলে আপনি একটি এনেছি নতুন ইন্টারফেস @ TulainsCórdova

— RubberDuck

Answer 3

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

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

Comments

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

— জর্জিও

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

— জর্জিও

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

— তুলিনস কর্ডোভা

অ্যাপ্লিকেশন কোডে টিউইলেন্সকার্ডোভা @ এটি প্রাসঙ্গিক নয়। লাইব্রেরি কোডের জন্য আমি যুক্তিযুক্ত সংস্করণটি ভাঙ্গা পরিবর্তনগুলি যোগাযোগের জন্য ভাল ফিট ছিল।

— opsb

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

— সংস্করণী

Answer 4

সাধারণ মানুষের কথায়:

উ: হে / সি নীতি মানে যে বিশেষজ্ঞতা ব্যাপ্ত, দ্বারা নয় একটি বর্গ বিশেষ প্রয়োজনের জন্য মিটমাট পরিবর্তন করা উচিত নয়।

বি। অনুপস্থিত (বিশেষীকৃত নয়) কার্যকারিতা যুক্ত করার অর্থ ডিজাইনটি সম্পূর্ণ হয়নি এবং চুক্তি লঙ্ঘন না করে আপনাকে অবশ্যই এটি বেস শ্রেণিতে যুক্ত করতে হবে। আমি মনে করি এটি নীতি লঙ্ঘন করছে না।

গ। রিফ্যাক্টরিং নীতি লঙ্ঘন করে না।

যখন কোনও নকশা পরিপক্ক হয় , তখন বলুন, কিছু সময় উত্পাদনের পরে:

• সময়ের সাথে শূন্যের দিকে ঝুঁকতে এমন (পয়েন্ট বি) করার খুব কম কারণ থাকতে হবে।
• (পয়েন্ট সি) আরও বিরল হলেও সর্বদা সম্ভব হবে।
• সমস্ত নতুন কার্যকারিতা একটি বিশেষায়নের বলে মনে করা হচ্ছে, অর্থাত ক্লাসগুলি প্রসারিত করতে হবে (উত্তরাধিকার সূত্রে প্রাপ্ত) (পয়েন্ট এ)।

Comments

খোলা / বন্ধ নীতিটি খুব বেশি ভুল বোঝাবুঝি। আপনার পয়েন্টগুলি এ এবং বি ঠিক এটি পেয়েছে।

— gnasher729

Answer 5

আমার কাছে, ওপেন-ক্লোজড প্রিন্সিপাল একটি গাইডলাইন, কঠোর এবং দ্রুত নিয়ম নয়।

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

বন্ধ অংশটি সম্পর্কে, যখন কোনও পণ্যটির ২.০ সংস্করণ থেকে ২.১ থেকে ২.২ থেকে ২.৩ অবধি চলছে, আচরণ পরিবর্তন না করা খুব ভাল ধারণা। প্রত্যেকটি ছোটখাটো রিলিজ তাদের নিজস্ব কোড বিড ভেঙে গেলে ব্যবহারকারীরা সত্যই এটি পছন্দ করে না। তবে, যেভাবে প্রায়শই দেখা যায় যে 2.0 সংস্করণে প্রাথমিক প্রয়োগটি মৌলিকভাবে ভেঙে গেছে, বা প্রাথমিক নকশাকে সীমাবদ্ধ করে এমন বাহ্যিক প্রতিবন্ধকতাগুলি আর প্রয়োগ হয় না। আপনি কি এটি গ্রিন করে সহ্য করেন এবং 3.0 এর মুক্তির ক্ষেত্রে সেই নকশাটি বজায় রাখেন, বা আপনি কিছু ক্ষেত্রে 3.0-অন-পশ্চাদপটে সামঞ্জস্যপূর্ণ করেছেন? পিছনের সামঞ্জস্য একটি বিশাল বাধা হতে পারে। প্রধান রিলিজ সীমানা এমন জায়গা যেখানে পশ্চাৎসঙ্গতি সামঞ্জস্যতা গ্রহণযোগ্য। আপনার সচেতন হওয়া দরকার যে এটি করার ফলে আপনার ব্যবহারকারীদের মন খারাপ হতে পারে। অতীতের সাথে এই বিরতি কেন প্রয়োজন তার জন্য একটি ভাল কেস থাকতে হবে।

Answer 6

সংশোধন করে, সংজ্ঞা অনুসারে, আচরণ পরিবর্তন না করে কোডের কাঠামো পরিবর্তন করা হয়। সুতরাং আপনি যখন অশোধক, আপনি নতুন বৈশিষ্ট্য যোগ করবেন না।

ওপেন ক্লোজ নীতিটির উদাহরণ হিসাবে আপনি যা করেছেন তা ঠিক মনে হচ্ছে। এই নীতিটি নতুন বৈশিষ্ট্য সহ বিদ্যমান কোড প্রসারিত করার বিষয়ে।

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

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

নিখুঁত নকশার মতো জিনিস নেই। এমন কোনও নকশা নেই যা বিদ্যমান নীতি বা নিদর্শনগুলিকে সম্মান করতে পারে এবং উচিত। যে ইউটোপিয়া কোডিং হয়।

আমি আশা করি এই উত্তরটি আপনাকে আপনার দ্বিধায় ফেলেছে। প্রয়োজনে নির্দ্বিধায় স্পষ্টতা জিজ্ঞাসা করুন।

Comments

"সুতরাং আপনি যখন রিফ্যাক্টর করবেন তখন নতুন বৈশিষ্ট্য যুক্ত করবেন না" ": তবে আমি একটি পরীক্ষিত সফ্টওয়্যারটিতে বাগগুলি প্রবর্তন করতে পারি।

— জর্জিও

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

— জর্জিও

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

— প্যাটকোস সিএসবা

@ জর্জিও যদি কোডটি কোডের Bউপর ভিত্তি করে Aবিবর্তন হিসাবে তৈরি করা হয় A, যখন Bপ্রকাশিত হয়, Aতার পরে অপসারণ করা উচিত এবং আর কখনও ব্যবহার করা উচিত নয়। পূর্বে ব্যবহার করা ক্লায়েন্টরা পরিবর্তনের কথা না জেনে Aকেবল ব্যবহার করবে B, কারণ ইন্টারফেসটি Iপরিবর্তন করা হয়নি (সম্ভবত এখানে

— লিসকোভ

হ্যাঁ, এটি আমার মনে ছিল: আপনার বৈধ (ভাল-পরীক্ষা করা) প্রতিস্থাপন না করা পর্যন্ত কার্যকরী কোডটি ফেলে দেবেন না।

— জর্জিও

Answer 7

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