Specifying interfaces

[jby1]

Hi

I am sure all of this has been dealt with before, but anyway ...

I am about to embark on a new software development project. It is in ASP.NET and C#, and using a SQL Server database. I am intending to use layers in the application:

(1) Presentation layer - Responsible for displaying information to the user, and for handling user input

(2) Business layer - Responsible for implementing business rules

(3) Data Access layer - Responsible for all data storage, retrieval, update etc.

I intend that no layer should have any knowledge of the inner workings of any other, and all interaction should be via well defined interfaces. I feel that this will aid testing and maintenance of the system. I intend to use NUnit to enable Test Driven Development.

I will also use the simplest workable design for my objects, and refactor should the complexity increase and I find that code is getting duplicated, or if things are getting too difficult to understand.

I have read somewhere that one shouldn't use concrete classes between interfaces when using layers like this, and should instead use an Interface (I know, using the same term for different things gets confusing!), and something like an Abstract Factory to pass back implementations of the interface.

However, in many cases I feel that this may add too much complexity to a system, and can be overkill. I can see the benefits to it in other cases though.

Does anybody have any comments on my proposed approach, and also on interfaces between layers?

I am very keen to use good OO practises in my development.

 

[chiph]

You do want to use Interfaces to define an API between layers. Not only will it reduce confusion when you have different people working on different layers, but will ease the ability to test the system.

How?

If you have someone writing the UI, but the middle tier isn't ready yet, you just write a quick & dirty program which implements the Interface that the middle tier is supposed to, and all it does is return a success indication. This is what's called creating a Mock Object.

At the same time, if you're writing the middle tier, but the UI isn't ready yet, you write a quick & dirty program to feed some input into your code.

Another benefit to using Interfaces is when you come out with v2.0 of your product. Each layer will probably need more/different datatypes than the 1.0 version did, so you define another Interface for it, and now your layers can handle callers of either version by responding to the calls thru it's Interface.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[EdwardJS024]

I usually follow a practice where the line that connects two objects should always end with an Interface, I think it was Grady Booch that said this. I see them as flexi joints.

Chip states how it eases testing, and he's right about the "quick and dirty" program that implements the Interface. They are called Mock objects.

If 2 interacting objects will be swappable at some time in the future, Interfaces will alliviate the Rigidity in the system.