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 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.

share|improve this question
add comment

2 Answers 2

up vote 0 down vote accepted

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"?

share|improve this answer
    
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 '11 at 13:44
add comment

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.

share|improve this answer
1  
In my case, this is a relatively common pattern in my application. –  Scott Whitlock Apr 21 '11 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 '11 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 '11 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 '11 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 '11 at 13:54
show 2 more comments

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.