স্থির পদ্ধতি ব্যবহারের বিরুদ্ধে প্রধান দুটি কারণ হ'ল:
- স্ট্যাটিক পদ্ধতি ব্যবহার করে কোড পরীক্ষা করা শক্ত
- স্ট্যাটিক পদ্ধতি ব্যবহার করে কোডটি প্রসারিত করা শক্ত
অন্য কোনও পদ্ধতির অভ্যন্তরে স্থির পদ্ধতি কল করা বৈশ্বিক পরিবর্তনশীল আমদানির চেয়ে খারাপ। পিএইচপি-তে ক্লাসগুলি বিশ্বব্যাপী প্রতীক, তাই আপনি যখনই স্থির পদ্ধতিতে কল করবেন তখনই আপনি বিশ্বব্যাপী প্রতীক (শ্রেণীর নাম) এর উপর নির্ভর করেন। এটি এমন একটি ঘটনা যখন বিশ্বব্যাপী মন্দ। জেন্ড ফ্রেমওয়ার্কের কিছু উপাদান নিয়ে এই ধরণের পদ্ধতির সাথে আমার সমস্যা ছিল। এমন ক্লাস রয়েছে যা অবজেক্ট তৈরির জন্য স্থির পদ্ধতি কল (কারখানাগুলি) ব্যবহার করে। কাস্টমাইজড বস্তুটি ফেরত পাওয়ার জন্য আমার পক্ষে সেই উদাহরণে অন্য কারখানা সরবরাহ করা অসম্ভব ছিল। এই সমস্যার সমাধান হ'ল প্রোগ্রামের শুরুতে কেবল উদাহরণ এবং ইনস্টাস্টের পদ্ধতি ব্যবহার করা এবং সিঙ্গেলন এবং এর মতো প্রয়োগ করা।
গুগলে অ্যাগ্রিল কোচ হিসাবে কাজ করা মিয়াকো হেভির একটি আকর্ষণীয় তত্ত্ব আছে, বা বরং পরামর্শ দিয়েছিল যে আমরা যখন অবজেক্টটি ব্যবহার করি তখন থেকেই আমাদের অবজেক্ট তৈরির সময়কে আলাদা করা উচিত। সুতরাং একটি প্রোগ্রামের জীবনচক্র দুটি বিভক্ত হয়। প্রথম অংশ ( main()পদ্ধতিটি বলি), যা আপনার আবেদনের সমস্ত অবজেক্ট ওয়্যারিং এবং প্রকৃত কাজ করে এমন অংশের যত্ন করে।
পরিবর্তে থাকার কারণে:
class HttpClient
{
public function request()
{
return HttpResponse::build();
}
}
আমাদের বরং করা উচিত:
class HttpClient
{
private $httpResponseFactory;
public function __construct($httpResponseFactory)
{
$this->httpResponseFactory = $httpResponseFactory;
}
public function request()
{
return $this->httpResponseFactory->build();
}
}
এবং তারপরে, সূচক / প্রধান পৃষ্ঠায়, আমরা করতাম (এটি হ'ল অবজেক্ট ওয়্যারিং স্টেপ, বা প্রোগ্রামটি ব্যবহারের জন্য উদাহরণগুলির গ্রাফ তৈরির সময়):
$httpResponseFactory = new HttpResponseFactory;
$httpClient = new HttpClient($httpResponseFactory);
$httpResponse = $httpClient->request();
মূল ধারণাটি হ'ল আপনার ক্লাসের বাইরে নির্ভরতাগুলি দ্বিগুণ করা। এইভাবে কোডটি অনেক বেশি এক্সটেনসিবল এবং, আমার জন্য সবচেয়ে গুরুত্বপূর্ণ অংশ, পরীক্ষামূলক। পরীক্ষার যোগ্য হওয়া কেন এটি আরও গুরুত্বপূর্ণ? কারণ আমি সবসময় লাইব্রেরি কোড লিখি না, সুতরাং এক্সটেনসিবিলিটি তেমন গুরুত্বপূর্ণ নয়, তবে আমি যখন রিফ্যাক্টরিং করি তখন টেস্টিবিলিটি গুরুত্বপূর্ণ। যাইহোক, টেস্টেবল কোডটি সাধারণত এক্সটেনসিবল কোড দেয়, সুতরাং এটি সত্যিই কোনও বা কোনও পরিস্থিতি নয়।
মিউকো হেভরি সিঙ্গলটনের এবং সিঙ্গলটনের মধ্যেও একটি স্পষ্ট পার্থক্য তৈরি করে (মূলধন এস সহ বা ছাড়াই)। পার্থক্য খুব সহজ। একটি নিম্ন কেস "s" সহ সিঙ্গেলটনগুলি সূচক / প্রধানতে তারের দ্বারা প্রয়োগ করা হয়। আপনি এমন কোনও শ্রেণীর কোনও অবজেক্ট ইনস্ট্যান্ট করেন যা সিঙ্গলটন প্যাটার্নটি প্রয়োগ করে না এবং যত্ন নেবেন যে আপনি কেবলমাত্র এই দৃষ্টান্তটি অন্য যে কোনও প্রয়োজনে প্রেরণ করবেন। অন্যদিকে, সিঙ্গেলটন, মূলধন "এস" সহ ধ্রুপদী (বিরোধী) প্যাটার্নের প্রয়োগ। মূলত ছদ্মবেশে একটি গ্লোবাল যা পিএইচপি বিশ্বে খুব বেশি ব্যবহার করে না। আমি এখন পর্যন্ত একটিও দেখিনি। আপনি যদি চান যে আপনার একক ডিবি সংযোগটি আপনার সমস্ত শ্রেণীর দ্বারা ব্যবহৃত হয় তবে এটি এটি করা ভাল:
$db = new DbConnection;
$users = new UserCollection($db);
$posts = new PostCollection($db);
$comments = new CommentsCollection($db);
উপরের কাজগুলি করে এটি স্পষ্ট যে আমাদের একটি সিঙ্গলটন রয়েছে এবং আমাদের পরীক্ষাগুলিতে একটি উপহাস বা স্টাব ইনজেকশনেরও একটি দুর্দান্ত উপায় রয়েছে। এটি আশ্চর্যজনকভাবে কীভাবে ইউনিট পরীক্ষাগুলি আরও ভাল ডিজাইনের দিকে পরিচালিত করে। কিন্তু যখন আপনি মনে করেন যে পরীক্ষাগুলি আপনাকে সেই কোডটি কীভাবে ব্যবহার করবেন সে সম্পর্কে ভাবতে বাধ্য করে তবে এটি প্রচুর অর্থবোধ করে।
/**
* An example of a test using PHPUnit. The point is to see how easy it is to
* pass the UserCollection constructor an alternative implementation of
* DbCollection.
*/
class UserCollection extends PHPUnit_Framework_TestCase
{
public function testGetAllComments()
{
$mockedMethods = array('query');
$dbMock = $this->getMock('DbConnection', $mockedMethods);
$dbMock->expects($this->any())
->method('query')
->will($this->returnValue(array('John', 'George')));
$userCollection = new UserCollection($dbMock);
$allUsers = $userCollection->getAll();
$this->assertEquals(array('John', 'George'), $allUsers);
}
}
একমাত্র পরিস্থিতি যেখানে আমি ব্যবহার করব (এবং আমি পিএইচপি 5.3 তে জাভাস্ক্রিপ্ট প্রোটোটাইপ অবজেক্টটি নকল করতে তাদের ব্যবহার করেছি) স্থির সদস্যরা যখন আমি জানি যে সংশ্লিষ্ট ক্ষেত্রে একই মান ক্রস-ইনস্ট্যান্স থাকবে। সেই সময়ে আপনি একটি স্থির সম্পত্তি এবং সম্ভবত স্ট্যাটিক গেটর / সেটার পদ্ধতিগুলির একজোড়া ব্যবহার করতে পারেন। যাইহোক, কোনও স্থায়ী সদস্যের সাথে স্থির সদস্যকে ওভাররাইড করার সম্ভাবনা যুক্ত করতে ভুলবেন না। উদাহরণস্বরূপ জেন্ড ফ্রেমওয়ার্ক একটি স্থিতিশীল সম্পত্তি ব্যবহার করছিল যাতে উদাহরণ হিসাবে ব্যবহৃত ডিবি অ্যাডাপ্টার শ্রেণীর নাম নির্দিষ্ট করে Zend_Db_Table। এগুলি ব্যবহার করার পরে কিছুক্ষণ হয়ে গেছে তাই এটি আর প্রাসঙ্গিক নাও হতে পারে তবে এটি আমার মনে আছে।
স্থিতিশীল পদ্ধতি যা স্থির বৈশিষ্ট্যের সাথে লেনদেন করে না সেগুলির কার্যকারিতা হওয়া উচিত। পিএইচপি এর ফাংশন রয়েছে এবং আমাদের সেগুলি ব্যবহার করা উচিত।