coupling an object to a procedural style framework 3

[DonQuichote]

I am busy writing a library for digitizers in Visual Basic. My problem is, that the digitizer driver uses API-calls (C-style, with pointers, structures and handles) and I want to design the library in an object-oriented way.

It looks like I have the choice between either making all most of the variables and driver-routines public (within the project, that is) or putting the structures and handles all in one class. I don't like either option, and because of all the handles and structures it is very hard to encapsulate some of the structures in intermediate classes.

Does anyone have an experience with this kind of interfacing?

Best regards

 

[mikewoodhouse]

Of your two options, the second (single class) seems clearly preferable to me. I'd say you were talking about the Facade pattern (

http://c2.com/cgi/wiki?FacadePattern).

At least you get the benefit of an interface being present, behind which the external functions can be hidden.

You might also want to consider applying a slightly 'bent' the Adapter pattern (

http://c2.com/cgi/wiki?AdapterPattern),

which involves converting an interface to something that another app is expecting. The 'bent' bit is that you get to define what you're expecting!

HTH,

Mike

 

[Polu]

Hello, DonQuichote

You could start defining what attributes and methods your package will offer. It use to be a good idea to design an interface as simple as you can in order to fit your requirements. I think that you won't need to show all attributes of every structure but only a few. Try to find what attributes are really needed to be known outside the library and expose them, but encapsulate all others.

The same idea must guide you in designing methods. You will be very lucky if you only need one method called "digitalize" but, unfortunately, it's likely you must write a greater number of methods. Try to minimize the number of attributes and methods that a developer have to be aware to use your library.

In the other hand, internal organization of your library will be as complex as needed, but design it with OO architecture in mind. Be aware of the 'Blob' antipattern!!! It looks like you are near of 'Blobalize' your code!!!

Use only one public class, as simple as you can, and create as many private classes as you need. Well, this is my point of view. I hope it will be useful.

Regards.

Polu.

 

[DonQuichote]

Thanks!

I knew of the blob, but I hadn't heard the word "Blobalize "before. It is a good one to remember! After cleaning up, I realized that I could store most of the handles and structures privately in the driver module.

I was thinking about chopping the driver module into some smaller parts, but it turned out to be too small to be worth the trouble when I finished.

Best regards

 

[Polu]

Well...

English is a foreign language for me, and I need to study a bit more, but I hope all of you can understand me when I say "Blobalize"

Regards, and be happy.

Polu.

 

[nrobin]

I think Mike has some good ideas here. Fundamentally, you need to consider minimising your coupling between your main domain layer and the driver layer. If you do this correctly, you can swap your driver layer for another (you would need to implement some classes for the new layer), and your application that uses the layers you write may never need to be recompiled. I am not sure how VB works, but fundamentally the OO principles are sound. The Proxy pattern is another that achieves similar results to the adapter.

HTH

Nick.