في هندسة البرمجيات، **نمط المحوّل (بالإنجليزية: adapter pattern)‏** هو **نمط** تصميم برمجيات (يُعرف أيضًا باسم المغلّف؛ تسمية بديلة مشتركة مع نمط الديكور) يسمح لواجهة صنف موجود مسبقاً ليُستخدم كواجهة أخرى. غالبًا ما يتم استخدامه لجعل الأصناف الموجودة تعمل مع الآخرين دون تعديل الكود المصدري الخاص بهم.

مثال على ذلك هو المحوّل الذي يحوّل واجهة نموذج كائن المستند من مستند XML إلى بنية شجرة يمكن عرضها.

نظرة عامة
---------

يعد نمط تصميم المحوّل أحد *أنماط تصميم GoF* الثلاثة والعشرون المعروفة التي تصف كيفية حل مشاكل التصميم المتكررة لتصميم برنامج مرن وقابل لإعادة الاستخدام، أي ذو توجيه كائني الذي يسهل تنفيذه، تغييره، اختباره وإعادة استخدامه.

يحل نمط تصميم المحوّل مشاكل مثل:

* كيف يمكن إعادة استخدام صنف (بالإنجليزية: class)‏ لا يحتوي على واجهة يطلبها العميل؟
* كيف يمكن للأصناف التي تحتوي على واجهات غير متوافقة أن تعمل معًا؟
* كيف يمكن تُوفّر واجهة بديلة لصنف؟

غالبًا لا يمكن إعادة استخدام صنف (موجود بالفعل) فقط لأن واجهته لا تتوافق مع الواجهة التي يطلبها العملاء.

يصف نمط تصميم المحوّل كيفية حل مثل هذه المشاكل:

* عرّف صنف محوّل منفصل (بالإنجليزية: `adapter`)‏ يحول الواجهة (غير المتوافقة) للصنف المحَوَل (بالإنجليزية: `adaptee`)‏ إلى واجهة أخرى تُعتبر الهدف (بالإنجليزية: `target`)‏ والتي يطلبها العملاء.
* اعمل من خلال محوّل (بالإنجليزية: `adapter`)‏ للعمل مع (إعادة استخدام) أصناف ليس لها الواجهة المطلوبة.

الفكرة الرئيسية في هذا النمط هي العمل من خلال المحوّل المنفصل (بالإنجليزية: `adapter`)‏، الذي يقوم بتكييف (تحويل) واجهة صنف (موجودة مسبقاً) دون تغييرها.

لا يعرف العملاء إذا ما كانوا يعملون مع الصنف الهدف مباشرة (بالإنجليزية: `target`)‏ أم من خلال محوّل (بالإنجليزية: `adapter`)‏ مع صنف لا يحتوي على الواجهة الهدف (بالإنجليزية: `target`)‏.

انظر أيضًا الرسم التخطيطي للصنف بلفة النمذجة الموحدة أدناه.

تعريف
-----

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

استخدام
-------

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

| نمط | نوايا |
| --- | --- |
| محوّل أو مُغلّف | يحول واجهة إلى أخرى بحيث تتطابق مع ما يتوقعه العميل. |
| منفذ الديكور | يضيف المسؤولية إلى الواجهة ديناميكيًا من خلال تغليف الكود الأصلي. |
| تفويض | دعم "التركيب على الميراث". |
| واجهة البناء | يوفر واجهة بينية مبسطة. |

هيكل
----

### مخطط الصنف بلغة النمذجة الموحدة

 مخطط الصنف بلغة النمذجة الموحدة لنمط تصميم المحوّل.
في مخطط الصنف بلغة النمذجة الموحدة أعلاه، لا يمكن لصنف العميل (بالإنجليزية: `client`)‏ الذي يتطلب الواجهة الهدف (بالإنجليزية: `target`)‏ إعادة استخدام صنف المحَوَل (بالإنجليزية: `adaptee` )‏ مباشرة لأن المحوَل (بالإنجليزية: `adaptee`)‏ لا يتوافق مع الواجهة الهدف (بالإنجليزية: `target`)‏. بدلاً من ذلك، يقوم العميل (بالإنجليزية: `client`)‏ خلال صنف المحوّل (بالإنجليزية: `adapter`)‏ بتنفيذ الواجهة الهدف (بالإنجليزية: `target`)‏ من حيث المحوَل (بالإنجليزية: `adaptee`)‏ :

* أسلوب مُحوّل الكائن (بالإنجليزية: `object adapter`)‏ ينفذ الواجهة الهدف (بالإنجليزية: `target`)‏ عن طريق التفويض إلى كائن محَوَل (بالإنجليزية: `adaptee`)‏ في وقت التشغيل (بالإنجليزية: `()adaptee.specificOperation`)‏ (الكود: محَوَل.عملية محددة).
* أسلوب مُحوّل الصنف (بالإنجليزية: `class adapter`)‏ ينفذ الواجهة الهدف (بالإنجليزية: `target`)‏ من خلال الوراثة من صنف المحَوَل (بالإنجليزية: `adaptee`)‏ في وقت التجميع (بالإنجليزية: `()specificOperation`)‏ (الكود: عملية محددة).

### نمط محوّل الكائن

**نمط محوّل الكائن (بالإنجليزية: Object adapter pattern)‏** في نمط المحوّل هذا، يحتوي المحوّل على مثيل من الصنف الذي يغلّفه. في هذه الحالة، يقوم المحوّل بإجراء استدعاءات إلى مثيل الكائن المُغلّف.

 نمط محوّل الكائن المعبر عنه في UML 
 نمط محوّل الكائن المعبر عنه في LePUS3
### نمط محوّل الصنف

**نمط محوّل الصنف (بالإنجليزية: Class adapter pattern)‏** يستخدم نمط المحوّل هذا عدة واجهات متعددة الأشكال تقوم بتنفيذ أو توريث كل من الواجهة المتوقعة والواجهة الموجودة مسبقًا. من المعتاد أن تكون الواجهة المتوقعة مُنشئة كصنف واجهة خالصة (صافية)، خاصة في لغات مثل جافا (قبل JDK 1.8) التي لا تدعم توارث الأصناف المتعدد.

 نمط محوّل الصنف المعبر عنه في مخطط لغة النمذجة الموحدة. 
محوّل الصنف مشروح ب LePUS3
### شكل آخر من أنماط محوّل وقت التشغيل

#### الدافع من الحل وقت التجميع

يجب أن يدعم صنف `ClassA`
 صنف `classB`
 مع بعض البيانات، لنفترض وجود بعض البيانات من سلاسل النص`String`
. الحل وقت التجميع هو التالي:

  

```
classB.setStringData(classA.getStringData());

```
 ومع ذلك، افترض أنه يجب تغيير تنسيق بيانات السلاسل النصية في `String`
. الحل وقت التجميع هو استخدام الوراثة:

```
public class Format1ClassA extends ClassA {
 @Override
 public String getStringData() {
 return format(toString());
 } 
}

```
 وربما إنشاء كائن «التنسيق» بشكل صحيح في وقت التشغيل عن طريق نمط المصنع.

#### حل محوّل وقت التشغيل

باستخدام «المحوّلات» نحصل على الحل كما يلي:

1. عرّف واجهة «مزود» وسيط، واكتبْ تنفيذ لواجهة المزود تلك التي تغلف مصدر البيانات، `ClassA`
 في هذا المثال، وتخرج البيانات المنسقة حسب الضرورة:

  

```
public interface StringProvider {
 public String getStringData();
}

public class ClassAFormat1 implements StringProvider {
 private ClassA classA = null;

 public ClassAFormat1(final ClassA a) {
 classA = a;
 }

 public String getStringData() {
 return format(classA.getStringData());
 }

 private String format(final String sourceValue) {
//تلاعب وتحكم بالسلسة النصية في التنسيق المطلوب عن طريق الكائن الذي يحتاج لكائن البيانات
 // Manipulate the source string into a format required 
 // by the object needing the source object's data
 return sourceValue.trim();
 }
}

```

2. اكتبْ صنف محوّل الذي يرجع التنفيذ المحدد للمزود:

```
public class ClassAFormat1Adapter extends Adapter {
 public Object adapt(final Object anObject) {
 return new ClassAFormat1((ClassA) anObject);
 }
}

```

3. سجّلْ المحوّل `adapter`
 في سجل عالمي، بحيث يمكن البحث عن المحوّل `adapter`
 في وقت التشغيل:

```
AdapterFactory.getInstance().registerAdapter(ClassA.class, ClassAFormat1Adapter.class, "تنسيق1");

```

4. في الكود، عند الرغبة في نقل البيانات من صنف `ClassA`
 إلى صنف `classB`
، اكتبْ:

```
 Adapter adapter =
 AdapterFactory.getInstance()
 .getAdapterFromTo(ClassA.class, StringProvider.class, "تنسيق1");
StringProvider provider = (StringProvider) adapter.adapt(classA);
String string = provider.getStringData();
classB.setStringData(string);

```
 أو بشكل أكثر إيجازًا: 

```
classB.setStringData(
 ((StringProvider)
 AdapterFactory.getInstance()
 .getAdapterFromTo(ClassA.class, StringProvider.class, "تنسيق1")
 .adapt(classA))
 .getStringData());

```

5. يمكن ملاحظة الفائدة من ذلك، إذا كان من المطلوب نقل البيانات بتنسيق ثاني، فابحثْ عن المحوّل/ المزود المختلف:

```
 Adapter adapter =
 AdapterFactory.getInstance()
 .getAdapterFromTo(ClassA.class, StringProvider.class, "تنسيق2");

```

6. وإذا كان من المطلوب إخراج البيانات من صنف `ClassA`
، على سبيل المثال؛ بيانات لصورة في `ClassC`
:

```
Adapter adapter =
 AdapterFactory.getInstance()
 .getAdapterFromTo(ClassA.class, ImageProvider.class, "تنسيق2");
ImageProvider provider = (ImageProvider) adapter.adapt(classA);
classC.setImage(provider.getImage());

```

7. بهذه الطريقة، استخدام المحوّلات والمزودين يسمح بتعدد «الرؤية» من قبل صنفا `ClassB`
 و `ClassC`
 في صنف `ClassA`
 دون الحاجة إلى تغيير التسلسل الهرمي للأصناف. بشكل عام، ما سبق يسمح بآلية لتدفق البيانات الغير محددة بين الكائنات التي يمكن تعديلها إلى التسلسل الهرمي للكائن الموجود.

### تنفيذ نمط المحوّل

عند تنفيذ نمط المحوّل، للتوضيح، يمكن للمرء تطبيق اسم الصنف من صنف إلى واجهة محوّل كالتالي `[ClassName]To[Interface]Adapter`
 للتنفيذ الخاص بالمزود، على سبيل المثال `DAOToProviderAdapter`
. يجب أن يكون لديه طريقة المنشئ مع متغير خاص بصنف المحَوَل كمعلمة. سيتم تمرير هذه المعلمة إلى مثيل عضو `instance member of`
 من (اسم-الصنف) إلى (اسم-الواجهة) للمحوّل كالتالي `[ClassName]To[Interface]Adapter`
. عندما يتم استدعاء طريقة العميل، سيتمكن من الوصول إلى مثيل المحوَل الذي يسمح بالوصول إلى البيانات المطلوبة للمحوَل وتنفيذ العمليات على تلك البيانات التي تولد المخرجات المطلوبة.

#### كريستال

```
abstract class FormatIphone
 getter connector

 abstract def recharge
 abstract def use\_lightning
end

abstract class FormatAndroid
 getter connector

 abstract def recharge
 abstract def use\_micro\_usb
end

class Iphone < FormatIphone
 def initialize
 @connector = false
 end

 def use\_lightning
 @connector = true
 puts "Lightning connected"
 end

 def recharge
 if @connector
 puts "Recharge started"
 puts "Recharge finished"
 else
 puts "Connect Lightning first"
 Close
 end
end

class Android < FormatAndroid
 def initialize
 @connector = false
 end

 def use\_micro\_usb
 @connector = true
 puts "MicroUsb connected"
 end

 def recharge
 if @connector
 puts "Recharge started"
 puts "Recharge finished"
 else
 puts "Connect MicroUsb first"
 end
 end
end

class IphoneAdapter < FormatAndroid
 private getter mobile : FormatIphone

 def initialize(@mobile)
 end

 def recharge
 @mobile.recharge
 end

 def use\_micro\_usb
 puts "MicroUsb connected"
 @mobile.use\_lightning
 end
end

class AndroidRecharger
 def initialize
 phone = Android.new
 phone.use\_micro\_usb
 phone.recharge
 end
end

class IphoneMicroUsbRecharger
 def initialize
 phone = Iphone.new
 phone\_adapter = IphoneAdapter.new(phone)
 phone\_adapter.use\_micro\_usb
 phone\_adapter.recharge
 end
end

class IphoneRecharger
 def initialize
 phone = Iphone.new
 phone.use\_lightning
 phone.recharge
 end
end

puts "Recharging android with MicroUsb Recharger"
AndroidRecharger.new
puts

puts "Recharging iPhone with MicroUsb using Adapter pattern"
IphoneMicroUsbRecharger.new
puts

puts "Recharging iPhone with iPhone Recharger"
IphoneRecharger.new

```
 المخرجات:

`Recharging android with MicroUsb Recharger
MicroUsb connected`

`Recharge started

Recharge finished

Recharging iPhone with MicroUsb using Adapter pattern

MicroUsb connected

Lightning connected

Recharge started

Recharge finished

Recharging iPhone with iPhone Recharger

Lightning connected`
`Recharge started
Recharge finished`

#### جافا

```
 interface LightningPhone {
 void recharge();
 void useLightning();
}

interface MicroUsbPhone {
 void recharge();
 void useMicroUsb();
}

class Iphone implements LightningPhone {
 private boolean connector;

 @Override
 public void useLightning() {
 connector = true;
 System.out.println("Lightning connected");
 }

 @Override
 public void recharge() {
 if (connector) {
 System.out.println("Recharge started");
 System.out.println("Recharge finished");
 } else {
 System.out.println("Connect Lightning first");
 }
 }
}

class Android implements MicroUsbPhone {
 private boolean connector;

 @Override
 public void useMicroUsb() {
 connector = true;
 System.out.println("MicroUsb connected");
 }

 @Override
 public void recharge() {
 if (connector) {
 System.out.println("Recharge started");
 System.out.println("Recharge finished");
 } else {
 System.out.println("Connect MicroUsb first");
 }
 }
}
/\* exposing the target interface while wrapping source object \*/
class LightningToMicroUsbAdapter implements MicroUsbPhone {
 private final LightningPhone lightningPhone;

 public LightningToMicroUsbAdapter (LightningPhone lightningPhone) {
 this.lightningPhone = lightningPhone;
 }

 @Override
 public void useMicroUsb() {
 System.out.println("MicroUsb connected");
 lightningPhone.useLightning();
 }

 @Override
 public void recharge() {
 lightningPhone.recharge();
 }
}

public class AdapterDemo {
 static void rechargeMicroUsbPhone(MicroUsbPhone phone) {
 phone.useMicroUsb();
 phone.recharge();
 }

 static void rechargeLightningPhone(LightningPhone phone) {
 phone.useLightning();
 phone.recharge();
 }

 public static void main(String[] args) {
 Android android = new Android();
 Iphone iPhone = new Iphone();

 System.out.println("Recharging android with MicroUsb");
 rechargeMicroUsbPhone(android);

 System.out.println("Recharging iPhone with Lightning");
 rechargeLightningPhone(iPhone);

 System.out.println("Recharging iPhone with MicroUsb");
 rechargeMicroUsbPhone(new LightningToMicroUsbAdapter (iPhone));
 }
}

```
مخرجات:

`Recharging android with MicroUsb`

`MicroUsb connected

Recharge started

Recharge finished

Recharging iPhone with Lightning

Lightning connected

Recharge started

Recharge finished

Recharging iPhone with MicroUsb

MicroUsb connected

Lightning connected`
`Recharge started
Recharge finished`

#### دلفي

```
 type
 ILightningPhone = interface
 ['{52628045-CF6C-41F0-ACCA-A65DCEE13BDC}']
 procedure Recharge;
 procedure UseLightning;
 end;

type
 IMicroUSBPhone = interface
 ['{436746B6-D02D-49E6-A5AC-F6D745DFD182}']
 procedure Recharge;
 procedure UseMicroUSB;
 end;

type
 TIPhone = class(TInterfacedObject, ILightningPhone)
 strict private
 FConnector: Boolean;
 public
 procedure Recharge;
 procedure UseLightning;
 end;

type
 TAndroid = class(TInterfacedObject, IMicroUSBPhone)
 strict private
 FConnector: Boolean;
 public
 procedure Recharge;
 procedure UseMicroUSB;
 end;

type
 TLightningToMicroUsbAdapter = class(TInterfacedObject, IMicroUSBPhone)
 strict private
 FLightningPhone: ILightningPhone;
 public
 constructor Create(const ALightningPhone: ILightningPhone); reintroduce;
 procedure Recharge;
 procedure UseMicroUSB;
 end;

procedure RechargeLightningPhone(const ALightningPhone: ILightningPhone);
begin
 ALightningPhone.UseLightning;
 ALightningPhone.Recharge;
end;

procedure RechargeMicroUSBPhone(const AMicroUSBPhone: IMicroUSBPhone);
begin
 AMicroUSBPhone.UseMicroUSB;
 AMicroUSBPhone.Recharge;
end;

procedure TEdijsForm.PatternExampleButtonClick(Sender: TObject);
var
 \_Android: IMicroUSBPhone;
 \_IPhone: ILightningPhone;
 \_LightningToMicroUsbAdapter: IMicroUSBPhone;
begin
 \_Android := TAndroid.Create;
 WriteLn('Recharging android with MicroUsb');
 RechargeMicroUSBPhone(\_Android);

 \_IPhone := TIPhone.Create;
 WriteLn('Recharging iPhone with Lightning');
 RechargeLightningPhone(\_IPhone);

 WriteLn('Recharging iPhone with MicroUsb');
 \_LightningToMicroUsbAdapter := TLightningToMicroUsbAdapter.Create(\_IPhone);
 RechargeMicroUSBPhone(\_LightningToMicroUsbAdapter);
end;

```

المخرجات:

`Recharging android with MicroUsb`

`MicroUsb connected
Recharge started

Recharge finished

Recharging iPhone with Lightning

Lightning connected

Recharge started

Recharge finished

Recharging iPhone with MicroUsb

MicroUsb connected

Lightning connected

Recharge started`
`Recharge finished`

#### بي أتش بي

```
// Adapter Pattern example

interface IFormatIPhone
{
 public function recharge();
 public function useLightning();
}

interface IFormatAndroid
{
 public function recharge();
 public function useMicroUsb();
}

// Adaptee
class IPhone implements IFormatIPhone
{
 private $connectorOk = FALSE;

 public function useLightning()
 {
 $this->connectorOk = TRUE;
 echo "Lightning connected -$\n";
 }

 public function recharge()
 {
 if ($this->connectorOk)
 {
 echo "Recharge Started\n";
 echo "Recharge 20%\n";
 echo "Recharge 50%\n";
 echo "Recharge 70%\n";
 echo "Recharge Finished\n";
 }
 else
 {
 echo "Connect Lightning first\n";
 }
 }
}

// Adapter
class IPhoneAdapter implements IFormatAndroid
{
 private $mobile;

 public function \_\_construct(IFormatIPhone $mobile)
 {
 $this->mobile = $mobile;
 }

 public function recharge()
 {
 $this->mobile->recharge();
 }

 public function useMicroUsb()
 {
 echo "MicroUsb connected -> ";
 $this->mobile->useLightning();
 }
}

class Android implements IFormatAndroid
{
 private $connectorOk = FALSE;

 public function useMicroUsb()
 {
 $this->connectorOk = TRUE;
 echo "MicroUsb connected ->\n";
 }

 public function recharge()
 {
 if ($this->connectorOk)
 {
 echo "Recharge Started\n";
 echo "Recharge 20%\n";
 echo "Recharge 50%\n";
 echo "Recharge 70%\n";
 echo "Recharge Finished\n";
 }
 else
 {
 echo "Connect MicroUsb first\n";
 }
 }
}

// client
class MicroUsbRecharger
{
 private $phone;
 private $phoneAdapter;

 public function \_\_construct()
 {
 echo "---Recharging iPhone with Generic Recharger---\n";
 $this->phone = new IPhone();
 $this->phoneAdapter = new IPhoneAdapter($this->phone);
 $this->phoneAdapter->useMicroUsb();
 $this->phoneAdapter->recharge();
 echo "---iPhone Ready for use---\n\n";
 }
}

$microUsbRecharger = new MicroUsbRecharger();

class IPhoneRecharger
{
 private $phone;

 public function \_\_construct()
 {
 echo "---Recharging iPhone with iPhone Recharger---\n";
 $this->phone = new IPhone();
 $this->phone->useLightning();
 $this->phone->recharge();
 echo "---iPhone Ready for use---\n\n";
 }
}

$iPhoneRecharger = new IPhoneRecharger();

class AndroidRecharger
{
 private $phone;

 public function \_\_construct()
 {
 echo "---Recharging Android Phone with Generic Recharger---\n";
 $this->phone = new Android();
 $this->phone->useMicroUsb();
 $this->phone->recharge();
 echo "---Phone Ready for use---\n\n";
 }
}

$androidRecharger = new AndroidRecharger();

// Result: #quanton81

//---Recharging iPhone with Generic Recharger---
//MicroUsb connected -> Lightning connected -$
//Recharge Started
//Recharge 20%
//Recharge 50%
//Recharge 70%
//Recharge Finished
//---iPhone Ready for use---
//
//---Recharging iPhone with iPhone Recharger---
//Lightning connected -$
//Recharge Started
//Recharge 20%
//Recharge 50%
//Recharge 70%
//Recharge Finished
//---iPhone Ready for use---
//
//---Recharging Android Phone with Generic Recharger---
//MicroUsb connected ->
//Recharge Started
//Recharge 20%
//Recharge 50%
//Recharge 70%
//Recharge Finished
//---Phone Ready for use---

```

#### سكالا

```
 implicit def adaptee2Adapter(adaptee: Adaptee): Adapter = {
 new Adapter {
 override def clientMethod: Unit = {
 // call Adaptee's method(s) to implement Client's clientMethod \*/
 }
 }
}

```

#### بايثون

```
"""
Adapter pattern example.
"""
from abc import ABCMeta, abstractmethod

NOT\_IMPLEMENTED = "You should implement this."

RECHARGE = ["Recharge started.", "Recharge finished."]

POWER\_ADAPTERS = {"Android": "MicroUSB", "iPhone": "Lightning"}

CONNECTED = "{} connected."
CONNECT\_FIRST = "Connect {} first."

class RechargeTemplate:
    \_\_metaclass\_\_ = ABCMeta

    @abstractmethod
    def recharge(self):
        raise NotImplementedError(NOT\_IMPLEMENTED)

class FormatIPhone(RechargeTemplate):
    @abstractmethod
    def use\_lightning(self):
        raise NotImplementedError(NOT\_IMPLEMENTED)

class FormatAndroid(RechargeTemplate):
    @abstractmethod
    def use\_micro\_usb(self):
        raise NotImplementedError(NOT\_IMPLEMENTED)

class IPhone(FormatIPhone):
    \_\_name\_\_ = "iPhone"

    def \_\_init\_\_(self):
        self.connector = False

    def use\_lightning(self):
        self.connector = True
        print(CONNECTED.format(POWER\_ADAPTERS[self.\_\_name\_\_]))

    def recharge(self):
        if self.connector:
            for state in RECHARGE:
                print(state)
        else:
            print(CONNECT\_FIRST.format(POWER\_ADAPTERS[self.\_\_name\_\_]))

class Android(FormatAndroid):
    \_\_name\_\_ = "Android"

    def \_\_init\_\_(self):
        self.connector = False

    def use\_micro\_usb(self):
        self.connector = True
        print(CONNECTED.format(POWER\_ADAPTERS[self.\_\_name\_\_]))

    def recharge(self):
        if self.connector:
            for state in RECHARGE:
                print(state)
        else:
            print(CONNECT\_FIRST.format(POWER\_ADAPTERS[self.\_\_name\_\_]))

class IPhoneAdapter(FormatAndroid):
    def \_\_init\_\_(self, mobile):
        self.mobile = mobile

    def recharge(self):
        self.mobile.recharge()

    def use\_micro\_usb(self):
        print(CONNECTED.format(POWER\_ADAPTERS["Android"]))
        self.mobile.use\_lightning()

class AndroidRecharger(object):
    def \_\_init\_\_(self):
        self.phone = Android()
        self.phone.use\_micro\_usb()
        self.phone.recharge()

class IPhoneMicroUSBRecharger(object):
    def \_\_init\_\_(self):
        self.phone = IPhone()
        self.phone\_adapter = IPhoneAdapter(self.phone)
        self.phone\_adapter.use\_micro\_usb()
        self.phone\_adapter.recharge()

class IPhoneRecharger(object):
    def \_\_init\_\_(self):
        self.phone = IPhone()
        self.phone.use\_lightning()
        self.phone.recharge()

print("Recharging Android with MicroUSB recharger.")
AndroidRecharger()
print()

print("Recharging iPhone with MicroUSB using adapter pattern.")
IPhoneMicroUSBRecharger()
print()

print("Recharging iPhone with iPhone recharger.")
IPhoneRecharger()

```

ملحق: مسرد المصطلحات الإنجليزية
-------------------------------


|  |
| --- |
| مَسرد المفردات وفق أقسام المقالة |
| المقدمة |
| **نمط المحوّل** | adapter pattern |
| المغلّف | wrapper |
| واجهة صنف بينية | class interface |
| الكود المصدري | source code |
| نموذج كائن المستند | Document Object Model |
| نظرة عامة |
| تنفيذ | implement |
| صنف | class |
| غير متوافقة | incompatible |
| يطلبها العملاء | clients require |
| محوّل منفصل | `adapter` |
| محَوَل | `adaptee` |
| الهدف | `target` |
| تكييف (تحويل) | adapts |
| لغة النمذجة الموحدة | UML |
| تعريف |
| الوظيفة الداخلية | inner functionality |
| واجهة إحدى الأصناف | interface of one class |
| العملاء | clients |
| استخدام |
| متعدد الأشكال | polymorphic behavior |
| وقت التشغيل | run-time |
| واجهة البناء | facade |
| كائن أساسي | underlying object |
| منفذ الديكور | Decorator |
| تفويض | Delegation |
| التركيب على الميراث | composition over inheritance |
| واجهة البناء | Facade |
| واجهة بينية مبسطة | simplified interface |
| هيكل |
| وقت التجميع | compile-time |
| مثيل من الصنف | an instance of the class |
| الكائن المُغلّف | wrapped object |
| عدة واجهات متعددة الأشكال | multiple polymorphic interfaces |
| الموجودة مسبقًا | pre-existing |
| صنف واجهة خالصة | pure interface class |
| توارث الأصناف المتعدد | multiple inheritance of classes |
| محوّل وقت التشغيل | runtime adapter |
| كائن "التنسيق" | "formatting" object |
| نمط المصنع | factory pattern |
| "مزود" | "provider" |
| تخرج | outputs |
| البيانات المنسقة | the data formatted |
| يرجع | returns |
| التنفيذ المحدد للمزود | the specific implementation of the provider |
| سجل عالمي | global registry |
| تنسيق | format |
| إخراج | output |
| بتعدد "الرؤية" | multiple "views" |
| التسلسل الهرمي للأصناف | class hierarchy |
| تدفق البيانات الغير محددة | arbitrary data flows |
| التسلسل الهرمي للكائن الموجود | to an existing object hierarchy |
| متغير خاص بصنف المحَوَل | adaptee class variable |
| كمعلمة | parameter |
| طريقة العميل | ClientMethod |
| مثيل المحوَل | the adaptee instance |
| محوَل | adaptee |

انظر أيضًا
----------

* التفويض(بالإنجليزية: Delegation)‏، ذو صلة قوية بنمط محوّل الكائن.
* مبدأ انعكاس التبعية (بالإنجليزية: Dependency inversion principle)‏، والذي يمكن اعتباره تطبيقًا لنمط المحوّل، عندما تعرّف الاصناف عالية المستوى واجهتها (المحوّل) الخاصة بها إلى النموذج المنخفض المستوى (التي ينفذها صنف المحوّلات).

المراجع
-------

1. 1 2  Freeman، Eric؛ Freeman، Elisabeth؛ Sierra، Kathy؛ Bates، Bert (2004). *Head First Design Patterns*. أوريلي ميديا. ص. 244. ISBN:978-0-596-00712-6. OCLC:809772256. مؤرشف من الأصل (paperback) في 2018-04-28. اطلع عليه بتاريخ 2013-04-30.
2. ↑  Gamma، Erich؛ Helm، Richard؛ Johnson، Ralph؛ Vlissides، John (1994). *Design Patterns: Elements of Reusable Object-Oriented Software*. أديسون-ويسلي  ‏. ص. 139ff. ISBN:0-201-63361-2. مؤرشف من الأصل في 2020-05-29.`{{استشهاد بكتاب}}`: صيانة CS1: extra punctuation (link)
3. ↑  "The Adapter design pattern - Problem, Solution, and Applicability". *w3sDesign.com*. مؤرشف من الأصل في 2020-05-29. اطلع عليه بتاريخ 2017-08-12.
4. ↑  Freeman، Eric؛ Freeman، Elisabeth؛ Sierra، Kathy؛ Bates، Bert (2004). Hendrickson، Mike؛ Loukides، Mike (المحررون). *Head First Design Patterns*. أوريلي ميديا. ج. 1. ص. 243, 252, 258, 260. ISBN:978-0-596-00712-6. مؤرشف من الأصل (paperback) في 2020-05-29. اطلع عليه بتاريخ 2012-07-02.
5. ↑  "The Adapter design pattern - Structure and Collaboration". *w3sDesign.com*. مؤرشف من الأصل في 2018-08-19. اطلع عليه بتاريخ 2017-08-12.

|  |  |
| --- | --- |
| مشاريع شقيقة | في كومنز صور وملفات عن: نمط المحول |



| * ع
* ن
* ت
 أنماط تصميم البرمجيات (برمجة) |
| --- |
| إنشائي (Creational) | 
* Abstract factory
* نمط تصميم الباني
* حقن التبعية
* نمط طريقة المصنع
* Lazy initialization
* Multiton
* Object pool
* Prototype
* اكتساب الموارد تهيئة
* النمط المفرد

 |
| هيكلي (Structural) | 
* نمط المحول
* نموذج التصميم جسر
* نموذج التصميم المجمع
* نموذج التصميم ديكور
* Delegation
* نمط واجهة المبنى
* نموذج التصميم وزن الذبابة
* Front controller
* Marker interface
* Module
* نمط الوكيل
* Twin

 |
| سلوكي (Behavioral) | 
* Blackboard
* Chain of responsibility
* Command
* Interpreter
* نمط المكرر
* Mediator
* Memento
* Null object
* المراقب (نموذج تصميم)
* Servant
* Specification
* State
* نموذج الإستراتيجية
* Template method
* Visitor

 |
| وظيفي (Functional) | 
* مونويد
* Functor
* Applicative
* Monad
* Comonad
* Free monad
* HOF
* Currying
* Function composition
* Closure
* المولد

 |
| متزامن (Concurrency) | 
* Active object
* Actor
* Balking
* حاجز (حوسبة)
* Binding properties
* Coroutine
* Compute kernel
* Double-checked locking
* Event-based asynchronous
* ليف
* Futex
* Futures and promises
* Guarded suspension
* Immutable object
* Join
* Lock
* صيغة التراسل
* Monitor
* Nuclear
* Proactor
* Reactor
* Read write lock
* Scheduler
* STM
* Thread pool
* Thread-local storage

 |
| معماري (Architectural) | 
* \* ADR
* نمط التسجيل النشط
* نمط الوسيط
* نموذج الخادم والعميل
* هندسة البرمجيات بالمكونات
* DAO
* كائن نقل البيانات
* تصميم موجه بالمجال
* ECB
* ECS
* EDA
* Front controller
* Identity map
* Interceptor
* Implicit invocation
* عكس التحكم
* Model 2
* MOM
* Microservices
* MVA
* نمط وعرض ومتحكم
* MVP
* MVVM
* Monolithic
* عمارة متعددة الطبقات
* Naked objects
* ORB
* ند لند
* Publish–subscribe
* PAC
* رست
* بنية خدمية
* نمط محدد موقع الخدمة
* SN
* SBA
* Specification

 |
| توزيع سحابي (Cloud Distributed) | 
* Ambassador
* Anti-Corruption Layer
* Bulkhead
* Cache-Aside
* Circuit Breaker
* CQRS
* Compensating Transaction
* Competing Consumers
* Compute Resource Consolidation
* Event Sourcing
* External Configuration Store
* Federated Identity
* Gatekeeper
* فهرس قاعدة بيانات
* Leader Election
* نموذج الهيكلة والتجميع
* Materialized View
* Pipes
* Filters
* Priority Queue
* Publisher-Subscriber
* Queue-Based Load Leveling
* Retry
* Scheduler Agent Supervisor
* Sharding
* Sidecar
* Strangler
* Throttling
* Valet Key

 |
| أخرى | 
* Business delegate
* Composite entity
* Intercepting filter
* Lazy loading
* Mangler
* غرض مقلد
* Type tunnel
* Method chaining

 |
| كتب | 
* *خطط التصميم*
* *Enterprise Integration Patterns*
* *Code Complete*
* *POSA*

 |
| أشخاص | 
* كريستوفر الكسندر
* إريك جاما
* رالف جونسن
* John Vlissides
* Grady Booch
* كينت بيك
* وورد كانينغهام
* مارتن فاولر
* روبرت سيسيل مارتن
* Jim Coplien
* دوغلاس س. شميت
* Linda Rising

 |
| مجتمعات (Communities) | 
* The Hillside Group
* The Portland Pattern Repository

 |

* أيقونة بوابةبوابة تقانة المعلومات
* أيقونة بوابةبوابة علم الحاسوب