> I believe that Fowler is correct (today) and incorrect
> (tomorrow).
>
> In SODA (service oriented development of applications) the
> emphasis is reuse and flexibility.
>
> In the past (OO & CBD days), reuse was a utopian dream
> that couldn't be realized. [skipping 5 reasons why] So,
> yes... don't bother with flexibility here...
>
> As we move away from statically compiling applications and
> into orchestrating applications through loosely coupled
> interfaces, it becomes obvious that the services will
> require flexible interfaces.
>
I think it is a question of extent. To what extent do you make your interface flexible? Just because a service interface is often a published interface, one which you can't refactor because you can't fix all client code married to the interface, doesn't mean you don't still have to balance simplicity with flexibility. I think developers should be conservative about the functionality they put into any interfaces, including published ones, because it is hard to predict the future. It is hard to know what flexibility will actually be needed in the future.

One thing you can do with Jini service interfaces that I'm not yet sure how easy it is to do with web service interfaces is evolve them over time. You can make all sorts of binary compatible changes to Jini service interfaces that add functionality without breaking existing clients.

One of the articles I want to publish on this site next year will be an exploration of how to design web services interfaces so they can be evolved. But in the world of Jini, at least, you can refactor published service interfaces. You are not as free as when the interface is not published, but there are all kinds of binary compatible changes you can make without breaking client code.

I also want to publish a web services article next year about contracts, because I believe thinking of interfaces as contracts is an essential part of designing published service interfaces that are changable over time.

Bill - all good points.
You are correct. Just because you can design for the future doesn't mean you have to. And you are correct again, it is a matter of 'extents'.

I would suggest that the extent would be based on the reusability of the platform. Creating applications that allow for reusability through neutralizers (OS, network, platform, language, location) incents one to create reusable code and thus consider designing for reuse. Service Oriented Architectures do this.

IMHO, we have a major shift in how applications will be written. My issue is that the gurus of OO seem to be stuck in OO-Land. When we talk about 'design' issues we must now preface them with an era (Structured, Object Oriented, Service Oriented) - because the rules have changed!
Jeff

>This paragraph reminded me of Ken Arnold's discussion of >the arrogance of taste, which is on this page:
>
>http://www.artima.com/intv/taste.html

I believe Ken is absolutely right, but I'm not sure why he put it in such lukewarm terms. In other words, things need to be spelled out more strongly.

For example, I disagree with his use of the 'painting the house' analogy. I think it's weak and doesn't serve the purpose well. A much better example would be building a house: yes, our customers may have all kinds of preferences when telling us how they want us to build their house, but there are many rock-bottom restrictions which no one's wish should be able to violate. I don't care if the customer promises to pay me extra $100,000.00, if the thing he's asking for is going to endanger the whole project, I'm going to decline him flatly.

I insist that we must adopt the same rigorous approach when designing a software product. Yes, the customers will quite likely demand foolish things from a product we're supposed to deliver, but we know better, and we should straighten them out as soon as the foolish demand arises. Some people may interpret that as being arrogant -- I interpret it as being a professional.

>What I find helpful is bringing all the parties together
>who have an opinion and want to feel included in defining
>the requirements, and get everybody talking about the
>requirements. I explore the requirements space together
>and help them figure out what they want. It is a process
>of exploration and negotiation between all the parties in
>the meeting. I do make suggestions and propose ideas, but
>for the most part the process feels like listening. After
>such a meeting I'll write down what I think we all agreed
>to and send it to everybody who attended the meeting.

I used to practise exactly the same apporach. Then one day I realized that it has the tendency to muddy the issue. What I do now is tell my customers not to involve me until they are absolutely certain what is it that they want to accomplish from the business point of view. That means, they should be able to sit down and hammer out their business requirements on their own, without having to involve computers/software at any point. I give them instructions to imagine they are dealing with the Alladin's magic lamp, so that whenever they feel they have a need for some sort of information service, they just put down something like: 'rub the lamp, the genie comes out, and we tell him what to do'. Everything else should be pure business, nothing to do with the genie, nothing to do with computers.

Then, once they are clear on that, I jump in and address the genie-related issues. I make an assessment as to whether the wishes expressed in there are reasonable, meaning whether the techno-genie can grant them or not. Most of the time, he can.

But *how* is techno-genie going to fulfill their wishes is really none of their business. They only worry about *what* is it they'd like to see as the outcome/externally perceived behavior of the system.

>My intuition is that it might make sense for developers to
>see themselves as nutritionists in the area of technology,
>but not in the area of the client's or employer's business.

Amen.

Alex

Having created many systems based on interfaces and factories, I've come to the conclusion that they are not always appropriate. I see definite a logical link between the flexibility/complexity tradeoff and the use of interfaces. The unconstrained use of interfaces - even when there is no foreseeable future need to ever have more than one concrete implementation - adds non-negligible complexity: extra names and potentially a factory. I would venture to claim that the use of an interface should be evaluated by the same flexibility/complexity criteria as any other issue.

Furthermore, there are certainly times where the use of an abstract base class is desirable - either as the root or as an implementation of the interface that the concrete implementations can extend.

There's an interesting item by the JDOM authors (Jason Hunter and Brett McLaughlin) called: "Why is the JDOM API defined in terms of concrete classes rather than interfaces?" See http://jdom.org/docs/faq.html

An excerpt:
"This issue has been discussed several times on the JDOM mailing list, with several people on both sides. In general, many people feel that a class-based API is better when subclassing is not needed, while an interface-based API is better when subclassing is needed. However, either system can be used in either case.

We started with interfaces actually. During our pre-release review to some peers we received the feedback we should try concrete classes. We did, and the design was much better for it."