0

I created a library in Scala. It's a parser that comes with different implementations. The trait that abstracts from everything looks something like this (simplified):

trait Parser {
  def parse(in: Array[Byte]): Array[Byte]
}

The concrete parser implementations that are provided by the library extend the trait above (nothing spectacular).

class FastParser(...) extends Parser...
class HighQualityParser(...) extends Parser...

Since I dont want clients to have dependencies on the concrete implementation classes (I even thought about making them package private), I'm using a companion object of the trait which offers access to the parsers without exposing their type:

object Parser {
  def getFastParser: Parser = new FastParser(...)
  def getHighQualityParser: Parser = new HighQualityParser(...)
}

Users should also be able to use their own implementations of the Parser trait if they want to.

However, I'm not sure if this is the best approach.

  • Are there any general disadvantages with this approach?
  • What about hiding the two implementations using access modifiers? From a client perspective, is there a reason to have acces to the implementations?

You may think those are very basic questions about loose coupling and abstraction. This is not necessarily the case, I'm using dependency injection frameworks and similar things all the time myself. However; I've never published a library before and find it quite difficult to provide something that can be used by everyone in a flexible way without being to complicated.

ceran
  • 1,392
  • 1
  • 17
  • 43
  • "From a client perspective, is there a reason to have acces to the implementations?" - since users can implement their own parsers it may make sense to extend the existing ones to avoid duplicating functionality and save some work. – alextsc Sep 29 '16 at 11:11
  • https://di-in-scala.github.io/ - pick one. – Reactormonk Sep 29 '16 at 11:13
  • @alextsc with the risk of their code going broke in case I'll change the implementation, but apart from that I agree – ceran Sep 29 '16 at 11:59
  • @Reactormonk I thought about it but don't see how. Isn't it the task of users to use DI? (As the creator of the library, I'm just providing something, not using it myself). Is there a way I could pre-configure the library for DI-frameworks without forcing users to use them if they don't want to? Or did you mean that in a totally different way? – ceran Sep 29 '16 at 12:02
  • If your implementations have dependencies, some DI framework might need annotations. – Reactormonk Sep 29 '16 at 13:57
  • I don't understand the concern. Primarly you would use a Factory if the constructor would be to complicated or you have dependencies between classes. Iam not sure if I understand it correctly but if you want the users to create their own parsers beside yours. They could easily extend the trait and implement the parser(...) method? Why should you hide the implementation from them? – sascha10000 Sep 29 '16 at 23:25

0 Answers0