Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a front end C# that needs to call a C++ back end. So interop is needed.

I have an "interop layer", that converts the C# data structure into C++ structure, and do all the memory freeing grunt work.

My question is, should I write this interop layer as a static class, or should I wrap it in a normal class and instantiate it as an object when I need to use it?

share|improve this question

migrated from codereview.stackexchange.com Feb 20 '11 at 21:14

This question came from our site for peer programmer code reviews.

1  
@Graviton: This is off-topic for this site. This site is for doing code reviews, which means questions should have code to be looked at. –  Mark Loeser Feb 18 '11 at 13:44
    
programmers.stackexchange.com may be a better site for this question. –  Michael K Feb 18 '11 at 13:59
    
@Mark, I think this question belongs here-- it's all about how the code should be and best practices, so it's a form of code review service that I'm asking about. –  Graviton Feb 18 '11 at 15:27
1  
@Graviton: Then that's what Programmers.SE is for. –  Mark Loeser Feb 18 '11 at 15:50

3 Answers 3

up vote 3 down vote accepted

static (especially static classes) should be avoided as much as possible, IMO. It results in inflexible and hard to test code. A proper normal class would also allow you to do some initialization or cleanup (via IDisposable) if needed, and you could easily switch to an interface to utilize mocking or replace the backend with a managed one.

share|improve this answer

I would definitely go with a non-static class. This allows you to implement IDisposable and clean up your un-managed resources in the way .NET prefers.

share|improve this answer

If you are doing TDD, you might want to read this article from the Google Testing blog.

I really liked the following quote from the article, which summarizes the problem really well:

The basic issue with static methods is they are procedural code. I have no idea how to unit-test procedural code. Unit-testing assumes that I can instantiate a piece of my application in isolation. During the instantiation I wire the dependencies with mocks/friendlies which replace the real dependencies. With procedural programing there is nothing to "wire" since there are no objects, the code and data are separate.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.