Why using manystatic methods in a class
in [C++]
|
From: Keith H Duggar on 14 Apr 2010 03:20 On Apr 14, 3:50 am, Tony Delroy <tony_in_da...(a)yahoo.co.uk> wrote: > On Apr 14, 6:55 am, emitrax <emit...(a)gmail.com> wrote: > > > On 13 Apr, 11:59, Ulrich Eckhardt <eckha...(a)satorlaser.com> wrote: > > > emitrax wrote: > > > > I'm finding myself analyzing a fairly complex system log (library), > > > > where amazingly for me, many classes have lots, or even only, static > > > > methods! > > > > Typical reason: Bad code quality. Some people seem to think "OOP is a must" > > > so they put everything into a class, i.e. abuse classes as mere namespaces. > > > Yes, that's what my colleague and I were wondering. Why not using > > namespaces in > > the first place, if the library has to be used with the following > > syntax > > > STATICCLASSNAME::STATICMETHOD::Method(bla,bla,bla); > > Some people - like John Lakos, author of Large Scale C++ Design or > whatever it's called - have written and used corporate coding > standards that demand classes/structs be used in place of namespaces > precisely because it forces the above usage (not sure if he still > does). You could read that book if you're really keen, but off the > top of my head, some of the kinds of justifications include: > > * by being explicit, the code becomes less context-dependent and hence > (supposedly) easier to debug/maintain > > * avoiding introduction of ambiguity should a name conflict arise in > distinct namespaces "used" by the same code > > * enforcing a reliable association of interface and "physical" files > (as class content can't be declared in multiple files the way > namespace content can). namespace's are not types so in addition to the above * namespaces cannot be used a template arguments so for example cannot be used as "policy" arguments. * namespaces cannot be instantiated and so cannot be passed as arguments to functions. For example a namespace cannot be passed at the comparison functor to the STL sort algorithm. also * namespaces are "open" and therefore can be added to without restriction. This may cry havoc and let slip the dogs of war. For example, according to the standard adding to namespace std is undefined behavior. KHD -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Tony D on 14 Apr 2010 03:45 On Apr 14, 8:18 pm, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > On 14 Kwi, 09:50, Tony Delroy <tony_in_da...(a)yahoo.co.uk> wrote: > > > > STATICCLASSNAME::STATICMETHOD::Method(bla,bla,bla); > > > Some people - like John Lakos, author of Large Scale C++ Design or > > whatever it's called - have written and used corporate coding > > standards that demand classes/structs be used in place of namespaces > > precisely because it forces the above usage > > Note that you can also force the above usage by banning the "use > namespace" construct. > > In other words, today there is no need to abuse the notion of class > (that is, the set of objects sharing common properties) in order to > achieve what name spaces are designed for (that is, to organize > names). That's like saying the private keyword can be replaced by banning people from accessing any variables whose names have a "private_" prefix! Rather, as a library writer, you can force your app-writing clients to use the verbose notation. A ban written in some coding standards is much less practical than utilising the compiler. Cheers, Tony -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Maciej Sobczak on 14 Apr 2010 08:39 On 14 Kwi, 20:19, emitrax <emit...(a)gmail.com> wrote: > > > > STATICCLASSNAME::STATICMETHOD::Method(bla,bla,bla); > > > > Some people - like John Lakos, author of Large Scale C++ Design or > > > whatever it's called - have written and used corporate coding > > > standards that demand classes/structs be used in place of namespaces > > > precisely because it forces the above usage > > > Note that you can also force the above usage by banning the "use > > namespace" construct. > > I don't mean to go OT, but how do you achieve that? > You mean you can prevent the user from using "use namespace > mynamesapce"? "Corporate coding standards" was mentioned above. :-) You can "ensure" that nobody will write "using namespace" to the same extent as you can ensure that people will use classes instead of namespaces. Or you can violate both easily. In both cases it is a matter of agreed convention and from the two I prefer the convention that is aligned with intended usage of the language elements. Note also that verification of such rules is trivial to automate. Especially in a corporate environment. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Maciej Sobczak on 14 Apr 2010 08:40 On 14 Kwi, 20:45, Tony D <anthony...(a)gmail.com> wrote: > Rather, as a library writer, you can force your app-writing > clients to use the verbose notation. A ban written in some coding > standards is much less practical than utilising the compiler. This brings some interesting point. Why should I (or anybody else), as a library writer, care about enforcing the verbosity of notation in the client code? I understand for example banning the copy operations where they could break the library internal state. Or banning the unrestricted instantiation of some class where many instances could similarly corrupt the library. Etc. - whenever there is a benefit for the library integrity, it makes sense to ban the client from doing something. But enforcing the verbosity of notation in the client code? What would be the benefit for the library? What would that protect? The only reason to do so is when the library and the client code are both managed by the same entity (a company) with common development policy, so that you can enforce the client-side policy already at the library level. But that brings you back to coding standards anyway. BTW - no matter how elaborate are you class names in the library, the client will freely use the preprocessor to make them shorter and nicer and look like Python and whatnot. Now try to prevent *that*. :-) -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pete Becker on 14 Apr 2010 15:54
Maciej Sobczak wrote: > On 14 Kwi, 20:45, Tony D <anthony...(a)gmail.com> wrote: > >> Rather, as a library writer, you can force your app-writing >> clients to use the verbose notation. A ban written in some coding >> standards is much less practical than utilising the compiler. > > This brings some interesting point. > > Why should I (or anybody else), as a library writer, care about > enforcing the verbosity of notation in the client code? > Because I can. And besides, it's good for them. I know better than they do what their code should look like. -- Pete Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The Standard C++ Library Extensions: a Tutorial and Reference" (www.petebecker.com/tr1book) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |