Comments on: The Purpose of Code

By: MarkH

MarkH — Wed, 19 Dec 2012 15:42:19 +0000

Have a look at this book

http://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208

it describes a very similar approach – essentially separation of domain or business logic (in your example, the calculation bit) from the application or contextual logic (the coordination logic) and suggests a consistent approach of how it might be achieved with current programming languages. the motivation is that the two types of logic are likely to change at a very different pace (domain logic slowly, application logic more quickly) and possibly even by different teams, depending on organizational structure of the “sponsor”, so separation should make maintenance less onerous.

By: nathan

nathan — Sat, 15 Dec 2012 22:21:04 +0000

Reblogged this on Nathan.

By: pip010 (@ppetrovdotnet)

pip010 (@ppetrovdotnet) — Mon, 29 Oct 2012 16:30:00 +0000

In reply to Shrutarshi Basu.

no no no, let’s complicate things using over-bloated tech : C# 😛
use anonymous this and that and this and that… 😀

By: mbrandewinder

mbrandewinder — Sun, 28 Oct 2012 19:24:11 +0000

In reply to Shrutarshi Basu.

I had the exact same thought – the overall thinking process described here immediately reminded me of F#, where you typically end up creating modules that expose functions (the “algorithms” part), and then composing them together. You should definitely look into F#!

By: jsonmez

jsonmez — Fri, 26 Oct 2012 13:08:26 +0000

In reply to Christian. I need to check out Go. Been meaning to do it, so much to do, so little time. Thanks for the suggestion.

By: Christian

Christian — Fri, 26 Oct 2012 09:11:27 +0000

I think you could become a big fan of the Go programming language, which promotes such a programming style. There are not even classes that could mislead developers. Static duck-typing helps to keep interfaces clean and simple, because the user of the interface defines it. And in terms of your article, the user defines what interface an algorithm must fulfill.

By: jsonmez

jsonmez — Fri, 26 Oct 2012 00:36:04 +0000

In reply to Tomek. I agree, this is just a simple example, but you are right that that history could be extracted out further.

By: Tomek

Tomek — Thu, 25 Oct 2012 22:12:05 +0000

I think BasicCalculator should not have a hardcoded dependency on History. Instead, it should allow to register listeners and notify them about new results (in Add() method) and about the computation finish (Done() method). The current implementation should be called BasicCalculatorWhichRemembersComputationsHistory. 🙂

By: maz100

maz100 — Thu, 25 Oct 2012 13:14:42 +0000

I agree wholeheartedly. I’d go further and have a calculator that only did calculations and a separate class to manage your session and history. I’d argue that session and history has absolutely nothing to do with an addition algorithm. Then the job of your coordinating method( I use the term orchestrating to mean the same thing) is to call the calculator interface to perform a calculation and then call the session/history interface to increment the session and add the result to the history. A typical service method in my code might need to validate some inputs and then call a database, mapping the results into an object and returning that object. So it’s a case of call a validation interface, call a data access interface and call a mapping interface. If you don’t use interfaces you end up in situations where you can’t test the mapping logic without jumping through hoops to satisfy the validation logic. Great article!

By: Java Programmer

Java Programmer — Wed, 24 Oct 2012 03:18:07 +0000

Isn’t it a kind of Encapsulation? I agree with separating part which changes more often or have potential to be replace with better or faster code. Code organization is an important skill to improve re-usability and I am big fan of Java which enforces such practices.