Am 10.04.2012 10:42, schrieb Ashwini Oruganti:
Agreed, that's why I chose it to be data, because we need OO in this
framework, else it will be quite tricky to add new rules at a later stage,
and since this is a heuristic, this is quite important.
I can see how extensibility is strongly pushing towards data.
However, this does not necessarily mean OO.
If the functions are isolated enough, you can move them outside of a
class context and place them directly in a data structure. This makes
the design considerably more flexible.
My advice is:
If functions and data are closely coupled, i.e. changing one means you
need to modify all others, then an OO design is better.
If functions can be made independent, then keep them independent and put
them directly into the data structures, without bothering to wrap them
in some class that's just there to satisfy a class structure. This makes
reusing the functions far easier.
A clear reason why some approach is unsuitable demands far too much. It's
a trade-off, not a mathematical proof.
Makes sense. I think I'll add a link to this discussion as a comment in my
application while I figure out the best solution to the framework design,
following the discussion.
Be warned that my views on software design are not universally shared
among SymPy developers, and you'll have to defend your choices.
In other words, give the reasons behind your choices, and stick with
concrete advantages (how does it make future coding/maintenance/testing
easier) instead of buzzwords ("it is OO", "it is Pythonic", or whatever).
Arguing with buzzwords will allow critics to argue with
counterbuzzwords, the discussion reaching nowhere. Concrete advantages
and disadvantages are what move a discussion along.
--
You received this message because you are subscribed to the Google Groups
"sympy" 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/sympy?hl=en.
