Le vendredi 06 avril 2012 à 22:01 +0200, Joachim Durchholz a écrit : > Am 05.04.2012 22:18, schrieb Ronan Lamy: > > 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. > > I don't know whether you or Ashwini is right about what should be an > object and what should be a class in this particular case. > > However, in general, looking at what's a verb and what's a noun is > definitely not a good way to do class design. I haven't used that > particular method of class design in all my 20 years of OO programming > and design, except maybe once in my experimental phase (and quickly > discarded the results because the resulting design was easily improved > by using other criteria). Also, I found that almost any specification > can be rephrased from using verbs to using nouns and back, without > changing the requirements on the implementation; so that's not going to > be very helpful.
What I said only applies to interface design in Python (it might perhaps be generalised to other dynamically typed object-oriented languages, but no further). I might have taken a few shortcuts, but I rest my case. I believe it's uncontroversial that class names should be nouns while function and method should usually be verbs. And while it's always possible to convert most verbs into nouns and some nouns into verbs, some formulations are more natural than others, e.g. "generate the steps" vs "apply the step generator". So if you think about which design will be easiest to explain, it forces a lot of constraints about the design of the interface. > > So what are good criteria? > - If you have a bunch of related data that is connected via consistency > conditions, putting the data into a class and making it private will > make sure that no code erroneously introduces inconsistencies. In Python, "private" is just a matter of convention, so you don't really make sure of anything. But more fundamentally, this relies on having an implementation, so it's definitely relevant for refactoring, but basing an interface on this ties it to the implementation, which isn't a good idea. > - If you need polymorphism (i.e. the "semantically same" function needs > to do different things depending on what the type of the data is that > it's working on). There are alternatives to using a class in such a > situation, and it isn't even rare that they are better. Methods are the one obvious way to do polymorphism in Python. To choose an alternative, you need a clear reason why a method would be unsuitable. > - ... okay, I think there are more criteria, but it's too late and I > don't have the time to cover all aspects of good OO design right now :-) > -- 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.
