+1 on STL conventions, in particular GP over OOP at a certain point (i.e., at least for (potentially) large K, M, N (objects, basic types, algorithms) -- very small (and guaranteed to remain so for eternity) K, M, N are perhaps more open to discussion and compromise) -- I think this is unavoidable if we want to avoid complexity and minimize coupling, otherwise we'd face the M*N problem:"For example, given N sequence data structures, e.g. singly linked list, vector etc., and M algorithms to operate on them, e.g. find, sort etc., a direct approach would implement each algorithm specifically for each data structure, giving N*M combinations to implement. However, in the generic programming approach, each data structure returns a model of an iterator concept (a simple value type which can be dereferenced to retrieve the current value, or changed to point to another value in the sequence) and each algorithm is instead written generically with arguments of such iterators, e.g. a pair of iterators pointing to the beginning and end of the subsequence to process. Thus, only N + M data structure-algorithm combinations need be implemented." // Generic programmingOr even K*M*N problem:"One of the main advantages of the use of generic programming is the significant reduce of code complexity. [...]Among of different programming paradigms the most interesting new paradigm is generic programming. The goal of this style is to reveal the foundations and programming methods of generic and therefore reusable components and libraries. In the terms of Multi-Paradigm theory we use generic programming in those cases when the objects have no or little common structure but the behavior (the methods used on objects) are similar. Using this approach we can greatly reduce the complexity of a software library. For example, if we have a library with n data structures, each with k base type and m algorithms, then using the traditional object-oriented way the complexity of the library is O(k*n*m). Using generic programming this reduced to O(n+m)." // Alternative Generic LibrariesA great concrete, practical illustration is Generic Programming and the Boost Graph LibraryThe object-oriented approach / " If we have M algorithms and N data structures, then we have O(M × N) code to write!"The generic programming approach / "We write O(M + N) code, leaving more time for skiing!"Now, it's true that at some point we still need to identify K, M, N -- I suppose on a very basic level this is where the layers enter. However, the design requirement that we minimize the coupling s.t. ++K, ++M, ++N remains !complex _supersedes_ the identification -- if we have a primary focus on "efficiency, discoverability and transparency, expressiveness, robustness, flexibility, modularity, and portability", we can have living libraries, like Boost. And then the identification of particular K, M, N can happen, say, one millisecond prior to its design and implementation.
Last edited by Polter
on October 22nd, 2011, 10:00 pm, edited 1 time in total.