Mga pattern ng disenyo: singleton, factory, factory method, abstract factory

"Hi, Amigo!"

"Hi, Bilaabo!"

"Ang aming paksa ngayon ay hindi lamang magiging kawili-wili - ito ay talagang epiko."

"Ngayon pupuntahan kita kung ano ang mga pattern ng disenyo. "

"Cool! Marami akong narinig tungkol sa kanila. I can't wait!"

"Ang mga nakaranasang programmer ay kailangang magsulat ng maraming klase. Ngunit ang pinakamahirap na bahagi ng trabahong ito ay ang pagpapasya kung aling mga klase ang lilikhain at kung paano hatiin ang gawain sa kanila."

"Kung mas nalutas nila ang mga ganoong katanungan, mas napagtanto nila na ang ilang mga solusyon ay mabuti, habang ang iba ay masama."

"Ang mga masasamang solusyon ay kadalasang lumilikha ng mas maraming problema kaysa sa kanilang nilulutas. Sila ay lumalawak nang hindi maganda, lumilikha ng maraming hindi kinakailangang limitasyon, atbp. At ang magagandang solusyon ay ang kabaligtaran."

"Mayroon ka bang pagkakatulad na magagawa mo?"

"Sabihin na nating nagpapatayo ka ng bahay. At iniisip mo kung ano ang gagawin nito. Napagpasyahan mong kailangan mo ng mga dingding, sahig, at kisame. Bilang resulta, gumawa ka ng isang bahay na may patag na bubong at walang pundasyon. Ang ganyang bahay ay mabibitak, at ang bubong ay tatagas. Ito ay isang masamang solusyon."

"Sa kabaligtaran, ang isang bahay na binubuo ng isang pundasyon, mga dingding, at isang gable na bubong ay magiging isang magandang solusyon. Ang malakas na pag-ulan ng niyebe ay nagpapakita ng walang problema, dahil ang snow ay dumudulas mula sa bubong. At ang paglilipat ng mga lupa ay walang dapat na katakutan, dahil ang pundasyon ay titiyakin katatagan. Matatawag nating mabuti ang gayong solusyon."

"I see. Salamat."

"Sige. Tapos itutuloy ko."

"Sa paglipas ng panahon, ang magagandang solusyon ay nakilala bilang mga pattern ng disenyo, habang ang mga hindi maganda ay tinawag na mga anti-pattern."

"Ang pattern ng disenyo ay parang sagot sa isang tanong. Mahirap intindihin kung hindi mo pa narinig ang tanong."

" Ang unang kategorya ng mga pattern ay creational patterns. Ang ganitong mga pattern ay naglalarawan ng magagandang solusyon na nauugnay sa paglikha ng mga bagay."

"Ano ang kumplikado tungkol sa paglikha ng mga bagay?"

"As it happens, yun lang ang i-explore natin ngayon."

Pattern ng singleton.

"Kadalasan sa mga programa, isang kopya lang ng ilang bagay ang maaaring umiral. Halimbawa, ang console, logger, garbage collector, atbp."

" Masamang solusyon: huwag lumikha ng anumang mga bagay - lumikha lamang ng isang klase na ang lahat ng mga pamamaraan ay static."

" Magandang solusyon:  lumikha ng isang bagay at iimbak ito sa isang static na variable. Pigilan ang paglikha ng pangalawang object ng klase. Halimbawa:"

class Sun
{
 private static Sun instance;
 public static Sun getInstance()
 {
  if (instance == null)
  instance = new Sun();

  return instance;
 }

 private Sun()
 {
 }
}

Sun sun = Sun.getInstance();

"Simple lang."

"Una, ginagawa naming pribado ang constructor. Ngayon ay maaari lamang itong tawagan mula sa loob ng aming klase. Na-block namin ang paglikha ng mga bagay sa Araw kahit saan maliban sa mga pamamaraan ng klase ng Araw."

"Pangalawa, ang isang bagay ng klase na ito ay maaari lamang makuha sa pamamagitan ng pagtawag sa getInstance() na pamamaraan.

"Nakita ko."

"Kapag naisip mo, «Ngayon, paano ko gagawin iyon?», sabi ng isang pattern, «maaari mong subukan ito — isa ito sa mga pinakamahusay na solusyon."

"Salamat. Ngayon nagsisimula nang maging malinaw ang mga bagay-bagay."

"Maaari mo ring basahin ang tungkol sa pattern na ito  dito ."

Pattern ng pabrika.

"Narito ang isang sitwasyon na madalas na kinakaharap ng mga programmer. Mayroon kang ilang base class at maraming subclass. Halimbawa, isang game character class (GamePerson) at mga klase para sa lahat ng iba pang character na nagmamana nito."

"Sabihin nating mayroon kang mga sumusunod na klase:"

abstract class GamePerson
{
}

class Warrior extends GamePerson
{
}

class Mag extends GamePerson
{
}

class Troll extends GamePerson
{
}

class Elf extends GamePerson
{
}

"Ang tanong ay kung paano namin nababaluktot at maginhawang pamahalaan ang paglikha ng mga bagay ng mga klase na ito."

"Kung ang problemang ito ay tila malayo sa iyo, isipin na sa laro ay kailangan mong lumikha ng dose-dosenang mga espada at kalasag, daan-daang magic spell, at libu-libong halimaw. Hindi mo magagawa nang walang maginhawang diskarte sa paglikha ng bagay dito. "

"Ang Factory pattern ay nag-aalok ng magandang solusyon."

"Una, kailangan nating lumikha ng isang enum na ang mga halaga ay tumutugma sa iba't ibang klase."

"Pangalawa, lumikha ng isang espesyal na klase ng Pabrika na mayroong (mga) static na pamamaraan na lumikha ng (mga) bagay batay sa isang halaga ng enum."

"Halimbawa:"

public enum PersonType
{
 UNKNOWN,
 WARRIOR,
 MAG,
 TROLL,
 ELF,
}

public class PersonFactory
{
 public static GamePerson createPerson(PersonType personType)
 {
  switch(personType)
  {
   WARRIOR:
   return new Warrior();
   MAG:
   return new Mag();
   TROLL:
   return new Troll();
   ELF:
   return new Elf();
   default:
   throw new GameException();
  }
 }
}

GamePerson person = PersonFactory.createPerson(PersonType.MAG);

"Sa madaling salita, lumikha kami ng isang espesyal na klase upang pamahalaan ang paglikha ng bagay?"

"Oo."

"Kaya anong mga pakinabang ang ibinibigay nito?"

"Una, sa klase na ito, maaaring masimulan ang mga bagay gamit ang kinakailangang data."

"Pangalawa, maaari mong ipasa ang kinakailangang halaga ng enum sa pagitan ng mga pamamaraan hangga't gusto mo upang sa huli ay malikha ang nais na bagay."

"Ikatlo, ang bilang ng mga enum field ay hindi kailangang tumugma sa bilang ng mga klase. Maaaring may maraming uri ng mga character, ngunit kakaunti ang mga klase."

"Halimbawa, ang isang Mag & Warrior ay maaaring gumamit ng isang klase (Tao), ngunit may iba't ibang lakas at mahiwagang katangian (mga argumento ng tagabuo)."

"Narito ang maaaring hitsura nito (para sa kalinawan, nagdagdag din ako ng mga dark elf):"

public enum PersonType
{
 UNKNOWN,
 WARRIOR,
 MAG,
 TROLL,
 ELF,
 DARK_ELF
}

public class PersonFactory
{
 public static GamePerson createPerson(PersonType personType)
 {
  switch(personType)
  {
   WARRIOR:
   return new Human(10, 0); // Strength, magic
   MAG:
   return new Human(0, 10); // Strength, magic
   TROLL:
   OGR:
   return new Troll();
   ELF:
   return new Elf(true); // true – good, false – evil
   DARK_ELF:
   return new Elf(false); // true – good, false – evil
   default:
   throw new GameException();
  }
 }
}

GamePerson person = PersonFactory.createPerson(PersonType.MAG);

"Sa halimbawa sa itaas, gumamit lamang kami ng tatlong klase upang lumikha ng anim na iba't ibang uri ng mga bagay.

"Ngayon ipagpalagay na nagpasya kaming lumikha ng isang hiwalay na klase para sa Ogre - pinapalitan lang namin ang ilang linya ng code dito, at hindi kalahati ng application."

"Sumasang-ayon ako. Magandang solusyon iyon."

"At iyon ang pinag-uusapan ko: ang mga pattern ng disenyo ay mga koleksyon ng magagandang solusyon."

"Sana alam ko rin kung saan gagamitin ang mga ito..."

"Oo. Sumasang-ayon ako, hindi mo kaagad maiintindihan. Gayunpaman, mas mabuting malaman at hindi magawa kaysa hindi alam at hindi magawa. Narito ang isa pang kapaki-pakinabang na link para sa iyo tungkol sa pattern na ito: Pattern ng Pabrika "

"Oh salamat."

" Abstract na pattern ng pabrika."

"Minsan kapag marami kang bagay, ang ideya ng paglikha ng pabrika para sa mga pabrika ay nagmumungkahi mismo. Ang ganitong pabrika ay tinatawag na abstract factory ."

"Saan ito kakailanganin?!"

"Ipagpalagay na mayroon kang ilang mga grupo ng magkatulad na mga bagay. Ito ay mas madaling ipakita sa isang halimbawa."

"Ngayon, sabihin nating mayroon kang tatlong karera sa iyong laro: mga tao, duwende, at mga demonyo. At para sa balanse, ang bawat lahi ay may mga mandirigma, mamamana, at salamangkero. Ang isang manlalaro ay maaari lamang lumikha ng mga bagay na kabilang sa lahi na kanyang nilalaro. sa laro. Ganito ang hitsura nito sa code:"

class Warrior
{
}
class Archer
{
}
class Mag
{
}

class HumanWarrior extends Warrior
{
}

class HumanArcher extends Archer
{
}

class HumanMag extends Mag
{
}

class ElfWarrior extends Warrior
{
}

class ElfArcher extends Archer
{
}

class ElfMag extends Mag
{
}

class DaemonWarrior extends Warrior
{
}

class DaemonArcher extends Archer
{
}

class DaemonMag extends Mag
{
}

At ngayon, likhain natin ang mga karera, o maaari rin nating tawaging mga hukbo.

abstract class Army
{
 public Warrior createWarrior();
 public Archer createArcher();
 public Mag createMag();
}

class HumanArmy extends Army
{
 public Warrior createWarrior()
 {
  return new HumanWarrior();
 }
 public Archer createArcher()
 {
  return new HumanArcher();
 }
 public Mag createMag()
 {
  return new HumanMag();
 }
}

class ElfArmy extends Army
{
 public Warrior createWarrior()
 {
  return new ElfWarrior();
 }
 public Archer createArcher()
 {
  return new ElfArcher();
 }
 public Mag createMag()
 {
  return new ElfMag();
 }
}

class DaemonArmy extends Army
{
 public Warrior createWarrior()
 {
  return new DaemonWarrior();
 }
 public Archer createArcher()
 {
  return new DaemonArcher();
 }
 public Mag createMag()
 {
  return new DaemonMag();
 }
}

"Ngunit paano mo ito ginagamit?"

"Maaari mong gamitin ang mga klase ng Army, Warrior, Archer, at Mage saanman sa programa, at upang lumikha ng mga kinakailangang bagay - ipasa lamang ang isang bagay ng gustong subclass ng Army."

"Halimbawa:"

Army humans = new HumanArmy();
Army daemons = new DaemonArmy();

Army winner = FightSimulator.simulate(humans, daemons);

"Sa halimbawa sa itaas, mayroon kaming isang klase na ginagaya ang mga labanan sa pagitan ng iba't ibang lahi (hukbo). Kailangan mo lang ipasa ang dalawang object ng Army. Ginagamit mismo ng klase ang mga ito upang lumikha ng iba't ibang tropa at magsagawa ng mga virtual na labanan sa pagitan nila upang makilala ang nanalo. ."

"I see. Thanks. A really interesting approach."

"Isang magandang solusyon, anuman ang sasabihin mo."

"Oo."

"Narito ang isa pang magandang link sa paksa:  Abstract factory pattern "