வடிவமைப்பு வடிவங்கள்: சிங்கிள்டன், தொழிற்சாலை, தொழிற்சாலை முறை, சுருக்க தொழிற்சாலை

"ஹாய், அமிகோ!"

"வணக்கம், பிலாபோ!"

"இன்றைய எங்கள் தலைப்பு சுவாரஸ்யமாக இருக்காது - இது வெளிப்படையான காவியமாக இருக்கும்."

" டிசைன் பேட்டர்ன்கள் என்னவென்று இன்று நான் உங்களிடம் செல்கிறேன் . "

"கூல்! நான் அவர்களைப் பற்றி நிறைய கேள்விப்பட்டிருக்கிறேன். என்னால் காத்திருக்க முடியாது!"

"அனுபவம் வாய்ந்த புரோகிராமர்கள் நிறைய வகுப்புகளை எழுத வேண்டும். ஆனால் இந்த வேலையின் மிகவும் கடினமான பகுதி என்னவென்றால், எந்த வகுப்புகளை உருவாக்குவது மற்றும் அவர்களிடையே வேலையை எவ்வாறு பிரிப்பது என்பதுதான்."

"இதுபோன்ற கேள்விகளை அவர்கள் எவ்வளவு அதிகமாக தீர்க்கிறார்களோ, சில தீர்வுகள் நல்லது, மற்றவை மோசமானவை என்பதை அவர்கள் உணர்ந்தனர்."

"மோசமான தீர்வுகள் பொதுவாக அவை தீர்ப்பதை விட அதிகமான சிக்கல்களை உருவாக்குகின்றன. அவை மோசமாக நீட்டிக்கப்படுகின்றன, பல தேவையற்ற வரம்புகளை உருவாக்குகின்றன, மேலும் நல்ல தீர்வுகள் எதிர்மாறாக இருக்கும்."

"உங்களால் ஏதாவது ஒப்புமை செய்ய முடியுமா?"

"நீங்கள் ஒரு வீட்டைக் கட்டுகிறீர்கள் என்று வைத்துக்கொள்வோம். அது எதைக் கொண்டு உருவாக்கப்படும் என்று நீங்கள் யோசிக்கிறீர்கள். உங்களுக்கு சுவர்கள், ஒரு தளம் மற்றும் கூரை தேவை என்று நீங்கள் முடிவு செய்கிறீர்கள். இதன் விளைவாக, நீங்கள் ஒரு தட்டையான கூரையுடன் ஒரு வீட்டைக் கட்டுகிறீர்கள். அடித்தளம். அத்தகைய வீடு விரிசல் அடையும், கூரை கசியும். இது ஒரு மோசமான தீர்வு."

"மாறாக, அடித்தளம், சுவர்கள் மற்றும் கேபிள் கூரை ஆகியவற்றைக் கொண்ட வீடு ஒரு நல்ல தீர்வாக இருக்கும். கடுமையான பனிப்பொழிவு எந்த பிரச்சனையும் இல்லை, ஏனெனில் பனி கூரையிலிருந்து சரிந்துவிடும். மேலும் மண்ணை மாற்றுவதற்கு பயப்பட ஒன்றுமில்லை, ஏனென்றால் அடித்தளம் உறுதி செய்யும். ஸ்திரத்தன்மை, அத்தகைய தீர்வை நாங்கள் நல்லது என்று அழைப்போம்."

"பார்க்கிறேன். நன்றி."

"சரி. அப்புறம் தொடர்கிறேன்."

"காலப்போக்கில், நல்ல தீர்வுகள் வடிவமைப்பு வடிவங்கள் என்று அறியப்பட்டன, அதே நேரத்தில் மோசமானவை எதிர்ப்பு வடிவங்கள் என்று அழைக்கப்பட்டன."

"டிசைன் பேட்டர்ன் என்பது ஒரு கேள்விக்கான பதில் போன்றது. நீங்கள் கேள்வியைக் கேட்கவில்லை என்றால் புரிந்துகொள்வது கடினம்."

" வடிவங்களின் முதல் வகை படைப்பு வடிவங்கள் ஆகும். இத்தகைய வடிவங்கள் பொருட்களின் உருவாக்கம் தொடர்பான நல்ல தீர்வுகளை விவரிக்கின்றன."

"பொருட்களை உருவாக்குவதில் என்ன சிக்கலானது?"

"அது நடக்கும், அதைத்தான் இப்போது நாம் ஆராயப் போகிறோம்."

சிங்கிள்டன் முறை.

"பெரும்பாலும் நிரல்களில், சில பொருட்களின் ஒற்றை நகல் மட்டுமே இருக்க முடியும். எடுத்துக்காட்டாக, பணியகம், லாகர், குப்பை சேகரிப்பான் போன்றவை."

" மோசமான தீர்வு: எந்தப் பொருட்களையும் உருவாக்க வேண்டாம் - அனைத்து முறைகளும் நிலையானதாக இருக்கும் ஒரு வகுப்பை உருவாக்கவும்."

" நல்ல தீர்வு:  ஒரு பொருளை உருவாக்கி அதை நிலையான மாறியில் சேமிக்கவும். வகுப்பின் இரண்டாவது பொருளை உருவாக்குவதைத் தடுக்கவும். எடுத்துக்காட்டாக:"

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

  return instance;
 }

 private Sun()
 {
 }
}

Sun sun = Sun.getInstance();

"இது எளிமை."

"முதலில், நாங்கள் கன்ஸ்ட்ரக்டரை தனிப்பட்டதாக ஆக்குகிறோம். இப்போது அதை எங்கள் வகுப்பிற்குள் இருந்து மட்டுமே அழைக்க முடியும். சூரிய வகுப்பின் முறைகள் தவிர மற்ற எல்லா இடங்களிலும் சூரிய பொருட்களை உருவாக்குவதை நாங்கள் தடுத்துள்ளோம்."

"இரண்டாவது, இந்த வகுப்பின் ஒரு பொருளை getInstance() முறையை அழைப்பதன் மூலம் மட்டுமே பெற முடியும். இது ஒரு சூரிய பொருளை உருவாக்கக்கூடிய ஒரே முறை மட்டுமல்ல, அத்தகைய ஒரு பொருள் மட்டுமே இருப்பதை உறுதி செய்கிறது."

"நான் பார்க்கிறேன்."

"இப்போது, ​​நான் அதை எப்படி சரியாக செய்வேன்?" என்று நீங்கள் நினைக்கும் போது, ​​"நீங்கள் இதை முயற்சி செய்யலாம் - இது சிறந்த தீர்வுகளில் ஒன்றாகும்" என்று ஒரு முறை கூறுகிறது.

"நன்றி. இப்போது விஷயங்கள் தெளிவாகத் தொடங்குகின்றன."

"இந்த மாதிரியைப் பற்றி நீங்கள் இங்கே படிக்கலாம்  ."

தொழிற்சாலை முறை.

"புரோகிராமர்கள் அடிக்கடி எதிர்கொள்ளும் ஒரு சூழ்நிலை இங்கே உள்ளது. உங்களிடம் சில அடிப்படை வகுப்புகள் மற்றும் பல துணைப்பிரிவுகள் உள்ளன. எடுத்துக்காட்டாக, கேம் கேரக்டர் கிளாஸ் (கேம்பர்சன்) மற்றும் அதை மரபுரிமையாகப் பெறும் மற்ற எல்லா எழுத்துக்களுக்கான வகுப்புகளும்."

"உங்களிடம் பின்வரும் வகுப்புகள் உள்ளன என்று வைத்துக்கொள்வோம்:"

abstract class GamePerson
{
}

class Warrior extends GamePerson
{
}

class Mag extends GamePerson
{
}

class Troll extends GamePerson
{
}

class Elf extends GamePerson
{
}

"இந்த வகுப்புகளின் பொருட்களை உருவாக்குவதை நாம் எவ்வாறு நெகிழ்வாகவும் வசதியாகவும் நிர்வகிப்பது என்பது கேள்வி."

"இந்தப் பிரச்சனை உங்களுக்கு வெகு தொலைவில் இருப்பதாகத் தோன்றினால், விளையாட்டில் நீங்கள் டஜன் கணக்கான வாள்கள் மற்றும் கேடயங்கள், நூற்றுக்கணக்கான மந்திர மந்திரங்கள் மற்றும் ஆயிரக்கணக்கான அரக்கர்களை உருவாக்க வேண்டும் என்று கற்பனை செய்து பாருங்கள். இங்கே பொருள் உருவாக்கத்திற்கு வசதியான அணுகுமுறை இல்லாமல் நீங்கள் செய்ய முடியாது. "

" தொழிற்சாலை முறை ஒரு நல்ல தீர்வை வழங்குகிறது."

"முதலில், பல்வேறு வகுப்புகளுக்கு மதிப்புகள் பொருந்தக்கூடிய ஒரு enum ஐ உருவாக்க வேண்டும்."

"இரண்டாவது, ஒரு enum மதிப்பின் அடிப்படையில் பொருள்(களை) உருவாக்கும் நிலையான முறை(கள்) கொண்ட ஒரு சிறப்பு தொழிற்சாலை வகுப்பை உருவாக்கவும்."

"உதாரணத்திற்கு:"

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);

"வேறு வார்த்தைகளில் கூறுவதானால், பொருள் உருவாக்கத்தை நிர்வகிக்க நாங்கள் ஒரு சிறப்பு வகுப்பை உருவாக்கினோம்?"

"ஆமாம்."

"எனவே இது என்ன நன்மைகளை வழங்குகிறது?"

"முதலில், இந்த வகுப்பில், தேவையான தரவுகளுடன் பொருள்களை துவக்கலாம்."

"இரண்டாவதாக, நீங்கள் விரும்பிய பொருளை உருவாக்குவதற்கு தேவையான enum மதிப்பை நீங்கள் விரும்பும் அளவுக்கு முறைகளுக்கு இடையில் அனுப்பலாம்."

"மூன்றாவதாக, enum புலங்களின் எண்ணிக்கை வகுப்புகளின் எண்ணிக்கையுடன் பொருந்த வேண்டியதில்லை. பல வகையான எழுத்துக்கள் இருக்கலாம், ஆனால் சில வகுப்புகள் இருக்கலாம்."

"உதாரணமாக, ஒரு Mag & Warrior ஒரு வகுப்பை (மனிதனை) பயன்படுத்தலாம், ஆனால் வெவ்வேறு வலிமை மற்றும் மேஜிக் பண்புகளுடன் (கட்டமைப்பாளர் வாதங்கள்)."

"அது எப்படி இருக்கும் என்பது இங்கே உள்ளது (தெளிவுக்காக, நான் டார்க் குட்டிச்சாத்தான்களையும் சேர்த்துள்ளேன்):"

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);

"மேலே உள்ள எடுத்துக்காட்டில், ஆறு வெவ்வேறு வகையான பொருட்களை உருவாக்க, நாங்கள் மூன்று வகுப்புகளைப் பயன்படுத்தினோம். இது மிகவும் வசதியானது. மேலும், இந்த தர்க்கத்தை ஒரு வகுப்பிலும் ஒரு முறையிலும் குவித்துள்ளோம்."

"இப்போது நாங்கள் ஓக்ரேக்கு ஒரு தனி வகுப்பை உருவாக்க முடிவு செய்கிறோம் - நாங்கள் இங்கே இரண்டு குறியீட்டு வரிகளை மாற்றுகிறோம், பயன்பாட்டில் பாதி அல்ல."

"நான் ஒப்புக்கொள்கிறேன், அது ஒரு நல்ல தீர்வு."

"அதைத்தான் நான் பேசுகிறேன்: வடிவமைப்பு வடிவங்கள் நல்ல தீர்வுகளின் தொகுப்புகள்."

"அவற்றை எங்கு பயன்படுத்த வேண்டும் என்பதை நான் அறிந்திருக்க விரும்புகிறேன் ..."

ஆம் _ _

"ஓ நன்றி."

" சுருக்கமான தொழிற்சாலை முறை."

"சில நேரங்களில் உங்களிடம் நிறைய பொருள்கள் இருக்கும்போது, ​​தொழிற்சாலைகளுக்கு ஒரு தொழிற்சாலையை உருவாக்கும் எண்ணம் தன்னைத்தானே அறிவுறுத்துகிறது. அத்தகைய தொழிற்சாலை ஒரு சுருக்க தொழிற்சாலை என்று அழைக்கப்படுகிறது ."

"இது எங்கே தேவைப்படும்?!"

"உங்களிடம் ஒரே மாதிரியான பொருள்களின் பல குழுக்கள் இருப்பதாக வைத்துக் கொள்வோம். இதை உதாரணத்துடன் காண்பிப்பது எளிது."

"இப்போது, ​​உங்கள் விளையாட்டில் மூன்று இனங்கள் உள்ளன: மனிதர்கள், குட்டிச்சாத்தான்கள் மற்றும் பேய்கள் என்று வைத்துக்கொள்வோம். மேலும் சமநிலைக்கு, ஒவ்வொரு இனத்திலும் வீரர்கள், வில்லாளர்கள் மற்றும் மந்திரவாதிகள் உள்ளனர். ஒரு வீரர் அவர் அல்லது அவள் விளையாடும் பந்தயத்திற்குச் சொந்தமான பொருட்களை மட்டுமே உருவாக்க முடியும். விளையாட்டில். இது குறியீட்டில் எப்படி இருக்கும்:"

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
{
}

இப்போது பந்தயங்களை உருவாக்குவோம், அல்லது அவற்றைப் படைகள் என்றும் அழைக்கலாம்.

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();
 }
}

"ஆனால் இதை எப்படிப் பயன்படுத்துகிறீர்கள்?"

"நீங்கள் இராணுவம், வாரியர், ஆர்ச்சர் மற்றும் மேஜ் வகுப்புகளை நிரலில் எங்கு வேண்டுமானாலும் பயன்படுத்தலாம், மேலும் தேவையான பொருட்களை உருவாக்கவும் - விரும்பிய இராணுவ துணைப்பிரிவின் ஒரு பொருளை அனுப்பவும்."

"உதாரணத்திற்கு:"

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

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

"மேலே உள்ள எடுத்துக்காட்டில், வெவ்வேறு இனங்களுக்கு (இராணுவங்களுக்கு) இடையேயான போர்களை உருவகப்படுத்தும் ஒரு வகுப்பு எங்களிடம் உள்ளது. நீங்கள் இரண்டு இராணுவப் பொருட்களைக் கடக்க வேண்டும். வகுப்பே அவற்றைப் பயன்படுத்தி பல்வேறு துருப்புக்களை உருவாக்கி, வெற்றியாளரை அடையாளம் காண அவர்களுக்கு இடையே மெய்நிகர் போர்களை நடத்துகிறது. ."

"நான் பார்க்கிறேன். நன்றி. மிகவும் சுவாரஸ்யமான அணுகுமுறை."

"நீங்கள் என்ன சொன்னாலும் ஒரு நல்ல தீர்வு."

"ஆமாம்."

"தலைப்பில் மற்றொரு நல்ல இணைப்பு இங்கே உள்ளது:  சுருக்கம் தொழிற்சாலை முறை "