News for hackers. Stuff that matters.
Re:Why bad scientific code beats code following “best practi... by ArkyBeagle on Sunday August 28, 2016 @07:22PM (#12379026)
I've returned recently ( for domain-specific reasons ) to sets of (opaque) god-classes with good interfaces when needed. No state in a god-class is visible except through the interface.

Since the domain requires a great deal of serialization, the interfaces are usually strings over that. In cases, it's even easier to just open a socket to the serialization interface.

So far, I'm able to pub/sub periodic data streams, but it'd be pretty easy to add "wake me when" operators and such.

It forces the use of one central table of names cross callbacks ( which can be grown dynamically ) but it's very, very nice to work with.

YMMV. The domain is instrumentation and industrial control, which just fits this pattern nicely. All use cases can and are specified as message sequences.

Re:Why bad scientific code beats code following “best practi... by flukus on Sunday August 28, 2016 @08:20PM (#12379237)
I've been using the delegation pattern a lot lately as a nice way to combine the best bits of god classes (few dependencies) with the best of SRP (small easy to test parts).

This way A, B, C (and many others) only depends on X, the delegator (which exposes a number of interfaces for practically everything), but X depends on everything and the kitchen sink, X contains no real functionality.

Re:Why bad scientific code beats code following “best practi... by ArkyBeagle on Sunday August 28, 2016 @08:59PM (#12379353)
"Delegator". Now I know what to call it :)