How to model apps using declarations (interfaces) only?

This is something I really like doing after I gave the problem some thought. So just creating classes, enums, interfaces, structs, etc to define interfaces in the sense of programming.

But when doing this, obviously the 开发者_StackOverflow中文版compiler complains because I have methods, etc all around with no code inside, so methods that need to return values, etc are flagged.

Now you could say, why compile then? But to me being able to compile and see that your interfaces is compiling is the an important step. Then when you are satisfied, you can add the missing implementations and test your changes.

So my question is, do you do this? If so, how?

What do you think are the pros and cons of this style? Also is there a name for this style of programming?

Notice that though this is different than some other more commonly used way of programming (from what I have seen), where the programmer, starts implementing right away and as he needs more types, etc, he adds them right away or after. But always going forward with implementations.

---

You can compile with all interfaces, no problem.

You can compile structs and classes that use automatic properties ({ get; set; }) and empty void methods.

Methods with return values can be compiled if they throw an exception. For this purpose, throw NotImplementedException. No return statements needed.

By the time you deploy, there should not be any NotImplementedExceptions; any members that do not have implementations by design should instead throw NotSupportedException.

---

why?

I've not personally tried to model an entire solution this way. I typically start with an interface, write tests, and then implement it. As I discover the need for dependencies, I write interfaces so that I can mock them in my tests.

Once that class is implemented using only interfaces, I begin to write tests for and implement the interfaces that I had to write to support the first class, then repeat this process until I've implemented everything.

---

This is extremely similar to what's normally called "mocking". The one difference is that in mocking, a mock class is created specifically for test purposes. The mock object doesn't even attempt to carry out the functions of the real object. In some cases it just includes enough of a body to let the code compile so you can play with the interface. More often, it includes some test code to verify the interface (e.g., check that requirements of the real interface are being met, even though it does nothing else with the values). Just for a really trivial example, a mock sqrt routine might simply verify that its argument is >= 0.0.

---

It's quite easy to do with the built-in class designer in VS.

When adding classes/methods/properties/... it generates compilable code stubs for everything.

The pretty picture is bonus.

This quit usable when designing (part of) the Model. You don't want to use this for GUI or DAL layers.