"David B. Held" <dheld@codelogicconsulting.com> wrote in message news:cnjtn1$ho4$1@sea.gmane.org... | Thorsten Ottosen wrote: | > "David B. Held" <dheld@codelogicconsulting.com> wrote in message | because that is the problem Add() is solving in the first place! Any | refactoring will simply add unnecessary complexity to a problem. I am | arguing that Add(), with its unashamedly numerous arguments, is | irreducibly complex. Any attempt to refactor it will *increase* | complexity, not reduce it through abstraction. I'm just not convinced. | > | Now, in this case, we are looking at functions that only get called | > | from a small number of places (or even just one). Thus, named | > | parameters don't really help any. But the fact is, long argument | > | lists are not intrinsically evil. | > | > are they intrinsically good? | | Is mowing the lawn intrinsically good or intrinsically evil? If you | can confidently answer that question, I know a few philosophers that | would like to talk to you. Some things are amoral, and long argument | lists is one of them. it was you who used the term "intrinsically evil", not me. | > [...] | > 1. pack the values in an object | > 2. send that object along to a function | > 3. unpack the data from the object inside the function | > | > And I guess that is what you think is plain stupid. | | Yes, because you had to either: pack the values into an object having | a c'tor with a lot of arguments (sound familiar?), or you had to create | an object and set the members later, which sounds downright foolish to | merely avoid long argument lists. | > My point has been, however, that once you start making abstractions you | > | > 1. simplify interfaces | > 2. makes it possible to define invariants for your data and hence localize | > error-checks | > 3. adds type-safety to the application | > | > (but I guess we don't have to go through the benefits of OO here.) | | And my point is, in order to implement those abstractions, you very | often encounter the very argument lists that you were trying to avoid!! | In fact, preserving invariants implies that you *need* to do all-at-once | initialization in the c'tor! depends on the invariant, I guess. | > [...] | > So if I were to do it all over, I would probably map my database tables to | > classes instead of passing tuples of strings and intergers around. | | That depends on the application. If the strings and ints make sense | in a class, by all means pack them into a class. But when the data | gets entered the first time, from the "outside world", *someone*, | logically speaking, has to pack that data into a class the first time; | and I don't see anything wrong with that being a single function with | a long argument list. Nothing you have said thus far convinces me | otherwise. I'm not surprised; its pretty hard to convince you :-) -Thorsten