On Sun, Apr 8, 2012 at 2:34 PM, Joachim Durchholz <j...@durchholz.org> wrote:
> Am 07.04.2012 22:04, schrieb Ronan Lamy: > > 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). >> > > My comment applies to interface design in general. > My position is that you cannot infer whether something should be data or a > function from the mere fact that the description you came up initially used > verbs or nouns. Yes, in fact. I think the same design can (most of the times, at least) be implemented with something being used as data as well as a function, without one being superior in design than the other. I guess if properly implemented both can be judged fit. It mostly varies from person to person, IMO. > > 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". >> > > 1) You can always convert a verb to a noun by appending an -izer suffix. > (This applies in any language that can somehow construct and store a > reference to a function and have that function executed later. In OO land, > this is even named as a Design Pattern: Command; it wouldn't be if > transforming verbs to nouns weren't a common need.) > Exactly, it's just a play of words, nouns can be converted to verbs and vice-versa. > > 2) Even if some wording might be more natural in everyday language, this > does not mean it is good program design. If good program design followed > natural speech patterns, every good author would be a good programmer. > In fact, in the above example of "generate the steps" vs. "apply the step > generator", both variants are perfectly equally valid in a programming > context. Each could be MUCH better than the other, depending on > nonlinguistic design considerations - including but not limited to aspects > such as whether we need to transform or combine step generators (MUST be > data), whether we need to decide on a generator strategy long before we > execute the generator (usually SHOULD be data), whether the generation is a > user-visible aspect of the system (preference for whatever the user > naturally expects). 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. > 3) It's often a trade-off between several aspects, many technical, some > linguistic. Most of the time, technical aspects far outweigh the linguistic > ones. > Starting with a single linguistic aspects to guide software design will > massively overvalue them. > > > > So if you think about which design > >> will be easiest to explain, it forces a lot of constraints about the >> design of the interface. >> > > Ah, but your advice was to start the design by applying a linguistic > principle, not collecting constraints. (Typical software engineering goals > are massively overconstrained. The art is to priorize constraints and know > which can be relaxed or dropped with the least overall damage.) > > So if you say "follow the verbs and nouns in the most natural > description", the questions I have are: > What's your argument why linguistic design is the right principle in this > case? > What are the technical constraints, and why are they less relevant in this > case? > What is "most natural" in this situation? How did you make sure it's not > just your usage of language, possibly pre-formed by your mother language, > but indeed the most natural wording? > > "Follow the verbs and nouns" used to be advice on OO design in the early > days of general adoption of OO ideas. > It didn't work very well, and mostly not at all. In the software design > community, it is now generally considered as one item on the long list of > desirables, and not very high on that list. (The top entries are ability to > adapt to change, getting the job done, and a getting interdependent parts > of the code into the same module. Not necessarily in that order.) > > > 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. >> > > Generally adhered conventions are almost as good as language-enforced > rules. > > > > 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. >> > > This design guideline was for those cases where you have an implementation > and try to refactor. > If you're working on the first draft of an interface, this is helpful only > if you already have an implementation in mind. > > If you don't have an implementation in mind, I agree this isn't a very > useful principle. > On the other hand, designing interfaces without thinking about > implementation at all risks defining something that's needlessly hard to > implement. Just as doing design starting with implementation ideas risks > designing something that's too far from the users' thinking to work well > for them. > Finding a middle ground between these two extremes is what makes a good > software designer. > > > - 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. >> > > Most of the time, you need to find all criteria that are relevant, come up > with designs, and then evaluate how each design meets each criterion. > > 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. Regards, Ashwini > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to sympy+unsubscribe@** > googlegroups.com <sympy%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/sympy?hl=en <http://groups.google.com/group/sympy?hl=en>. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
