نمط المحول  في هندسة البرمجيات، نمط المحوّل هو نمط تصميم برمجيات (يُعرف أيضًا باسم المغلّف؛ تسمية بديلة مشتركة مع نمط الديكور) يسمح لواجهة صنف موجود مسبقاً ليُستخدم كواجهة أخرى. غالبًا ما يتم استخدامه لجعل الأصناف الموجودة تعمل مع الآخرين دون تعديل الكود المصدري الخاص بهم.  مثال على ذلك هو المحوّل الذي يحوّل واجهة نموذج كائن المستند من مستند XML إلى بنية شجرة يمكن عرضها.  يعد نمط تصميم المحوّل أحد "أنماط تصميم GoF" الثلاثة والعشرون المعروفة التي تصف كيفية حل مشاكل التصميم المتكررة لتصميم برنامج مرن وقابل لإعادة الاستخدام، أي ذو توجيه كائني الذي يسهل تنفيذه، تغييره، اختباره وإعادة استخدامه.  يحل نمط تصميم المحوّل مشاكل مثل:   غالبًا لا يمكن إعادة استخدام صنف (موجود بالفعل) فقط لأن واجهته لا تتوافق مع الواجهة التي يطلبها العملاء.  يصف نمط تصميم المحوّل كيفية حل مثل هذه المشاكل:   الفكرة الرئيسية في هذا النمط هي العمل من خلال المحوّل المنفصل ، الذي يقوم بتكييف (تحويل) واجهة صنف (موجودة مسبقاً) دون تغييرها.  لا يعرف العملاء إذا ما كانوا يعملون مع الصنف الهدف مباشرة أم من خلال محوّل مع صنف لا يحتوي على الواجهة الهدف .  انظر أيضًا الرسم التخطيطي للصنف بلفة النمذجة الموحدة أدناه.  يسمح المحوّل لواجهتين غير متوافقتين بالعمل معًا. هذا هو التعريف الحقيقي للمحوّل. قد تكون الواجهات غير متوافقة، ولكن الوظيفة الداخلية يجب أن تلبي الحاجة. يسمح نمط تصميم المحوّل للأصناف غير المتوافقة بالعمل معًا من خلال تحويل واجهة إحدى الأصناف إلى واجهة يتوقعها العملاء.  يمكن استخدام المحوّل عندما يتوجب على المُغلّف الالتزام بواجهة معينة ويجب أن يدعم سلوك متعدد الأشكال. بدلاً من ذلك، منفذ نمط الديكور يمكّن من إضافة أو تغيير سلوك واجهة في وقت التشغيل، ويتم استخدام واجهة البناء عند الرغبة في واجهة أسهل أو أبسط لكائن أساسي.  في مخطط الصنف بلغة النمذجة الموحدة أعلاه، لا يمكن لصنف العميل الذي يتطلب الواجهة الهدف إعادة استخدام صنف المحَوَل مباشرة لأن المحوَل لا يتوافق مع الواجهة الهدف . بدلاً من ذلك، يقوم العميل خلال صنف المحوّل بتنفيذ الواجهة الهدف من حيث المحوَل :  نمط محوّل الكائن في نمط المحوّل هذا، يحتوي المحوّل على مثيل من الصنف الذي يغلّفه. في هذه الحالة، يقوم المحوّل بإجراء استدعاءات إلى مثيل الكائن المُغلّف.  نمط محوّل الصنف يستخدم نمط المحوّل هذا عدة واجهات متعددة الأشكال تقوم بتنفيذ أو توريث كل من الواجهة المتوقعة والواجهة الموجودة مسبقًا. من المعتاد أن تكون الواجهة المتوقعة مُنشئة كصنف واجهة خالصة (صافية)، خاصة في لغات مثل جافا (قبل JDK 1.8) التي لا تدعم توارث الأصناف المتعدد.  يجب أن يدعم صنف صنف مع بعض البيانات، لنفترض وجود بعض البيانات من سلاسل النص. الحل وقت التجميع هو التالي:  classB.setStringData(classA.getStringData());  public class Format1ClassA extends ClassA {  باستخدام «المحوّلات» نحصل على الحل كما يلي:  1. عرّف واجهة «مزود» وسيط، واكتبْ تنفيذ لواجهة المزود تلك التي تغلف مصدر البيانات، في هذا المثال، وتخرج البيانات المنسقة حسب الضرورة: public interface StringProvider {  public class ClassAFormat1 implements StringProvider {  //تلاعب وتحكم بالسلسة النصية في التنسيق المطلوب عن طريق الكائن الذي يحتاج لكائن البيانات 2. اكتبْ صنف محوّل الذي يرجع التنفيذ المحدد للمزود:  public class ClassAFormat1Adapter extends Adapter { 3. سجّلْ المحوّل في سجل عالمي، بحيث يمكن البحث عن المحوّل في وقت التشغيل:  AdapterFactory.getInstance().registerAdapter(ClassA.class, ClassAFormat1Adapter.class, "تنسيق1"); 4. في الكود، عند الرغبة في نقل البيانات من صنف إلى صنف ، اكتبْ:  StringProvider provider = (StringProvider) adapter.adapt(classA); String string = provider.getStringData(); classB.setStringData(string); classB.setStringData( 5. يمكن ملاحظة الفائدة من ذلك، إذا كان من المطلوب نقل البيانات بتنسيق ثاني، فابحثْ عن المحوّل/ المزود المختلف:  6. وإذا كان من المطلوب إخراج البيانات من صنف ، على سبيل المثال؛ بيانات لصورة في :  Adapter adapter = ImageProvider provider = (ImageProvider) adapter.adapt(classA); classC.setImage(provider.getImage()); 7. بهذه الطريقة، استخدام المحوّلات والمزودين يسمح بتعدد «الرؤية» من قبل صنفا و في صنف دون الحاجة إلى تغيير التسلسل الهرمي للأصناف. بشكل عام، ما سبق يسمح بآلية لتدفق البيانات الغير محددة بين الكائنات التي يمكن تعديلها إلى التسلسل الهرمي للكائن الموجود.  عند تنفيذ نمط المحوّل، للتوضيح، يمكن للمرء تطبيق اسم الصنف من صنف إلى واجهة محوّل كالتالي للتنفيذ الخاص بالمزود، على سبيل المثال . يجب أن يكون لديه طريقة المنشئ مع متغير خاص بصنف المحَوَل كمعلمة. سيتم تمرير هذه المعلمة إلى مثيل عضو من (اسم-الصنف) إلى (اسم-الواجهة) للمحوّل كالتالي . عندما يتم استدعاء طريقة العميل، سيتمكن من الوصول إلى مثيل المحوَل الذي يسمح بالوصول إلى البيانات المطلوبة للمحوَل وتنفيذ العمليات على تلك البيانات التي تولد المخرجات المطلوبة.  abstract class FormatIphone  end  abstract class FormatAndroid  end  class Iphone < FormatIphone  end  class Android < FormatAndroid  end  class IphoneAdapter < FormatAndroid  end  class AndroidRecharger end  class IphoneMicroUsbRecharger end  class IphoneRecharger 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 codice_1   interface LightningPhone {  interface MicroUsbPhone {  class Iphone implements LightningPhone {  class Android implements MicroUsbPhone {  /* exposing the target interface while wrapping source object */ class LightningToMicroUsbAdapter implements MicroUsbPhone {  public class AdapterDemo {  مخرجات: codice_2   type  type  type  type  type  procedure RechargeLightningPhone(const ALightningPhone: ILightningPhone); begin end;  procedure RechargeMicroUSBPhone(const AMicroUSBPhone: IMicroUSBPhone); begin end;  procedure TEdijsForm.PatternExampleButtonClick(Sender: TObject); var begin  end;  المخرجات:  codice_3  // Adapter Pattern example  interface IFormatIPhone  interface IFormatAndroid  // Adaptee class IPhone implements IFormatIPhone  // Adapter class IPhoneAdapter implements IFormatAndroid  class Android implements IFormatAndroid  // client class MicroUsbRecharger  $microUsbRecharger = new MicroUsbRecharger();  class IPhoneRecharger  $iPhoneRecharger = new IPhoneRecharger();  class AndroidRecharger  $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 = {  Adapter pattern example. from abc import ABCMeta, abstractmethod  NOT_IMPLEMENTED = "You should implement this."  RECHARGE = ["Recharge started.", "Recharge finished."]  CONNECTED = "{} connected." CONNECT_FIRST = "Connect {} first."  class RechargeTemplate:  class FormatIPhone(RechargeTemplate):  class FormatAndroid(RechargeTemplate):  class IPhone(FormatIPhone):  class Android(FormatAndroid):  class IPhoneAdapter(FormatAndroid):  class AndroidRecharger(object):  class IPhoneMicroUSBRecharger(object):  class IPhoneRecharger(object):  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()