फैक्ट्री क्लास के बजाय ऑब्जेक्ट के भीतर फ़ैक्टरी विधियों का उपयोग करना कब अच्छा होता है?
फैक्ट्री क्लास के बजाय ऑब्जेक्ट के भीतर फ़ैक्टरी विधियों का उपयोग करना कब अच्छा होता है?
जवाबों:
मुझे अपनी कक्षाओं के 'लोगों' के संदर्भ में डिजाइन के बारे में सोचना पसंद है, और पैटर्न ऐसे तरीके हैं जिनसे लोग एक-दूसरे से बात करते हैं।
तो, मेरे लिए कारखाना पैटर्न एक भर्ती एजेंसी की तरह है। आपको कोई ऐसा व्यक्ति मिला है जिसे श्रमिकों की एक चर संख्या की आवश्यकता होगी। इस व्यक्ति को कुछ जानकारी पता हो सकती है कि उन्हें उन लोगों की ज़रूरत है जो वे किराए पर लेते हैं, लेकिन ऐसा है।
इसलिए, जब उन्हें एक नए कर्मचारी की आवश्यकता होती है, तो वे काम पर रखने वाली एजेंसी को बुलाते हैं और उन्हें बताते हैं कि उन्हें क्या चाहिए। अब, वास्तव में किसी को किराए पर लेने के लिए , आपको बहुत सारे सामान - लाभ, पात्रता सत्यापन, आदि जानने की आवश्यकता है, लेकिन काम पर रखने वाले व्यक्ति को इनमें से किसी को भी जानने की आवश्यकता नहीं है - भर्ती एजेंसी उस सभी को संभालती है।
उसी तरह, किसी कारखाने का उपयोग करने से उपभोक्ता नई वस्तुओं को बनाने की अनुमति देता है बिना यह जाने कि वे कैसे बनाई गई हैं, या उनकी निर्भरता क्या है - का विवरण उन्हें केवल उन सूचनाओं को देना होगा जो वे वास्तव में चाहते हैं।
public interface IThingFactory
{
Thing GetThing(string theString);
}
public class ThingFactory : IThingFactory
{
public Thing GetThing(string theString)
{
return new Thing(theString, firstDependency, secondDependency);
}
}
इसलिए, अब उपभोक्ता से आने वाले स्ट्रिंग डेटा को छोड़कर, ThingFactory के उपभोक्ता को एक Thing मिल सकता है, जो Thing की निर्भरता के बारे में नहीं जानता है।
within an object instead of a Factory class
। मुझे लगता है कि उनका अभिप्राय उस परिदृश्य से है जहां आप ctor को निजी बनाते हैं और क्लास को तुरंत (ऑब्जेक्ट बनाने के लिए) स्टैटिक विधि का उपयोग करते हैं। लेकिन इस उदाहरण का पालन ThingFactory
करने के लिए Thing
, वस्तुओं को प्राप्त करने के लिए पहले वर्ग को तुरंत रोकना चाहिए , जिससे यह Factory class
प्रभाव में आता है।
कारखाने के तरीकों को निर्माणकर्ताओं के विकल्प के रूप में माना जाना चाहिए - ज्यादातर जब निर्माणकर्ता पर्याप्त अर्थपूर्ण नहीं होते हैं, अर्थात।
class Foo{
public Foo(bool withBar);
}
उतना स्पष्ट नहीं है:
class Foo{
public static Foo withBar();
public static Foo withoutBar();
}
जब आप ऑब्जेक्ट के निर्माण के लिए जटिल प्रक्रिया की आवश्यकता होती है, जब निर्माण को एक निर्भरता की आवश्यकता होती है, जो आपको वास्तविक वर्ग के लिए नहीं चाहिए, जब आपको विभिन्न वस्तुओं आदि के निर्माण की आवश्यकता होती है, तब फैक्ट्री कक्षाएं उपयोगी होती हैं।
एक स्थिति जहां मैं व्यक्तिगत रूप से अलग-अलग फैक्ट्री कक्षाएं ढूंढता हूं, यह समझ में आता है कि अंतिम वस्तु आप कई अन्य वस्तुओं पर निर्भर बनाने की कोशिश कर रहे हैं। जैसे, PHP में: मान लीजिए कि आपके पास एक House
ऑब्जेक्ट है, जिसके बदले में Kitchen
एक LivingRoom
ऑब्जेक्ट है, और ऑब्जेक्ट के अंदर LivingRoom
भी एक TV
ऑब्जेक्ट है।
इसे प्राप्त करने की सबसे सरल विधि प्रत्येक वस्तु को उनके निर्माण की विधि पर अपने बच्चों को पैदा करने में है, लेकिन अगर गुण अपेक्षाकृत घोंसले के शिकार हैं, जब आपकी House
असफलता आपको पैदा करने में कुछ समय बिताएगी, जो असफल हो रहा है, ठीक करने के लिए कुछ समय बिताना होगा।
विकल्प निम्नलिखित है (निर्भरता इंजेक्शन, यदि आपको फैंसी शब्द पसंद है):
$TVObj = new TV($param1, $param2, $param3);
$LivingroomObj = new LivingRoom($TVObj, $param1, $param2);
$KitchenroomObj = new Kitchen($param1, $param2);
$HouseObj = new House($LivingroomObj, $KitchenroomObj);
यहाँ अगर House
असफलता पैदा करने की प्रक्रिया केवल देखने के लिए एक ही जगह है, लेकिन हर बार जब कोई नया चाहता है, तो इस ठग का उपयोग करना House
सुविधाजनक होता है। कारखानों में प्रवेश करें:
class HouseFactory {
public function create() {
$TVObj = new TV($param1, $param2, $param3);
$LivingroomObj = new LivingRoom($TVObj, $param1, $param2);
$KitchenroomObj = new Kitchen($param1, $param2);
$HouseObj = new House($LivingroomObj, $KitchenroomObj);
return $HouseObj;
}
}
$houseFactory = new HouseFactory();
$HouseObj = $houseFactory->create();
यहाँ कारखाने के लिए धन्यवाद एक बनाने की प्रक्रिया House
अमूर्त है (इसमें आपको हर एक निर्भरता को बनाने और सेट करने की आवश्यकता नहीं है जब आप बस बनाना चाहते हैं House
) और उसी समय केंद्रीकृत होता है जो इसे बनाए रखना आसान बनाता है। अलग-अलग फैक्ट्रियों का उपयोग करने के अन्य कारण फायदेमंद हो सकते हैं (उदाहरण के लिए टेस्टीबिलिटी) लेकिन मुझे लगता है कि फैक्ट्री कक्षाएं कैसे उपयोगी हो सकती हैं, यह बताने के लिए यह विशिष्ट उपयोग मामला है।
HouseFactory
कक्षा में कैसे पारित किया जाता है ?
create
विधि से पारित करने की आवश्यकता नहीं है । उदाहरण के लिए, यदि आपका House
हमेशा एक ही तरह का है, LivingRoom
तो यह तर्क के रूप में पारित होने के बजाय फैक्ट्री क्लास में हार्ड डिस्क को अपने पैराशूट के लिए समझ में आता है। यदि आप कुछ प्रकार के हैं और प्रत्येक प्रकार के हार्डकोडेड मापदंडों के साथ अंदर स्विच करते हैं, तो आप type
अपनी HouseFactory::create
पद्धति को एक तर्क प्रदान करना चाह सकते हैं LivingRoom
।
फैक्ट्री या फैक्ट्री पद्धति का उपयोग करने के पीछे के विचार को स्पष्ट रूप से अलग करना महत्वपूर्ण है। दोनों ही परस्पर भिन्न प्रकार की वस्तु निर्माण समस्याओं के समाधान के लिए हैं।
चलो "कारखाना विधि" के बारे में विशिष्ट हैं:
पहली बात यह है कि, जब आप पुस्तकालय या एपीआई विकसित कर रहे होते हैं, जिसका उपयोग आगे के विकास के लिए किया जाता है, तो कारखाना पद्धति निर्माण पैटर्न के लिए सबसे अच्छे चयनों में से एक है। पीछे कारण; हम जानते हैं कि जब आवश्यक कार्यक्षमता (ऑब्जेक्ट्स) का निर्माण करना है, लेकिन ऑब्जेक्ट का प्रकार अनिर्धारित रहेगा या यह तय किया जाएगा कि पास किए गए डायनामिक पैरामीटर क्या हैं ।
अब बिंदु यह है कि लगभग एक ही कारखाने के पैटर्न का उपयोग करके प्राप्त किया जा सकता है, लेकिन एक बहुत बड़ी खामी इस प्रणाली में लागू होगी यदि फैक्टरी पैटर्न का उपयोग ऊपर हाइलाइट की गई समस्या के लिए किया जाएगा, तो यह है कि विभिन्न वस्तुओं (सब क्लास ऑब्जेक्ट्स) को बनाने का आपका तर्क होगा भविष्य में कुछ व्यावसायिक स्थितियों के लिए विशिष्ट होना चाहिए जब आपको अपनी लाइब्रेरी की कार्यक्षमता को अन्य प्लेटफार्मों के लिए विस्तारित करने की आवश्यकता होती है (अधिक तकनीकी रूप से, आपको बुनियादी इंटरफ़ेस या अमूर्त वर्ग के अधिक उप वर्गों को जोड़ने की आवश्यकता है ताकि कारखाना उन वस्तुओं को वापस कर सके जो मौजूदा एक के अलावा भी हैं। कुछ गतिशील मापदंडों के आधार पर) तो हर बार आपको फैक्ट्री वर्ग के तर्क को बदलना (विस्तार) करना होगा जो महंगा ऑपरेशन होगा और डिजाइन के नजरिए से अच्छा नहीं होगा। दूसरी तरफ, अगर "कारखाना विधि"
interface Deliverable
{
/*********/
}
abstract class DefaultProducer
{
public void taskToBeDone()
{
Deliverable deliverable = factoryMethodPattern();
}
protected abstract Deliverable factoryMethodPattern();
}
class SpecificDeliverable implements Deliverable
{
/***SPECIFIC TASK CAN BE WRITTEN HERE***/
}
class SpecificProducer extends DefaultProducer
{
protected Deliverable factoryMethodPattern()
{
return new SpecificDeliverable();
}
}
public class MasterApplicationProgram
{
public static void main(String arg[])
{
DefaultProducer defaultProducer = new SpecificProducer();
defaultProducer.taskToBeDone();
}
}
जब वस्तु के अंदर कारखाने के तरीकों का उपयोग करना अच्छा होता है:
अमूर्त कारखाना वर्ग का उपयोग करना कब अच्छा है:
से यू.एम.एल.
उत्पाद: यह उन वस्तुओं के एक इंटरफ़ेस को परिभाषित करता है जो फैक्टरी विधि बनाती है।
कंक्रीटप्रोडक्ट: इम्प्लीमेंट्स उत्पाद इंटरफ़ेस
निर्माता: फैक्टरी विधि की घोषणा करता है
ConcreateCreator: एक कंक्रीटप्रोडक्ट की आवृत्ति वापस करने के लिए फ़ैक्टरी विधि लागू करता है
समस्या कथन: फ़ैक्टरी विधियों का उपयोग करके खेलों का एक कारखाना बनाएँ, जो खेल इंटरफ़ेस को परिभाषित करता है।
सांकेतिक टुकड़ा:
import java.util.HashMap;
/* Product interface as per UML diagram */
interface Game{
/* createGame is a complex method, which executes a sequence of game steps */
public void createGame();
}
/* ConcreteProduct implementation as per UML diagram */
class Chess implements Game{
public Chess(){
}
public void createGame(){
System.out.println("---------------------------------------");
System.out.println("Create Chess game");
System.out.println("Opponents:2");
System.out.println("Define 64 blocks");
System.out.println("Place 16 pieces for White opponent");
System.out.println("Place 16 pieces for Black opponent");
System.out.println("Start Chess game");
System.out.println("---------------------------------------");
}
}
class Checkers implements Game{
public Checkers(){
}
public void createGame(){
System.out.println("---------------------------------------");
System.out.println("Create Checkers game");
System.out.println("Opponents:2 or 3 or 4 or 6");
System.out.println("For each opponent, place 10 coins");
System.out.println("Start Checkers game");
System.out.println("---------------------------------------");
}
}
class Ludo implements Game{
public Ludo(){
}
public void createGame(){
System.out.println("---------------------------------------");
System.out.println("Create Ludo game");
System.out.println("Opponents:2 or 3 or 4");
System.out.println("For each opponent, place 4 coins");
System.out.println("Create two dices with numbers from 1-6");
System.out.println("Start Ludo game");
System.out.println("---------------------------------------");
}
}
/* Creator interface as per UML diagram */
interface IGameFactory {
public Game getGame(String gameName);
}
/* ConcreteCreator implementation as per UML diagram */
class GameFactory implements IGameFactory {
HashMap<String,Game> games = new HashMap<String,Game>();
/*
Since Game Creation is complex process, we don't want to create game using new operator every time.
Instead we create Game only once and store it in Factory. When client request a specific game,
Game object is returned from Factory instead of creating new Game on the fly, which is time consuming
*/
public GameFactory(){
games.put(Chess.class.getName(),new Chess());
games.put(Checkers.class.getName(),new Checkers());
games.put(Ludo.class.getName(),new Ludo());
}
public Game getGame(String gameName){
return games.get(gameName);
}
}
public class NonStaticFactoryDemo{
public static void main(String args[]){
if ( args.length < 1){
System.out.println("Usage: java FactoryDemo gameName");
return;
}
GameFactory factory = new GameFactory();
Game game = factory.getGame(args[0]);
if ( game != null ){
game.createGame();
System.out.println("Game="+game.getClass().getName());
}else{
System.out.println(args[0]+ " Game does not exists in factory");
}
}
}
उत्पादन:
java NonStaticFactoryDemo Chess
---------------------------------------
Create Chess game
Opponents:2
Define 64 blocks
Place 16 pieces for White opponent
Place 16 pieces for Black opponent
Start Chess game
---------------------------------------
Game=Chess
यह उदाहरण एक Factory
वर्ग को लागू करके दिखाता है FactoryMethod
।
Game
सभी प्रकार के खेलों के लिए इंटरफ़ेस है। यह जटिल विधि को परिभाषित करता है:createGame()
Chess, Ludo, Checkers
खेलों के विभिन्न प्रकार हैं, जो कार्यान्वयन प्रदान करते हैं createGame()
public Game getGame(String gameName)
है FactoryMethod
में IGameFactory
वर्ग
GameFactory
कंस्ट्रक्टर में विभिन्न प्रकार के खेल पूर्व-निर्मित होते हैं। यह IGameFactory
कारखाना विधि को लागू करता है ।
गेम का नाम कमांड लाइन तर्क के रूप में दिया गया है NotStaticFactoryDemo
getGame
में GameFactory
एक खेल का नाम है और इसी रिटर्न स्वीकार करता है Game
वस्तु।
फैक्टरी:
क्लाइंट के लिए तात्कालिकता तर्क को उजागर किए बिना ऑब्जेक्ट बनाता है।
FactoryMethod
एक ऑब्जेक्ट बनाने के लिए एक इंटरफ़ेस को परिभाषित करें, लेकिन उपवर्गों को यह तय करने दें कि किस वर्ग को त्वरित करना है। फैक्ट्री पद्धति उपवर्गों को एक क्लास डिफरेंट इंस्टालेशन की सुविधा देती है
उदाहरण:
उपयोग कब करें: Client
रनटाइम के दौरान कौन सी ठोस कक्षाएं बनाने की आवश्यकता होगी, यह नहीं पता, लेकिन बस एक वर्ग प्राप्त करना चाहता है जो काम करेगा।
getArea()
एक कारखाने की विधि बिल्कुल नहीं है ।
यह वास्तव में स्वाद की बात है। कारखाने की कक्षाओं को आवश्यक रूप से अलग किया जा सकता है / बाधित किया जा सकता है, जबकि कारखाने के तरीके हल्के वजन के होते हैं (और परीक्षण योग्य भी होते हैं, क्योंकि उनके पास परिभाषित प्रकार नहीं होता है, लेकिन उन्हें एक सेवा के लिए एक प्रसिद्ध पंजीकरण बिंदु की आवश्यकता होती है। लोकेटर लेकिन कारखाने के तरीकों का पता लगाने के लिए)।
फैक्ट्री कक्षाएं तब उपयोगी होती हैं जब ऑब्जेक्ट प्रकार जो वे वापस करते हैं, एक निजी कंस्ट्रक्टर होता है, जब अलग-अलग फैक्ट्री कक्षाएं रिटर्निंग ऑब्जेक्ट पर अलग-अलग गुण सेट करती हैं, या जब एक विशिष्ट फैक्ट्री प्रकार अपने रिटर्निंग कंक्रीट प्रकार के साथ युग्मित होता है।
WCF विभिन्न स्थितियों में ServiceHost ऑब्जेक्ट्स को पुनः प्राप्त करने के लिए ServiceHostFactory कक्षाओं का उपयोग करता है। मानक ServiceHostFactory के लिए ServiceHost उदाहरणों को पुनः प्राप्त करने का उपयोग IIS .svc फ़ाइलें, लेकिन एक WebScriptServiceHostFactory सेवाओं के लिए प्रयोग किया जाता है कि जावास्क्रिप्ट ग्राहकों को वापसी serializations। ADO.NET Data Services का अपना एक विशेष DataServiceHostFactory है और ASP.NET का अपना ApplicationServicesHostFactory है क्योंकि इसकी सेवाओं में निजी कंस्ट्रक्टर हैं।
यदि आपके पास केवल एक वर्ग है जो कारखाने का उपभोग कर रहा है, तो आप बस उस वर्ग के भीतर एक कारखाना विधि का उपयोग कर सकते हैं।
एक परिदृश्य पर विचार करें जब आपको ऑर्डर और ग्राहक वर्ग डिज़ाइन करना होगा। सादगी और प्रारंभिक आवश्यकताओं के लिए आपको ऑर्डर क्लास के लिए कारखाने की आवश्यकता महसूस नहीं होती है और अपने आवेदन को कई 'नए ऑर्डर ()' कथनों से भरना होता है। चीजें अच्छी तरह से काम कर रही हैं।
अब एक नई आवश्यकता चित्र में आती है कि ऑर्डर ऑब्जेक्ट को ग्राहक संघ (नई निर्भरता) के बिना तत्काल नहीं किया जा सकता है। अब आपके पास निम्नलिखित विचार हैं।
1- आप कंस्ट्रक्टर ओवरलोड बनाते हैं जो केवल नए कार्यान्वयन के लिए काम करेगा। (स्वीकार्य नहीं है)। 2- आप ऑर्डर () हस्ताक्षरों को बदलते हैं और प्रत्येक और प्रत्येक इनवोकेशन को बदलते हैं। (एक अच्छा अभ्यास और वास्तविक दर्द नहीं)।
इसके बजाय यदि आपने ऑर्डर क्लास के लिए एक कारखाना बनाया है तो आपको केवल एक लाइन कोड को बदलना होगा और आप जाने के लिए अच्छे हैं। मेरा सुझाव है कि लगभग हर कुल संघ के लिए कारखाना वर्ग। उम्मीद है की वो मदद करदे।
यदि आप उपयोग करने के संदर्भ में एक अलग वस्तु बनाना चाहते हैं। यह उपयोगी है।
public class factoryMethodPattern {
static String planName = "COMMERCIALPLAN";
static int units = 3;
public static void main(String args[]) {
GetPlanFactory planFactory = new GetPlanFactory();
Plan p = planFactory.getPlan(planName);
System.out.print("Bill amount for " + planName + " of " + units
+ " units is: ");
p.getRate();
p.calculateBill(units);
}
}
abstract class Plan {
protected double rate;
abstract void getRate();
public void calculateBill(int units) {
System.out.println(units * rate);
}
}
class DomesticPlan extends Plan {
// @override
public void getRate() {
rate = 3.50;
}
}
class CommercialPlan extends Plan {
// @override
public void getRate() {
rate = 7.50;
}
}
class InstitutionalPlan extends Plan {
// @override
public void getRate() {
rate = 5.50;
}
}
class GetPlanFactory {
// use getPlan method to get object of type Plan
public Plan getPlan(String planType) {
if (planType == null) {
return null;
}
if (planType.equalsIgnoreCase("DOMESTICPLAN")) {
return new DomesticPlan();
} else if (planType.equalsIgnoreCase("COMMERCIALPLAN")) {
return new CommercialPlan();
} else if (planType.equalsIgnoreCase("INSTITUTIONALPLAN")) {
return new InstitutionalPlan();
}
return null;
}
}
किसी भी वर्ग को जिस वस्तु के साथ काम करने की आवश्यकता होती है, उसके लिए अपने उप-वर्ग को ऑब्जेक्ट निर्माण को संदर्भित करते हुए फैक्टरी पैटर्न के उदाहरण के रूप में देखा जा सकता है।
मैंने https://stackoverflow.com/a/49110001/504133 पर एक अन्य उत्तर में विस्तार से उल्लेख किया है
मुझे लगता है कि यह ढीली युग्मन डिग्री पर निर्भर करेगा जिसे आप अपने कोड में लाना चाहते हैं।
फैक्टरी विधि बहुत अच्छी तरह से चीजों को डिकॉय करती है लेकिन फैक्ट्री क्लास नं।
दूसरे शब्दों में, यदि आप कारखाने की विधि का उपयोग करते हैं तो इसकी तुलना में चीजों को बदलना आसान है यदि आप एक साधारण कारखाने (जिसे कारखाना वर्ग के रूप में जाना जाता है) का उपयोग करते हैं।
इस उदाहरण में देखें: https://connected2know.com/programming/java-factory-pattern/ । अब, कल्पना करें कि आप एक नया पशु लाना चाहते हैं। फैक्ट्री क्लास में आपको फैक्ट्री बदलने की आवश्यकता होती है, लेकिन फैक्ट्री विधि में, नहीं, आपको केवल एक नया उपवर्ग जोड़ने की जरूरत है।
फ़ैक्टरी कक्षाएं अधिक भारी होती हैं, लेकिन आपको कुछ फायदे देती हैं। ऐसे मामलों में जब आपको कई, कच्चे डेटा स्रोतों से अपनी वस्तुओं का निर्माण करने की आवश्यकता होती है, तो वे आपको एक ही स्थान पर केवल बिल्डिंग लॉजिक (और शायद डेटा का एकत्रीकरण) को एनकैप्सुलेट करने की अनुमति देते हैं। वहां इसे ऑब्जेक्ट इंटरफ़ेस से संबंधित किए बिना अमूर्त में परीक्षण किया जा सकता है।
मुझे यह एक उपयोगी पैटर्न मिला है, खासकर जहां मैं ओआरएम को बदलने और अपर्याप्त करने में असमर्थ हूं और डीबी टेबल जॉइन या स्टोर की गई प्रक्रियाओं से कई वस्तुओं को कुशलता से निकालना चाहता हूं।
मैं कारखानों को पुस्तकालयों की अवधारणा के लिए पसंद करता हूं। उदाहरण के लिए आपके पास संख्याओं के साथ काम करने के लिए एक पुस्तकालय और आकृतियों के साथ काम करने के लिए दूसरा हो सकता है। आप इन पुस्तकालयों के कार्यों को तार्किक रूप से नामित निर्देशिकाओं में Numbers
या के रूप में संग्रहीत कर सकते हैं Shapes
। ये सामान्य प्रकार हैं जो आकृतियों के मामले में पूर्णांक, फ़्लोट, डब्यूल्स, लॉन्ग या आयताकार, सर्कल, त्रिकोण, पेंटागन शामिल कर सकते हैं।
फैक्ट्री पेटर पॉलीमोर्फिज़्म, निर्भरता इंजेक्शन और नियंत्रण के व्युत्क्रम का उपयोग करता है।
फैक्ट्री पैटर्न का घोषित उद्देश्य है: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
तो मान लीजिए कि आप एक ऑपरेटिंग सिस्टम या फ्रेमवर्क बना रहे हैं और आप सभी असतत घटकों का निर्माण कर रहे हैं।
यहाँ PHP में फ़ैक्टरी पैटर्न की अवधारणा का एक सरल उदाहरण है। मैं इस सब पर 100% नहीं हो सकता लेकिन यह एक सरल उदाहरण के रूप में सेवा करने का इरादा है। मैं एक विशेषज्ञ नहीं हूं।
class NumbersFactory {
public static function makeNumber( $type, $number ) {
$numObject = null;
$number = null;
switch( $type ) {
case 'float':
$numObject = new Float( $number );
break;
case 'integer':
$numObject = new Integer( $number );
break;
case 'short':
$numObject = new Short( $number );
break;
case 'double':
$numObject = new Double( $number );
break;
case 'long':
$numObject = new Long( $number );
break;
default:
$numObject = new Integer( $number );
break;
}
return $numObject;
}
}
/* Numbers interface */
abstract class Number {
protected $number;
public function __construct( $number ) {
$this->number = $number;
}
abstract public function add();
abstract public function subtract();
abstract public function multiply();
abstract public function divide();
}
/* Float Implementation */
class Float extends Number {
public function add() {
// implementation goes here
}
public function subtract() {
// implementation goes here
}
public function multiply() {
// implementation goes here
}
public function divide() {
// implementation goes here
}
}
/* Integer Implementation */
class Integer extends Number {
public function add() {
// implementation goes here
}
public function subtract() {
// implementation goes here
}
public function multiply() {
// implementation goes here
}
public function divide() {
// implementation goes here
}
}
/* Short Implementation */
class Short extends Number {
public function add() {
// implementation goes here
}
public function subtract() {
// implementation goes here
}
public function multiply() {
// implementation goes here
}
public function divide() {
// implementation goes here
}
}
/* Double Implementation */
class Double extends Number {
public function add() {
// implementation goes here
}
public function subtract() {
// implementation goes here
}
public function multiply() {
// implementation goes here
}
public function divide() {
// implementation goes here
}
}
/* Long Implementation */
class Long extends Number {
public function add() {
// implementation goes here
}
public function subtract() {
// implementation goes here
}
public function multiply() {
// implementation goes here
}
public function divide() {
// implementation goes here
}
}
$number = NumbersFactory::makeNumber( 'float', 12.5 );
NumbersFactory::makeNumber( 'float', 12.5 );
कह new Float(12.5);
रहा हूं Float
? यह वही है जो मैं कारखानों के बारे में नहीं समझता ... क्या बात है?