The general idea for the Connection Pool pattern is that if instances of a class can be reused, you avoid creating instances of the class by reusing them.
Основната идея е да имаме дадена data structure, например масив, която да съдържа готови обекти, които можем да използваме когато ни трябват, вместо да създаваме нови, особено когато са „expensive to create“.
Но идеята е както просто да съхраняваме дадената data structure но и да я менажираме като например колко максимално да са обектите, маркиране като „ангажирани“ на тези, които изпозваме, връщане в изходно състояние (reset) на обект, който освобождаваме, унищожаване ненужните и т.н…
Basically, an Object pool is a container which contains some amount of objects. So, when an object is taken from the pool, it is not available in the pool until it is put back.
В този смисъл, Object Pool design pattern е близък по идея с Prototype design pattern, защото елиминира инстанцирането (когато е възможно), което е по принцип „скъпо“.
Както и на Multiton design pattern и до Singleton design pattern, защото предлага кеширане на обекти вместо пре-създаването им всеки път когато ни трябват, но с разликата че Singleton се използва за един обект, от един клас, а не много както тук.
Object pools (otherwise known as resource pools) are used to manage the object caching. A client with access to a Object pool can avoid creating a new Objects by simply asking the pool for one that has already been instantiated instead.
Този design pattern може най-просто да се реализира програмно с помощта на един клас ObjectPoolClass да гарантираме, че ще имаме само един object pool, този singleton клас ще има едни private масив $objects, и ще имаме и например два метода acquire() и release() за извличане на нужният обект и за унищожаване на ненужен.
При тези два метода можем да използваме Factory design pattern, подавайки името на нужният клас, чиито обект ни трябва.
Важно е да се знае, че когато вземем нужният ни обект, друг клиент не трябва да може да го взема, тоест трябва например някак да го маркираме като зает.
A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished, it returns the object to the pool rather than destroying it; this can be done manually or automatically.
The object pool design pattern creates a set of objects that may be reused. When a new object is needed, it is requested from the pool.
1. If a previously prepared object is available it is returned immediately, avoiding the instantiation cost.
2. If no objects are present in the pool, a new item is created and returned.
3. When the object has been used and is no longer needed, it is returned to the pool, allowing it to be used again in the future without repeating the computationally expensive instantiation process. It is important to note that once an object has been used and returned, existing references will become invalid.
И разбира се, когато го „върнем“ първо трябва да го размаркираме като свободен, и непременно да го върнем в „чисто“ /pristine/, първоначално състояние за следващите „ползватели“.
Care must be taken to ensure the state of the objects returned to the pool is reset back to a sensible state for the next use of the object, otherwise the object may be in an state unexpected by the client, which may cause it to fail.
Също и, по подобни причини, трябва да се внимава със статичните пропъртита, ако такива се използват, защото те могат да се запазват на ниво клас и могат да запазят стойностите си при отделните извиквания на даденият обект от клиент на клиент.
Това важи особено когато даденият обект съдържа поверителна информация.
Добър пример за този design pattern в живота би бил например офисът на дадена фирма, всеки човек си има работно място, ако дойде нов и нямаме необходимото за него оборудване, купуваме и вече го имаме като собственост на фирмата, ако човекът напусне – запазваме го евентуално за следващият служител, който ще дойде. Ако няма да наемаме друг – изхвърляме оборудването му.