One current benefit of having those classes extensible is the ability to write simple wrappers around KStreamBuilder to add functionality that currently doesn't exist.
In my case, I extend KStreamBuilder mainly to provide syntactic sugar and make it easier to work with. For instance, I overload implementations of some methods, such as .stream(...) to take custom objects that intrinsically define topic names and key/value types, so I don't have to worry about casting to the correct type. I agree that extending those classes is probably not a sound practice, however, absent any kind of interface to implement, it becomes difficult to use a delegate pattern. My proposal would be that if we make those classes final, we should also define actual interfaces that KSteamBuilder and TopologyBuilder implement, so that users could still easily create custom wrappers delegating most methods. An added benefit is that this would also codify the methods that are shared between KStreamBuilder and TopologyBuilder, avoiding the need to manually keep them in sync. Xavier On Sat, Feb 4, 2017 at 11:31 AM Matthias J. Sax <matth...@confluent.io> wrote: > I think the right pattern should be to use TopologyBuilder as a class > member, like new KStreamBuilder will do, instead of a class hierarchy, > in case you want to offer your own higher level abstraction to describe > a topology. > > Why is it important that you can derive a new class from it? > > I am not too strict about about. It's just a suggestion to make it final > to enforce a different usage pattern, that IMHO is better than the > current one. > > > -Matthias > > > On 2/3/17 5:15 PM, radai wrote: > > why is it so important to make those classes final ? > > > > On Fri, Feb 3, 2017 at 3:33 PM, Matthias J. Sax <matth...@confluent.io> > > wrote: > > > >> Hi All, > >> > >> I did prepare a KIP to do some cleanup some of Kafka's Streaming API. > >> > >> Please have a look here: > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP- > >> 120%3A+Cleanup+Kafka+Streams+builder+API > >> > >> Looking forward to your feedback! > >> > >> > >> -Matthias > >> > >> > > > >
