Gevşek Birleştirilmiş Kod İçin Arabirimleri Kullanma

Arka fon

Belirli bir donanım aygıtının kullanımına bağlı bir projem var, ancak bu donanım aygıtını yapmam gereken şeyi yaptığı sürece kimin yaptığı önemli değil. Bununla birlikte, aynı şeyi yapması gereken iki cihazın bile aynı üretici tarafından yapılmadığında farklılıkları olacaktır. Bu yüzden uygulamayı ilgili marka / modelden ayırmak için bir arayüz kullanmayı düşünüyorum ve bunun yerine arayüzün en üst düzey işlevselliği kapsamasını sağladım. İşte benim mimarimin şöyle görüneceğini düşünüyorum:

1. Bir C # projesinde bir arayüz tanımlayın IDevice.
2. Cihazı temsil etmek için kullanılacak başka bir C # projesinde tanımlanan bir kütüphanede bir somut var.
3. Beton cihazının IDevicearayüzü uygulamasını sağlayın.
4. IDeviceArayüz gibi yöntemler olabilir GetMeasurementveya SetRange.
5. Uygulamanın beton hakkında bilgi sahibi olmasını sağlayın ve betonu cihazı kullanan ( uygulamayan ) uygulama koduna iletin IDevice.

Bunun bunun için doğru yol olduğundan eminim, çünkü o zaman uygulamayı etkilemeden hangi cihazın kullanıldığını değiştirebileceğim (bazen gerçekleşiyor gibi görünüyor). Başka bir deyişle, betonun uygulamalarının nasıl uygulandığı GetMeasurementveya SetRangegerçekten nasıl çalıştığı önemli değildir (cihazın üreticileri arasında farklılık gösterebilir).

Aklımdaki tek şüphe, hem uygulamanın hem de cihazın somut sınıfının, hem IDevicearabirimi içeren kütüphaneye bağlı olmasıdır . Ama bu kötü bir şey mi?

Cihaz IDeviceaynı ad alanında değilse, uygulamanın cihaz hakkında nasıl bilmesi gerekmediğini de göremiyorum .

Soru

Uygulamam ve kullandığı cihaz arasındaki bağımlılığı çözmek için bir arayüz uygulamak için doğru bir yaklaşım gibi mi görünüyor?

Bence ayrıştırılmış yazılımın nasıl çalıştığını çok iyi anladınız :)

Aklımdaki tek şüphe, hem uygulamanın hem de cihazın somut sınıfının, hem IDevice arayüzünü içeren kütüphaneye bağlı olmasıdır. Ama bu kötü bir şey mi?

Olmasına gerek yok!

Cihaz ve IDevice aynı ad alanında değilse, uygulamanın cihaz hakkında nasıl bilmesi gerekmediğini de göremiyorum.

Tüm bu endişeleri Proje Yapısı ile başa çıkabilirsiniz .

Ben tipik olarak bunu yapmak:

• Tüm soyut eşyalarımı bir Commonprojeye koy . Gibi bir şey MyBiz.Project.Common. Diğer projeler buna referansta özgürdür, ancak diğer projelere atıfta bulunmayabilir.
• Bir soyutlamanın somut bir uygulamasını yarattığımda onu ayrı bir projeye koydum. Gibi bir şey MyBiz.Project.Devices.TemperatureSensors. Bu proje projeye referans verecektir Common.
• Sonra Clientbenim uygulama (benim gibi bir şey MyBiz.Project.Desktop) giriş noktası olan projem var . Başlangıçta uygulama, soyutlama / somut uygulama eşlemelerini yapılandırdığım bir Bootstrapping işleminden geçer . Benim beton örneğini IDevicesgibi WaterTemperatureSensorve IRCameraTemperatureSensorburada, yoksa sonradan benim için doğru beton türlerini örneğini Fabrikalar veya bir IoC konteyner gibi hizmetleri yapılandırabilirsiniz.

Buradaki anahtar şey Client, hem Commonprojenizin hem soyut projenin hem de tüm somut uygulama projelerinin farkında olması gerektiğidir . Özet-> somut eşlemeyi Bootstrap kodunuzla sınırlayarak, uygulamanızın geri kalanının somut türlerden mutsuz bir şekilde habersiz olmasını mümkün kılarsınız.

Gevşek bir şekilde kod ftw :)

Evet, doğru yaklaşım gibi görünüyor. Hayır, özellikle uygulamanın kontrolü sizde ise uygulama ve cihaz kütüphanesinin arayüze bağlı olması kötü bir şey değildir.

Cihazların her zaman arayüzü uygulayamayacağından endişe ediyorsanız, hangi nedenle olursa olsun, adaptör desenini kullanabilir ve cihazların somut uygulamasını arayüze uyarlayabilirsiniz.

DÜZENLE

Beşinci endişenizi giderirken, böyle bir yapı düşünün (cihazlarınızı tanımlamanın kontrolünde olduğunuzu varsayıyorum):

Bir çekirdek kütüphaneniz var. İçinde IDevice adlı bir arayüz var.

Cihaz kitaplığınızda çekirdek kitaplığınıza bir referansınız var ve hepsi IDevice'i uygulayan bir dizi cihaz tanımladınız. Ayrıca farklı türde IDevices oluşturmayı bilen bir fabrikanız da var.

Uygulamanıza çekirdek kütüphaneye ve cihaz kütüphanesine referanslar dahil edersiniz. Uygulamanız artık IDevice arabirimine uyan nesnelerin örneklerini oluşturmak için fabrikayı kullanıyor.

Bu, endişelerinizi gidermek için birçok olası yoldan biridir.

ÖRNEKLER:

namespace Core
{
    public interface IDevice { }
}


namespace Devices
{
    using Core;

    class DeviceOne : IDevice { }

    class DeviceTwo : IDevice { }

    public class Factory
    {
        public IDevice CreateDeviceOne()
        {
            return new DeviceOne();
        }

        public IDevice CreateDeviceTwo()
        {
            return new DeviceTwo();
        }
    }
}

// do not implement IDevice
namespace ThirdrdPartyDevices
{

    public class ThirdPartyDeviceOne  { }

    public class ThirdPartyDeviceTwo  { }

}

namespace DeviceAdapters
{
    using Core;
    using ThirdPartyDevices;

    class ThirdPartyDeviceAdapterOne : IDevice
    {
        private ThirdPartyDeviceOne _deviceOne;

        // use the third party device to adapt to the interface
    }

    class ThirdPartyDeviceAdapterTwo : IDevice
    {
        private ThirdPartyDeviceTwo _deviceTwo;

        // use the third party device to adapt to the interface
    }

    public class AdapterFactory
    {
        public IDevice CreateThirdPartyDeviceAdapterOne()
        {
            return new ThirdPartyDeviceAdapterOne();
        }

        public IDevice CreateThirdPartyDeviceAdapterTwo()
        {
            return new ThirdPartyDeviceAdapterTwo();
        }
    }
}

namespace Application
{
    using Core;
    using Devices;
    using DeviceAdapters;

    class App
    {
        void RunInHouse()
        {
            var factory = new Factory();
            var devices = new List<IDevice>() { factory.CreateDeviceOne(), factory.CreateDeviceTwo() };
            foreach (var device in devices)
            {
                // call IDevice  methods.
            }
        }

        void RunThirdParty()
        {
            var factory = new AdapterFactory();
            var devices = new List<IDevice>() { factory.CreateThirdPartyDeviceAdapterOne(), factory.CreateThirdPartyDeviceAdapterTwo() };
            foreach (var device in devices)
            {
                // call IDevice  methods.
            }
        }
    }
}

Aklımdaki tek şüphe, hem uygulamanın hem de cihazın somut sınıfının, hem IDevice arabirimini içeren kütüphaneye bağlı olmasıdır. Ama bu kötü bir şey mi?

Bunun tersini düşünmelisin. Bu şekilde gitmezseniz, uygulamanın tüm farklı aygıtlar / uygulamalar hakkında bilgi sahibi olması gerekir. Unutmamanız gereken şey, bu arayüzün değiştirilmesinin zaten vahşi doğada uygulamanıza zarar verebileceğidir, bu nedenle söz konusu arayüzü dikkatlice tasarlamanız gerekir.

Uygulamam ve kullandığı cihaz arasındaki bağımlılığı çözmek için bir arayüz uygulamak için doğru bir yaklaşım gibi mi görünüyor?

Basitçe evet

Beton aslında uygulamaya nasıl ulaşır?

Uygulama zamanında beton montaj (dll) yükleyebilirsiniz. Bkz. Https://stackoverflow.com/questions/465488/can-i-load-a-net-assembly-at-runtime-and-instantiate-a-type-knowing-only-the-na

Böyle bir "sürücüyü" dinamik olarak boşaltmanız / yüklemeniz gerekiyorsa, montajı ayrı bir AppDomain'e yüklemeniz gerekir .