Justin Bozonier suggested I cross-post the following. I originally posted it in the "Flow-Based Programming" discussion group (http:// groups.google.com/group/flow-based-programming):
<cross-post> I´d like to bring to the attention of the community a software design approach called "Flow-Oriented Design" (or Flow-Design (FD) for short). FD has been discussed for about a year in the German C# (and Java) community. It has roots in FBP and other methods revolving around data flows and events. But it differs from most in two regards: -FD is synchronous by default -FD comes with very concrete translations into languages like C# and Java; no framework/runtime is necessary to build FD based programs If you´re interested have a look at the articles in this list: http://bit.ly/dTGlOR It all begins with the introduction at the bottom of it: http://bit.ly/9GbRk1 The latest article sums up the current notation for Flow-Designs: http://bit.ly/i3ASMh Another one will follow to explain different ways to translate designs into 3GL code. Many more pages on the topic are available - but, alas, they are in German. Here´s a page listing Flow-Design resources: http://bit.ly/eFiQex I´m now wondering, if FBP and FD can learn from each other? FD has been taught in quite a few seminars and been presented at developer conferences. As usual there a many sceptics ;-) But practice has already shown the benefit of designing software by looking at processes/flows first instead of data. OOAD might lead to maintainable software - but that´s very hard to accomplish. Flow-Design on the other hand seems to be much more natural and straightforward. Especially if flows are introduced without the need for asynchronous/ parallel processing. I´d be happy to discuss FD with you guys. </cross-post> Flow-Design sets out to help where "traditional" (read: OOAD) object orientation reaches its limits. From the flurry of principles and practices that became all the rage in the past years, we can see, that OO is not manageable "just like that". Millions of programmers fail to grasp it. To me OO thus has not delivered fully on its promises. Yes, it is possible to write correct and maintainable code using OO languages (and maybe some UML on top ;-) But it´s awfully hard. Since I refuse to call millions of programmers dumb who don´t manage to write maintainable code, I´d say the method is wrong (or at least overstrechted). It´s plain wrong to expect from OO and some class diagrams and an occaissonal sequence diagram and some patterns to enable us to develop large maintainable systems. Why´s that? Why should I think such heretic thoughts? Because OO does not get a grip on dependencies. Dependencies are hard to manage using just OO thinking. Several practices and principles are trying to aleviate the situation (IoC, LoD, SoC to name just a few) - but still it´s hard. It´s hard because dependencies are at the heart of OOP. Flow-Design takes another approach. It either does away with dependencies altogether. Or it gets them out of the way by making them implicit. Or it categorizes them properly. Or it makes them very explicit where need be (eg. shared resources). In any case, Flow-Design is not trying to replace OO, but rather reposition it. OO has its place. But that´s not at the forefront of software design. I´ve been working with FD for the past 12 months and I would not want to go back to "traditional" OO or just TDD. One reason is, I was able to change my software development trainings to that TDD is no longer needed as a rigorous dicipline, because with FD functional units become so small just by thinking about the solution, you hardly need TDD to drive out any design. Refactoring has become much easier. And last but not least I don´t need to teach usage of a mock framework like Rhino Mocks anymore. Yes, that´s true: hardly any mocks needed anymore. Looking forward to your questions and suggestions. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
