Recently, I came across a scenario where I needed to provide a service that internally needed to needed to open a socket connection. Now, socket connection is a resource that needs to be closed when done. I could open and close a connection for every call that user made to the service but that is also not optimal. I needed to give the user a way of using the same connection across multiple calls. In a language like C++ this would have been done by creating a socket connection in the constructor and closing the connection in destructor but we don't have destructors in the java world. In this situation, I found it best to go with the resource block solution. The idea is that user can supply a block to the library. In that block the user will have access to the service in question. Library promises that same underlying resource/resources will be shared across all the calls inside the block. This makes it possible for the library to allocate a resource before invoking the block and clear it afterwards.
Enough of rants, let's see some code:
object MyLibrary {
def apply[T]( cb: (ServiceInterface) => T): Option[T] = try {
val service = new Service
val result = cb(service)
service.shutdown()
Some(result)
} catch {
case _ => None
}
}
trait ServiceInterface {
def serviceMethod1()
def serviceMethod2()
}
class Service private() extends ServiceInterface {
private val connection = openConnection()
def serviceMethod1() = {...}
def serviceMethod2() = {...}
def shutdown() = closeConnection()
}
Ok, lots going on here. Before we take apart the above code let's see how the library can be used
MyLibrary{ serviceInterface =>
serviceInterface.serviceMethod1()
serviceInterface.serviceMethod2()
serviceInterface.serviceMethod1()
.
.
.
}
We don't want client to directly instantiate Service so we make Service's constructor private. We just want the client to know about the service interface, hence we pass a parameter with that signature into the block. The block itself is defined using the apply method on the companion object which provide convenient block invocation syntax i.e. MyLibrary { ...}
In my case I also wanted to make sure that client never receives an exception but gets informed about success or failure using an option, hence the return type of callback is option of T where T is the return type of user supplied block. Returning an option is sort of an important point. We want the user to be able to use a block that returns a value otherwise we'll force user to write a block that work with side effects which is not a good idea. It would have been easier if we could return the exact return type of the block from the library but we can't. That's because we may fail in resource initialization i.e. even before we call the block and this failure possibility needs to be reflected in the return type.
Enough of rants, let's see some code:
object MyLibrary {
def apply[T]( cb: (ServiceInterface) => T): Option[T] = try {
val service = new Service
val result = cb(service)
service.shutdown()
Some(result)
} catch {
case _ => None
}
}
trait ServiceInterface {
def serviceMethod1()
def serviceMethod2()
}
class Service private() extends ServiceInterface {
private val connection = openConnection()
def serviceMethod1() = {...}
def serviceMethod2() = {...}
def shutdown() = closeConnection()
}
Ok, lots going on here. Before we take apart the above code let's see how the library can be used
MyLibrary{ serviceInterface =>
serviceInterface.serviceMethod1()
serviceInterface.serviceMethod2()
serviceInterface.serviceMethod1()
.
.
.
}
We don't want client to directly instantiate Service so we make Service's constructor private. We just want the client to know about the service interface, hence we pass a parameter with that signature into the block. The block itself is defined using the apply method on the companion object which provide convenient block invocation syntax i.e. MyLibrary { ...}
In my case I also wanted to make sure that client never receives an exception but gets informed about success or failure using an option, hence the return type of callback is option of T where T is the return type of user supplied block. Returning an option is sort of an important point. We want the user to be able to use a block that returns a value otherwise we'll force user to write a block that work with side effects which is not a good idea. It would have been easier if we could return the exact return type of the block from the library but we can't. That's because we may fail in resource initialization i.e. even before we call the block and this failure possibility needs to be reflected in the return type.
