Abstract Factory Pattern

Abstract Factory Pattern هو نمط تصميم إبداعي يستخدم لإنشاء عائلات من الكائنات ذات الصلة دون تعريض concrete classes لكود التطبيق الرئيسي. يكون ذلك مفيدًا عندما يحتاج التطبيق إلى إنشاء كائنات متعددة تنتمي معًا ويجب أن تعمل كمجموعة متسقة.

يُستخدم هذا النمط بشكل شائع في أنظمة البرامج التي تدعم العديد من السمات أو الأنظمة الأساسية أو برامج تشغيل قواعد البيانات أو مكونات واجهة المستخدم أو موفري الدفع أو مصدري الملفات أو عائلات الخدمة. بدلاً من إنشاء كل كائن على حدة، يوفر Abstract Factory Pattern واجهة factory تنشئ كائنات مرتبطة من خلال عقد مشترك.

مقدمة

في المقالة السابقة من سلسلة Design Patterns، ناقشنا Factory Pattern. يساعد Factory Pattern في إنشاء نوع واحد من الكائنات بناءً على الإدخال أو التكوين أو قواعد العمل. فهو يركز على إنشاء الكائنات ويحافظ على نظافة منطق الأعمال.

يذهب Abstract Factory Pattern خطوة أخرى إلى الأمام. بدلاً من إنشاء كائن واحد فقط، فإنه يقوم بإنشاء مجموعة أو عائلة من الكائنات المرتبطة. عادةً ما يتم تصميم هذه الكائنات للعمل معًا وتتبع نفس النمط أو الموفر أو النظام الأساسي أو البيئة.

على سبيل المثال، قد يحتاج نظام واجهة المستخدم إلى إنشاء أزرار ومربعات اختيار وحقول إدخال. إذا كان التطبيق يدعم كلاً من المظهر الفاتح والمظهر الداكن، فيجب أن يوفر كل سمة المكونات المطابقة الخاصة به. يساعد Abstract Factory في إنشاء جميع المكونات ذات الصلة من نفس العائلة.

ما هو Abstract Factory Pattern؟

Abstract Factory Pattern هو نمط تصميم يحدد واجهة لإنشاء عائلات من الكائنات ذات الصلة دون تحديد concrete classes بالضبط.

بعبارات بسيطة، يسمح للتطبيق بطلب مجموعة من الكائنات من المصنع، بينما يقرر المصنع أي concrete classes يجب استخدامه.

لا يحتاج كود التطبيق الرئيسي إلى معرفة ما إذا كان يستخدم سمة فاتحة أو سمة داكنة أو برنامج تشغيل MySQL أو برنامج تشغيل PostgreSQL أو موفر Stripe أو موفر PayPal. يعتمد ذلك فقط على الملخص interfaces.

الفكرة الرئيسية للمصنع الملخص

الفكرة الرئيسية لـ Abstract Factory هي class إنشاء الكائنات ذات الصلة عن الكود الذي يستخدمها. يتضمن النمط عادةً ما يلي:

• factory interface مجردة تحدد طرق إنشاء الكائنات ذات الصلة.

• فئات مصنع concrete التي تنفذ واجهة المصنع المجردة.

• المنتج interfaces الذي يحدد سلوك الكائنات التي تم إنشاؤها.

• فئات المنتجات الconcrete التي تنتمي إلى عائلات محددة.

• رمز العميل الذي يستخدم المصنع والمنتج فقط interfaces.

تجعل هذه البنية النظام مرنًا لأن التطبيق يمكنه التبديل بين عائلات الكائنات دون تغيير منطق العمل الرئيسي.

لماذا يعد المصنع الملخص مهمًا

يعد Abstract Factory مهمًا لأن العديد من التطبيقات تحتاج إلى العمل مع الكائنات ذات الصلة التي يجب أن تظل متسقة. إذا تم إنشاء هذه الكائنات يدويًا في أماكن مختلفة، يصبح من السهل خلط classes غير المتوافقة.

على سبيل المثال، يجب ألا يقوم التطبيق الذي يدعم سمات واجهة المستخدم المتعددة بإنشاء زر سمة فاتحة مع مربع اختيار سمة داكنة عن طريق الخطأ. يجب ألا يخلط نظام إعداد التقارير بين مكونات الرأس الخاصة بـ PDF ومكونات النص الخاصة بـ Excel. يجب ألا يخلط نظام الدفع بين كائنات الدفع Stripe وكائنات استرداد PayPal.

يمنع Abstract Factory هذا النوع من عدم الاتساق عن طريق إنشاء كائنات ذات صلة من نفس عائلة المصنع.

مشكلة بدون مصنع مجردة

تخيل تطبيقًا يدعم موضوعين للتصميم: الضوء والظلام. يحتاج التطبيق إلى إنشاء أزرار وحقول إدخال لكل موضوع.

بدون Abstract Factory، قد يحتوي الكود على شروط مثل هذه:

if ($theme === 'light') {
    $button = new LightButton();
    $input = new LightInput();
} elseif ($theme === 'dark') {
    $button = new DarkButton();
    $input = new DarkInput();
}

قد ينجح هذا في مثال صغير، لكن المشكلة تتفاقم عندما يحتوي التطبيق على العديد من المكونات. إذا أضاف النظام لاحقًا بطاقات ونماذج وقوائم وتنبيهات وجداول، فسيصبح المنطق الشرطي أكبر ويصعب الحفاظ عليه.

يقوم Abstract Factory بنقل منطق الإنشاء هذا إلى فئات المصنع المخصصة ويحافظ على نظافة كود العميل.

هيكل المصنع الملخص

يحتوي هيكل Abstract Factory النموذجي على عدة أجزاء. أولاً، يحدد المنتج interfaces السلوك الشائع لكل نوع من أنواع المنتجات. بعد ذلك، تقوم المنتجات الخرسانية بتنفيذ هذه interfaces. بعد ذلك، تحدد واجهة المصنع المجردة طرق إنشاء مجموعات المنتجات. وأخيرًا، تقوم مصانع concrete بإنشاء منتجات مطابقة.

قد يبدو هذا معقدًا في البداية، لكن الفكرة بسيطة: يقوم مصنع واحد بإنشاء عائلة متسقة من الكائنات ذات الصلة.

مثال مصنع مجردة في PHP

يوضح المثال التالي تطبيق Abstract Factory لنظام واجهة مستخدم قائم على السمات.

interface Button
{
    public function render(): string;
}

interface Input
{
    public function render(): string;
}

class LightButton implements Button
{
    public function render(): string
    {
        return 'Rendering light button';
    }
}

class LightInput implements Input
{
    public function render(): string
    {
        return 'Rendering light input';
    }
}

class DarkButton implements Button
{
    public function render(): string
    {
        return 'Rendering dark button';
    }
}

class DarkInput implements Input
{
    public function render(): string
    {
        return 'Rendering dark input';
    }
}

في هذا المثال، الزر والإدخال هما المنتج interfaces. LightButton، وLightInput، وDarkButton، وDarkInput هي منتجات concrete.

إنشاء واجهة المصنع abstractionي

يمكننا الآن تحديد factory interface مجردة تقوم بإنشاء مكونات واجهة المستخدم ذات الصلة:

interface UiFactory
{
    public function createButton(): Button;

    public function createInput(): Input;
}

هذه interface لا تعرف شيئًا عن السمات الفاتحة أو الداكنة. إنه يحدد فقط أن أي مصنع لواجهة المستخدم يجب أن يكون قادرًا على إنشاء زر وإدخال.

إنشاء مصانع concrete

بعد ذلك نقوم بإنشاء مصانع خرسانة لكل موضوع:

class LightThemeFactory implements UiFactory
{
    public function createButton(): Button
    {
        return new LightButton();
    }

    public function createInput(): Input
    {
        return new LightInput();
    }
}

class DarkThemeFactory implements UiFactory
{
    public function createButton(): Button
    {
        return new DarkButton();
    }

    public function createInput(): Input
    {
        return new DarkInput();
    }
}

يقوم كل مصنع بإنشاء مجموعة متسقة من الكائنات. يقوم LightThemeFactory بإنشاء مكونات فاتحة فقط، بينما يقوم DarkThemeFactory بإنشاء مكونات داكنة فقط.

باستخدام مصنع مجردة

يمكن لرمز العميل الآن استخدام واجهة UiFactory دون الاعتماد على concrete classes:

class PageRenderer
{
    public function __construct(
        private UiFactory $factory
    ) {
    }

    public function render(): string
    {
        $button = $this->factory->createButton();
        $input = $this->factory->createInput();

        return $button->render() . PHP_EOL . $input->render();
    }
}

$factory = new DarkThemeFactory();
$page = new PageRenderer($factory);

echo $page->render();

لا تعرف فئة PageRenderer ما إذا كان المصنع يقوم بإنشاء مكونات فاتحة أم مكونات داكنة. يعتمد الأمر فقط على واجهة UiFactory.

وهذا يجعل التصميم مرنًا وسهل التوسع.

تبديل عائلات الكائنات

إحدى أكبر فوائد Abstract Factory هي أن التطبيق يمكنه تبديل مجموعة الكائنات بأكملها عن طريق تغيير المصنع.

على سبيل المثال:

$theme = 'light';

$factory = match ($theme) {
    'light' => new LightThemeFactory(),
    'dark' => new DarkThemeFactory(),
    default => throw new InvalidArgumentException('Invalid theme.'),
};

$page = new PageRenderer($factory);

إذا تغير الموضوع، يستخدم التطبيق مصنعًا مختلفًا. ويظل باقي منطق PageRenderer دون تغيير.

مصنع مجردة مقابل Factory Pattern

إن Factory Pattern وAbstract Factory Pattern مرتبطان، لكنهما يحلان مشاكل تصميم مختلفة.

يقوم Factory Pattern عادةً بإنشاء نوع واحد من الكائنات. على سبيل المثال، قد يقوم PaymentFactory بإنشاء كائن CreditCardPayment أو PayPalPayment أو BankTransferPayment.

يقوم Abstract Factory Pattern بإنشاء عائلات من الكائنات ذات الصلة. على سبيل المثال، قد يقوم ThemeFactory بإنشاء زر وإدخال ومشروط ومربع اختيار تنتمي جميعها إلى نفس السمة.

باختصار، يركز Factory على إنشاء منتج واحد، بينما يركز Abstract Factory على إنشاء عائلات المنتجات ذات الصلة.

الاختلافات الرئيسية بين المصنع والمصنع المجرد

الاختلافات الرئيسية هي:

• Factory Pattern: إنشاء كائن واحد من مجموعة classes المحتملة.

• Abstract Factory Pattern: يقوم بإنشاء كائنات متعددة ذات صلة تنتمي إلى نفس العائلة.

• Factory Pattern: عادة ما يكون له طريقة إنشاء واحدة.

• Abstract Factory Pattern: عادة ما يكون له طرق إنشاء متعددة.

• Factory Pattern: مفيد لاختيار تنفيذ واحد.

• Abstract Factory Pattern: مفيد للحفاظ على اتساق عمليات التنفيذ ذات الصلة.

يعمل كلا النمطين على تحسين إنشاء الكائنات، لكن Abstract Factory يكون أكثر ملاءمة عندما يجب إنشاء الكائنات معًا كمجموعة متوافقة.

مثال من العالم الحقيقي: عائلة برامج تشغيل قاعدة البيانات

مثال عملي آخر هو نظام قاعدة البيانات الذي يدعم محركات قواعد البيانات المختلفة. قد تتضمن عائلة MySQL كائن اتصال، وconstructor الاستعلام، ومدير المخطط. قد توفر عائلة PostgreSQL تطبيقات مختلفة لنفس المفاهيم.

يمكن لـ Abstract Factory التأكد من أن جميع الكائنات المرتبطة بقاعدة البيانات تأتي من نفس عائلة قاعدة البيانات.

interface Connection
{
    public function connect(): string;
}

interface QueryBuilder
{
    public function select(string $table): string;
}

interface DatabaseFactory
{
    public function createConnection(): Connection;

    public function createQueryBuilder(): QueryBuilder;
}

يمكن لكل مصنع قاعدة بيانات concrete إنشاء كائنات مطابقة لمحرك قاعدة البيانات الخاص به.

تنفيذ مصنع قاعدة البيانات

class MySqlConnection implements Connection
{
    public function connect(): string
    {
        return 'Connecting to MySQL';
    }
}

class MySqlQueryBuilder implements QueryBuilder
{
    public function select(string $table): string
    {
        return 'SELECT * FROM `' . $table . '`';
    }
}

class MySqlFactory implements DatabaseFactory
{
    public function createConnection(): Connection
    {
        return new MySqlConnection();
    }

    public function createQueryBuilder(): QueryBuilder
    {
        return new MySqlQueryBuilder();
    }
}

يمكن لمصنع PostgreSQL إنشاء كائنات إنشاء اتصالات واستعلام خاصة بـ PostgreSQL. يمكن أن يعتمد كود التطبيق على DatabaseFactory دون معرفة نوع قاعدة البيانات المحددة.

مثال من العالم الحقيقي: عائلة مزودي الدفع

أنظمة الدفع هي مثال مفيد آخر. قد يتضمن مزود الدفع العديد من الخدمات ذات الصلة، مثل معالجة الدفع، ومعالجة استرداد الأموال، وإدارة الاشتراك، وإنشاء الفاتورة.

على سبيل المثال، قد تتضمن عائلة Stripe StripePaymentProcessor، وStripeRefundService، وStripeSubscriptionService. قد تتضمن عائلة PayPal خدمة PayPalPaymentProcessor وPayPalRefundService وPayPalSubscriptionService.

يمكن لـ Abstract Factory إنشاء المجموعة الصحيحة من الخدمات الخاصة بموفر معين ومنع خلط الخدمات من مقدمي خدمات مختلفين.

مثال على مصنع ملخص مزود الدفع

interface PaymentProcessor
{
    public function pay(float $amount): bool;
}

interface RefundProcessor
{
    public function refund(float $amount): bool;
}

interface PaymentProviderFactory
{
    public function createPaymentProcessor(): PaymentProcessor;

    public function createRefundProcessor(): RefundProcessor;
}

class StripeProviderFactory implements PaymentProviderFactory
{
    public function createPaymentProcessor(): PaymentProcessor
    {
        return new StripePaymentProcessor();
    }

    public function createRefundProcessor(): RefundProcessor
    {
        return new StripeRefundProcessor();
    }
}

class PayPalProviderFactory implements PaymentProviderFactory
{
    public function createPaymentProcessor(): PaymentProcessor
    {
        return new PayPalPaymentProcessor();
    }

    public function createRefundProcessor(): RefundProcessor
    {
        return new PayPalRefundProcessor();
    }
}

يسمح هذا التصميم للتطبيق بالتبديل بين موفري الدفع مع الحفاظ على اتساق جميع الخدمات ذات الصلة.

فوائد Abstract Factory Pattern

يوفر Abstract Factory Pattern العديد من الفوائد عندما يحتاج التطبيق إلى عائلات كائنات ذات صلة.

تشمل الفوائد الرئيسية ما يلي:

• ينشئ عائلات من الكائنات ذات الصلة باستمرار.

• يمنع خلط الكائنات غير المتوافقة من عائلات مختلفة.

• يclass إنشاء الكائن عن منطق الأعمال.

• يدعم التصميم القائم على interface وpolymorphism.

• يجعل التبديل بين العائلات أسهل.

• يحسن قابلية الصيانة في الأنظمة الكبيرة.

• يدعم المبدأ المفتوح المغلق عند تصميمه بعناية.

تجعل هذه المزايا Abstract Factory مفيدًا في الأنظمة التي تدعم موفري الخدمة أو السمات أو الأنظمة الأساسية أو البيئات أو عائلات المنتجات المتعددة.

عيوب Abstract Factory Pattern

على الرغم من أن Abstract Factory قوي، إلا أنه يمكنه أيضًا زيادة التعقيد. يتطلب عادةً عدة interfaces، ومتعددة concrete classes، والعديد من فئات المصنع.

قد يكون هذا غير ضروري للمشاريع الصغيرة أو إنشاء كائن بسيط. إذا لم يكن التطبيق بحاجة إلى إنشاء عائلات كائنات ذات صلة، فقد يكون من الأفضل إنشاء مصنع بسيط أو إنشاء كائن مباشر.

عيب آخر هو أن إضافة نوع منتج جديد إلى كل عائلة يمكن أن يتطلب تغييرات في جميع المصانع interfaces ومصانع concrete. على سبيل المثال، إذا قام مصنع واجهة المستخدم بإنشاء أزرار ومدخلات، فإن إضافة طريقة createModal جديدة تتطلب تحديث جميع مصانع السمات.

متى تستخدم Abstract Factory Pattern

استخدم Abstract Factory عندما يحتاج تطبيقك إلى إنشاء عائلات من الكائنات ذات الصلة ويجب استخدام هذه الكائنات معًا بشكل متسق.

يكون Abstract Factory مفيدًا عندما:

• يدعم التطبيق موضوعات أو منصات متعددة.

• يجب أن تأتي العديد من العناصر ذات الصلة من نفس العائلة.

• يجب ألا يعتمد الرمز على concrete classes.

• يحتاج النظام إلى التبديل بين عائلات الكائنات الكاملة.

• تريد منع اختلاط الكائنات غير المتوافقة.

• قواعد إنشاء الكائنات معقدة ويجب أن تكون مركزية.

إذا توفرت هذه الشروط، فيمكن لـ Abstract Factory تحسين التصميم وتسهيل توسيع النظام.

متى لا تستخدم Abstract Factory Pattern

لا تستخدم Abstract Factory عندما تكون مشكلة إنشاء الكائن بسيطة. إذا قام التطبيق بإنشاء نوع كائن واحد فقط، فقد يكون Factory Pattern كافيًا. إذا كان إنشاء الكائن مباشرًا ومن غير المرجح أن يتغير، فقد لا تكون هناك حاجة إلى مصنع.

تجنب مصنع الملخص عندما:

• هناك نوع منتج واحد فقط.

• لا توجد عائلات كائنات ذات صلة.

• يضيف النمط عددًا كبيرًا جدًا من classes دون فائدة حقيقية.

• المشروع صغير و بسيط.

• Dependency Injection المباشر يحل المشكلة بشكل نظيف بالفعل.

يجب أن تقلل أنماط التصميم من التعقيد على المدى الطويل، وليس إنشاء بنية غير ضرورية.

مصنع مجردة و Dependency Injection

يعمل Abstract Factory بشكل جيد مع Dependency Injection. بدلاً من إنشاء مصنع خرسانة مباشرة داخل فئة العميل، يمكن حقن المصنع من خلال constructor.

وهذا يجعل كود العميل أكثر قابلية للاختبار ومرونة.

class CheckoutService
{
    public function __construct(
        private PaymentProviderFactory $factory
    ) {
    }

    public function checkout(float $amount): bool
    {
        $processor = $this->factory->createPaymentProcessor();

        return $processor->pay($amount);
    }
}

تعتمد خدمة CheckoutService على واجهة PaymentProviderFactory. أثناء وقت التشغيل، يمكن للتطبيق إدخال StripeProviderFactory أو PayPalProviderFactory أو مصنع مزود آخر.

مصنع مجردة في لارافيل

في Laravel، يمكن استخدام Abstract Factory عندما يدعم التطبيق عائلات خدمات متعددة. على سبيل المثال، قد يدعم المشروع العديد من موفري الدفع أو تنسيقات التصدير أو موفري الإشعارات أو أنظمة التخزين.

يمكن أن تساعد حاوية خدمة Laravel في إدخال المصنع الصحيح بناءً على التكوين. بدلاً من اختيار concrete classes يدويًا عبر التطبيق، يمكن لموفر الخدمة ربط التنفيذ الصحيح للمصنع.

$this->app->bind(
    PaymentProviderFactory::class,
    StripeProviderFactory::class
);

الآن يمكن لأي خدمة تعتمد على PaymentProviderFactory أن تتلقى المصنع الذي تم تكوينه تلقائيًا.

مصنع مجردة في Symfony

يدعم Symfony أيضًا Abstract Factory من خلال الخدمات وDependency Injection والتكوين. يمكن للمطورين تحديد خدمات المصنع المختلفة وإدخال الخدمة الصحيحة اعتمادًا على البيئة أو التكوين أو قواعد العمل.

يعد هذا الأسلوب مفيدًا في تطبيقات Symfony الكبيرة حيث يجب تبديل عائلات الخدمة دون تغيير فئات الأعمال.

مصنع مجردة والهندسة المعمارية النظيفة

يمكن لـ Abstract Factory دعم البنية النظيفة عندما يساعد في الحفاظ على منطق الأعمال عالي المستوى مستقلاً عن تفاصيل التنفيذ ذات المستوى المنخفض.

على سبيل المثال، يمكن أن يعتمد منطق الأعمال على واجهة PaymentProviderFactory بدلاً من الاعتماد بشكل مباشر على فئات Stripe أو PayPal. وهذا يجعل منطق التطبيق الأساسي أكثر استقرارًا وأسهل في الاختبار.

ومع ذلك، لا ينبغي استخدام Abstract Factory في كل مكان. يجب استخدامه عندما يحتاج النظام حقًا إلى عائلات قابلة للتبديل من الكائنات ذات الصلة.

المصنع المجرد والمبدأ المغلق المفتوح

يمكن لـ Abstract Factory Pattern أن يدعم المبدأ المفتوح المغلق من خلال السماح بإضافة عائلات كائنات جديدة دون تغيير رمز العميل.

على سبيل المثال، إذا كان أحد التطبيقات يدعم بالفعل LightThemeFactory وDarkThemeFactory، فيمكن إضافة HighContrastThemeFactory جديد. لا تحتاج فئة PageRenderer إلى التغيير لأنها تعتمد على واجهة UiFactory.

وهذا يجعل النظام مفتوحًا للعائلات الجديدة مع إبقاء كود العميل الحالي مغلقًا للتعديل.

الأخطاء الشائعة في مصنع الملخص

أحد الأخطاء الشائعة هو استخدام Abstract Factory لإنشاء كائن بسيط. إذا لم تكن هناك عائلة من الكائنات ذات الصلة، فقد يكون Abstract Factory ثقيلًا جدًا.

خطأ آخر هو جعل عائلات المنتجات غير واضحة. يجب أن تنتمي جميع المنتجات التي تم إنشاؤها بواسطة نفس المصنع معًا بشكل منطقي. إذا قام المصنع بإنشاء كائنات غير ذات صلة، يصبح التصميم مربكًا.

الخطأ الثالث هو وضع منطق العمل داخل المصنع. يجب أن يركز المصنع على إنشاء الكائنات. يجب أن يظل سير عمل الأعمال في الخدمات أو فئات المجال أو حالات الاستخدام.

الخطأ الرابع هو إنشاء الكثير من abstractionات في وقت مبكر جدًا. من الأفضل تقديم Abstract Factory عندما تتضح الحاجة.

أفضل الممارسات لـ Abstract Factory Pattern

لاستخدام Abstract Factory بشكل صحيح، يجب على المطورين الحفاظ على تركيز التصميم ومعنىه.

تتضمن أفضل الممارسات المفيدة ما يلي:

• استخدم Abstract Factory فقط لعائلات الكائنات ذات الصلة.

• حدد منتجًا واضحًا interfaces.

• حافظ على اتساق فئات المنتجات الconcrete داخل كل عائلة.

• إبقاء المصانع تركز على منطق الخلق.

• استخدم Dependency Injection لتوفير المصانع لفئات العملاء.

• تجنب إضافة سير العمل داخل المصانع.

• استخدم أسماء ذات معنى مثل ThemeFactory، أو DatabaseFactory، أو PaymentProviderFactory.

• لا تقدم النمط إذا كان المصنع البسيط كافياً.

تساعد هذه الممارسات في إبقاء Abstract Factory Pattern مفيدًا ومفهومًا.

قائمة مرجعية عملية قبل استخدام مصنع الملخص

قبل استخدام Abstract Factory، اطرح هذه الأسئلة:

• هل أحتاج إلى إنشاء كائنات متعددة ذات صلة؟

• هل تنتمي هذه الكائنات إلى عائلات أو مقدمي خدمات مختلفين؟

• هل يجب التبديل بين العائلات الكاملة؟

• هل من المهم منع خلط الكائنات غير المتوافقة؟

• هل سيصبح كود العميل أكثر نظافة بالاعتماد على interfaces؟

• هل سيكون Factory Pattern البسيط كافيًا؟

• هل سيجعل هذا التصميم التغييرات المستقبلية أسهل؟

إذا كانت الإجابة بنعم على معظم هذه الأسئلة، فقد يكون Abstract Factory خيارًا جيدًا للتصميم.

خاتمة

Abstract Factory Pattern هو نمط تصميم إبداعي يُستخدم لإنشاء عائلات من الكائنات ذات الصلة دون تعريض concrete classes لكود العميل. يكون ذلك مفيدًا بشكل خاص عندما يدعم التطبيق العديد من السمات أو الأنظمة الأساسية أو مقدمي الخدمة أو محركات قواعد البيانات أو عائلات الخدمة.

بالمقارنة مع Factory Pattern، يركز Abstract Factory بشكل أكبر على إنشاء مجموعات من الكائنات المتوافقة. فهو يعمل على تحسين الاتساق، ويدعم polymorphism، ويقلل من الاقتران، ويساعد في الحفاظ على منطق الأعمال مستقلاً عن تفاصيل إنشاء الكائنات.

ومع ذلك، ينبغي استخدام Abstract Factory بعناية. يمكن أن يضيف التعقيد عندما تكون المشكلة بسيطة. يجب على المطورين تطبيقه عندما يحتاج التطبيق حقًا إلى عائلات قابلة للتبديل من الكائنات ذات الصلة. عند استخدامه بشكل صحيح، فإنه يعد نموذجًا قويًا لبناء برامج موجهة للكائنات مرنة وقابلة للتطوير وقابلة للصيانة.