Design pattern per il wrapping della libreria Extern Methods

Question

Design pattern per il wrapping della libreria Extern Methods

#1 da (2 voti)

2

Sto lavorando per creare una libreria C # che includa una DLL C da integrare con il nostro sistema di test. Probabilmente la DLL C ha quasi 100 funzioni a cui è possibile accedere e tutte provenienti dalla stessa DLL. Non ho bisogno di tutte le funzioni in questo momento, ma voglio assicurarmi di essere impostato in una direzione che renda l'implementazione di tutto gestibile.

La DLL "raggruppa" molte delle sue funzioni con scopi diversi per aiutare a creare separazione. Il mio piano era quello di creare una classe che fosse il punto di accesso principale che contiene funzioni generiche e quindi creare classi separate che creano metodi di estensione per la classe generica.

Diciamo che i miei "gruppi" sono:

Generico
Acquisizione
Selezione
L'interazione
Utilità

Vorrei quindi creare la mia classe principale

public class BaseClass
{
    // Generic methods
}

Quindi gli altri gruppi sarebbero ciascuno la propria classe di estensione statica:

public static class AcquisitionClassExtensions
{
    public static int AcquisitionMethod1(this BaseClass b)
    {
        // Access DLL
    }
}

E continua per gli altri gruppi. Questo mi permetterebbe di mantenere la BaseClass come la principale classe di oggetti con cui la DLL sarebbe stata interagita.

L'utente vedrebbe comunque un enorme elenco di metodi durante la visualizzazione di intellisense, ma da una manutenibilità del progetto posso tenere separate le cose. Sono sicuro che mi troverei nei problemi se uno dei metodi di estensione dovesse terminare di aver bisogno di un qualche tipo di tracciato, ma questo è minimo.

C'è un modo migliore per avvicinarmi a questo o mi sto preoccupando di nulla?

Modifica chiarezza:

Il gruppo generico o BaseClass contiene l'accesso di base alla connessione al sistema hardware a cui è destinata la DLL e che manterrebbe lo stato. Gli altri gruppi sono operazioni speciali che possono essere eseguite sull'hardware. L'obiettivo è di aggiungere un nuovo set di funzionalità che può essere aggiunto con i metodi di estensione come gli altri raggruppamenti.

c# design-patterns extension-method

posta lucasbrendel 18.12.2015 - 06:17

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns extension-method

Bug che si presentano con unione sul ramo di rilascio Differenza in endianness tra sistemi operativi [chiuso]

score 2 · Accepted Answer

Suppongo che quando si parla di aggiungere metodi di estensione, si stia pensando di arricchire la funzionalità della libreria C. Vorrei sconsigliarlo, perché una collezione di 100 metodi non è un'interfaccia orientata agli oggetti, e in quanto tale probabilmente non sarà suscettibile all'estensione.

Ora, il concetto di programmazione orientata agli oggetti non è sconosciuto ai programmatori C; in effetti, molti, se non la maggior parte, i sistemi scritti in C hanno un concetto di oggetti, lo fanno semplicemente a modo loro che potrebbe non essere facilmente riconoscibile. Ad esempio:

<stdio.h> file sono, in un certo senso, un costrutto orientato agli oggetti. L'oggetto in questo caso è un struct chiamato FILE .
<fcntl.h> file sono, in un certo senso, un costrutto orientato agli oggetti. L'oggetto in questo caso è nascosto dietro un handle int .
Nell'API di Windows c'è una moltitudine di oggetti, anche nascosti dietro vari tipi di maniglie, il più famoso dei quali è HWND .

Non so se la libreria C che stai usando abbia qualche tipo di nozione orientata agli oggetti come quella sopra, ma molte probabilità sono che lo faccia. Se così non fosse, allora immagino che non ci sia nulla di speciale che tu possa fare, procedi nel modo in cui stavi pianificando. Ma se lo fa, allora lo schema di progettazione che probabilmente ti servirà qui è Wrapper .

Quindi, ciò che dovresti fare, se possibile, è rilevare quali entità orientate agli oggetti sono utilizzate dalla tua libreria e introdurre una classe C # per ognuna di esse. Se stavi creando un wrapper per <fcntl.h> , dovresti creare un class File che contiene un singolo membro, private readonly int handle e offre una serie di metodi che delegano alle funzioni native come read() , write() , ecc passando loro l'handle int contenuto all'interno dell'oggetto.

Quindi, arricchiresti quelle classi con funzionalità aggiuntive, (per ereditarietà o per composizione,) invece di estendere la classe di interfaccia nativa. La cosa migliore da fare con la classe di interfaccia nativa è di tenerlo il più breve possibile e nascosto. ("interno" all'assembly che lo contiene.)

Per ulteriori informazioni, vedi: