Le mercredi 04 avril 2012 à 15:48 +0530, Ashwini Oruganti a écrit : > > > On Sat, Mar 31, 2012 at 11:33 PM, Ronan Lamy <[email protected]> > wrote: > Le samedi 31 mars 2012 à 22:52 +0530, Ashwini Oruganti a > écrit : > > > Any more suggestions? > > With meaningful names, it's much easier to see how your design > could be > improved. So: > > * OperationInfo: the "Info" part is obviously meaningless. So > what you > have a concept of "Operation". OK. > > > I'll make the changes in the names. If you have any suggestions, I > would be glad to use that. > > * GenerateStep and PrintStep: these obviously look like > functions, not > objects. However, they have a "Step" element in common. That > looks like > a useful concept, so it should probably be a class... > > > They are not functions, because their implementation for different > operations is different, i.e., how I generate steps for > differentiation will be different from what I'd do to generate steps > in an Integration operation. Hence the object-like design, to make > adding new rules in future easier.
The fact that there are different implementations is irrelevant. To know whether something should be a function or an object, you need to ask yourself whether it's an action or a thing. Here, we clearly have actions, because the names you use are verb phrases. Now, if you want to have different implementations for different operations, there's an obvious solution: make generate_step() a method of the class Operation. Obviously, it should return an instance of a Step class. > For somewhat similar reasons, I want to keep the printing and > generating mechanisms separate. As long as they are implemented in separate functions or methods, they are separate, aren't they? > If its the names of the structures that's bothersome, please feel free > to suggest new and more appropriate names as per the proper naming > conventions The trick is that the names always match our understanding of the problem better than any design does, because we think in words, not in Python, so once we have names that describe clearly what happens, it's the design that must be altered to fit the names, not the other way round. > > * "Ask the user": you mention this several times, but you > never explain > how it works. Generally speaking, you say little of substance > about UI, > except the fact that it exists. If you want to focus on the > backend, > it's fine, but you need to clarify it. > > Since we have to start from scratch for this project, a lot of work > has to go for designing both the backend and frontend. > I am aware of the design requirements, and I have a basic idea about > implementing this, and since this is a heuristic, I would be > implementing a simple basic framework first, and then adding more > features to it. OK, that sounds reasonable. However, I don't see any way to "ask the user" anything in your project. If you only implement a few methods, then users will certainly be able to ask for whatever they want, but it's not clear how your design scenario will be implemented. In its simplest form, I suppose it could just be a short console script interacting with the user via raw_input(). If so, I suggest that you try writing the script now. It would be a very fine illustration of your ideas (and it'd be even better if you can manage to fake some of the things you want to implement). -- 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.
