3

I have a situation where some procedure returns an object (kind of like a DTO) with a certain interface:

interface ISomeInterface
{
    string StringReadOnlyProperty { get; }
    int IntReadWriteProperty { get; set; }
}

(In the real implementation, there are more properties).

There are two different places where these objects are handled - one process that generates new instances, and another process that manipulates existing instances. Internally, these two implementations are very different. The "new" instance is just a stub, and the "existing" instance has lots of tracking logic.

So I need to have this "Stub" implementation kicking around all the time. I was thinking about how nicely Rhino Mocks can stub up implementations of an interface without having to generate a concrete class. Has anyone ever used a "stubbing" mechanism like Rhino Mocks, but in their production code rather than in their unit tests? It just seems like a bad practice, because of the dependency to a testing framework.

Improve this question

2 Answers 2

Reset to default
1

It sounds like the stub is just a cut down version of the main model right?

Maybe "BareBonesObject" contains just enough to create an instance, and "FullObject" carries everything?

Nothing wrong with that kind of scenario.

Using RhinoMocks to save you from writing "BareBonesObject" seems like a code smell and overkill. Is it that much of a pain to write "BareBonesObject"?

Improve this answer
1
  • The interface represents a "scratch-pad" object that holds data in transition, before the user decides to commit the changes. It's closer to the data on the screen (think ViewModel, but without the INotifyPropertyChanged implementation). I think you're right, it's probably worth the effort to create the stub object explicitly, just for simplicity, even if it feels like redundant logic. It would be nice to declare a class like class SomeClass : Stub<ISomeInterface> { } and then be able to flesh out that class later when I need to add more functionality.
    – Scott Whitlock
    Apr 21, 2011 at 13:44
1

Mocking frameworks are generally useful if you need to generate lots of different mock objects for a large amount of different scenarios to test. In this case it appears you just want to have one single stub implementation around. If you just implement that directly (with mock or generated functionality) in it, you can bypass the mocking framework altogether.

Improve this answer
7
  • 1
    In my case, this is a relatively common pattern in my application.
    – Scott Whitlock
    Apr 21, 2011 at 13:25
  • @Scott Whitlock You mean you typically generate lots of different mock objects for all kinds of interfaces? In that case it can be justified to include a framework for it, although I would very carefully inspect how such a framework impacts things such as performance (they tend to do a lot of reflection, which may be expensive).
    – Deckard
    Apr 21, 2011 at 13:31
  • 1
    @Deckard - all this is GUI driven on the client side, so it only has to create objects fast enough to keep up with the user. You're limited by the amount of info you can see on the screen. These are basically scratch-pad objects (non-committed data that the user is working with, before they commit their changes). When they save, the data is transferred to entities. In the case of a "new" object, it's new-ing up an entity, but in the case of existing stuff, it has to track the existing entity, and change it.
    – Scott Whitlock
    Apr 21, 2011 at 13:36
  • 1
    @Scott - have you thought about writing a mini code generator? That's how I would have handled this pattern before the mocking libraries existed, and I personally would be more comfortable with seeing a source file that proves this class is absolutely a stub with no side effects.
    – Steve Jackson
    Apr 21, 2011 at 13:49
  • 1
    @Steve Jackson - as I said in the other comment, what I'm really looking for is a way to write class SomeClass : Stub<ISomeInterface> { } and then come back later and fill in more implementation (if I ever need to). So since I'd potentially want to flesh it out later, I wouldn't be comfortable with a .tt style code generation. @Deckard - it would be nice if the auto-implemented properties that VS generates would just create normal { get; set; } properties rather than throwing NotImplementedException's
    – Scott Whitlock
    Apr 21, 2011 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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