Converting Spring abstract factory pattern to scala

Question

In Spring I have a controller, a service interface which provides the methods this controller can access. The controller invokes various implementation methods of the service.

To acheive same 'seperation of design' in scala is this the correct implementation : Define the scala controller, define a scala trait which acts as the service interface. Define a new class which extends this trait and provides the implementations of the service. The controller will then instatiate this new class and call the various methods implementations of the service methods.

Is this good design or how Spring MVC is used in practice ?

Answer 1

"Good design" is quite subjective and the meaning of "good design" changes over time for each programmer. There are a few things that most people consider best practices, yet even best practices have conflicts. My personal opinion is that a programmer should continue to learn these best practices and more importantly keep molding his code until it reaches the best shape for that situation. That point however, where it's the 'best' shape keeps changing as the programmer keeps learning.

I can not tell you what "good design" design is in your case as I don't know the situation. On top of that, I am not you, so my "good design" is not the best for you. I would suggest you find it yourself with the help of some questions:

• Who are you programming for?
• How long will your code live?
• Who will maintain your code?
• Do you want to create automatic tests and are you willing to change your design for that?
• Do you need more than one implementation of a single principle?
• What style feels right for you at this point in time?
• How often will the code change?
• Do you want to take the future into account, or only create what is needed right now?
• What libraries do you like to use?
• How much time do you want to spend?

Answer 2

As has been commented by others, 'good design' is a flexible concept depending on other factors. I shall not add to that discussion but offer an overview of our approach instead.

We started with a conventional Java & Spring webapp, although we chose Jersey instead of Spring MVC. Later, we recoded in Scala, which went well. We deliberately kept to a Java-like style Scala - this may be seen as uncool but it works well and is easy to train up new colleagues.

Then we decided to drop Spring, along with its XML and the whole shebang of transitive dependencies. This was easy because we already had a set of services and controllers that were all classes with constructor-injected dependencies (all TDD of course). All we had to do was write a new Bootstrap class that instantiates the services and controllers, supplying the necessary concrete classes in each constructor parameter list. Conveniently, the Bootstrap class is essentially a transliteration of the original Spring wiring into (quite simple) Scala. The Bootstrap class is started from web.xml when the app starts. (This approach will be familiar to anyone who has used Pico Container.)

In our case, we didn't need to use traits much in our service layers; clean design of concrete classes driven by TDD was sufficient. But our approach would also work well with pluggable abstractions for the services, if that were necessary.

Now we have a webapp with no XML except web.xml, purely in Scala so it's easy to navigate and modify, and with far fewer external dependencies. This worked very well for us.