search

dehora / nakadi-java

🌀 Client library for the Nakadi Event Broker (examples: http://bit.ly/njc-examples, site: https://dehora.github.io/nakadi-java/)
MIT License
30 stars 19 forks source link

Refactor the library into packages according to their functions #253

Closed ovolynets closed 2 years ago

ovolynets commented 7 years ago

I suggest to refactor the library in a way that the java classes belong to the packages per functionality, something like:

dehora commented 7 years ago

@ovolynets what problems would this refactoring be solving?

ovolynets commented 7 years ago

I would say the greatest benefit would be maintainability for people who are not familiar with the code. When there is one package, it is difficult, at least to me, to figure out where I need to go to debug a possible problem. If the sources were organized by packages, I would probably not check for a portion of the files that do rest mapping, or exception helpers, or similar, just to give an idea.

dehora commented 7 years ago

The problem is that potentially complicates the client for regular end use. Instead of working with the top level package and not having to think about which package contains the object you're looking for (which imo is a tedious thing to deal with in Java libraries and JSRs) users need a bit of extra knowledge (maybe that's fine for frameworks and heavily used standard libs but an API client like this should be pretty minimal). Also keeping things flat means implementation classes can be left package private very easily - if people can see it, they'll use it and it becomes part of the API.

So, the client's layout optimised for ease of use ("don't make me think") and not for maintenance. That said maybe some things could be moved to packages where those package names were relevant to users (eg exceptions) but not organised the way you'd see a typical server codebase broken up.

254 I think can be addressed by having named loggers and not depend on packages.