On 07/05/16 11:35, Ian Clarke wrote: > Hey Martin, > This sounds like a great idea. Classes should only require the dependencies > they > actually need, partially because it makes unit testing much easier, as you > point > out. > So if a large node object is being passed to classes that only use a small > part > of that object, then it's definitely an architectural problem (it's been a > very > long time since I delved into the codebase). The node option is basically > functioning as a static dependency. > If the solution is a publish-subscribe architecture, then one option you might > look at is Guava's EventBus, it is designed for exactly this purpose: > https://github.com/google/guava/wiki/EventBusExplained > Another way to avoid this kind of architectural problem is to use a dependency > injection framework like Guice (older but more widely used) or Daggar (newer > and with faster startup time and better on mobile). > For anyone interested in avoiding this kind of software architecture mistake, > and many other mistakes, I highly recommend the book “Clean Code” by Robert C. > Martin. It's full of great ideas and best practices for architecting code (not > Java-specific, but most of the examples are Java). > Ian.
I am concerned that if we use Martin's approach directly we could end up with another layer of indirection for little purpose. That is, DMT Message's come in, and then we convert them to events on a 1:1 basis, and then... If so, it would be better just to subscribe to Message's in the first place! And furthermore the existing infrastructure *does do that*... At the moment, most of that level of the node *does* subscribe to Message's via MessageFilter's. The MessageCore matches incoming messages to MessageFilter's. NodeDispatcher deals with what's left. Unfortunately, "what's left" is quite big! Maybe we should replace NodeDispatcher with a series of more general subscriptions in the relevant parts of Freenet? There would be some redundant checking. There would still need to be a class which hooks incoming requests and starts them. Announcements could indeed be handled by OpennetManager directly. On the other hand, if Martin's approach is taken carefully, with only the relatively obscure, rare events such as IP re-detection, that may make more sense. His two examples were: 1) IP re-detection after setting a PeerNode's incoming detected IP address. This is unnecessary; the method on the PeerNode could just as easily call the redetect method. 2) Starting an announcement. OpennetManager could subscribe directly? > > > > > > On Sat, May 7, 2016 5:10 AM, Martin Byrenheid martin.byrenh...@tu-dresden.de > wrote: > Hello everyone, > > > > > I've spend some time thinking about how to make it easier to test Freenet's > > different subsystems, especially without having to instantiate the whole > > Freenet Node class for almost every test. One possibly helpful idea that came > > to my mind is to decouple classes by using a publish-subscribe mechanism, > > where each instance can subscribe to events (e.g. received a new announcement > > request) and publish other events together with corresponding data (e.g. the > > message and the neighbor node where the request came from). This way, many > > subsystems could then trigger methods in other subsystems without having to > > know them directly and also might not need a reference to the Node class > > anymore, making them much easier to test. > > > > > I've integrated some examples within the NodeDispatcher-class and pushed it > > into my Github repository [1]. Due to its rather high level of abstraction, > > the publish-subscribe mechanism handles all attached data just as objects, > > which is not nice regarding type safety. However, I haven't yet found a better > > solution since I don't have much experience with Java and I first want to hear > > your opinion about this approach. > > > > > Martin > > > > > [1] > > https://github.com/yadevel/fred/commit/f4ce1b066ad673b995ea2a729ba21b2a7e932e5b > > _______________________________________________ > > Devl mailing list > > Devl@freenetproject.org > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > Ian Clarke > Founder, The Freenet Project > Email: i...@freenetproject.org > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
