- Concrete classes considered harmful - 13 Updates
- Concrete classes considered harmful - 3 Updates
- bind2nd with templates - 1 Update
| Mr Flibble <flibble@i42.co.uk>: Jul 11 04:04AM +0100 Dependencies on concrete classes are considered harmful and should be replaced with dependencies on abstractions. A class should not new its member objects for example but rather should use a factory passed into its constructor. SOLID priniciples can be at odds with performance though as far as C++ is concerned as certain optimizations cannot be peformed if all function calls are via abstract interfaces (virtual functions). Any thoughts on how to square this circle? /Flibble |
| Ian Collins <ian-news@hotmail.com>: Jul 11 03:09PM +1200 Mr Flibble wrote: > Dependencies on concrete classes are considered harmful and should be > replaced with dependencies on abstractions. By whom? > A class should not new its > member objects for example but rather should use a factory passed into > its constructor. Why? -- Ian Collins |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 11 05:11AM +0200 On 11-Jul-15 5:04 AM, Mr Flibble wrote: > is concerned as certain optimizations cannot be peformed if all function > calls are via abstract interfaces (virtual functions). Any thoughts on > how to square this circle? You can do a cost/benefit analysis. Is the added developer time and runtime overhead worth whatever the unmentioned benefit is, for you? If so, use the guideline/principle, but if not, ditch it. A good heuristic, if the benefits are unclear, can be to look at what others do and think, i.e. common practice. Which is, that practically nobody uses the above principle. ;-) Cheers & hth., - Alf -- Using Thunderbird as Usenet client, Eternal September as NNTP server. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 11 06:07AM +0200 On 11-Jul-15 5:25 AM, Stefan Ram wrote: > a concrete class, because its representation is stored outside of > its instances. But according to your terminology, it would be a > »concrete class«, because it implements all it's member functions. On the contrary, Bjarne uses std::vector as an example of a concrete class. Quoting the relevant passage, indirectly from <url: http://programmers.stackexchange.com/questions/221437/concrete-types-as-described-by-stroustrup-c-programming-language-4th-ed>: > Stroustrup, Bjarne (2013-07-10). The C++ Programming Language (4th Edition) > (Section 16.3 Concrete Classes; Kindle Locations 2373-2386). Pearson Education. > Kindle Edition. Note: I find the discussion over on SO perplexing. But then much is perplexing there. It's the #1 Herb Schildt area of the net, AFAIK. Cheers & hth., - Alf -- Using Thunderbird as Usenet client, Eternal September as NNTP server. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 11 02:06AM -0500 Mr Flibble <flibble@i42.co.uk> wrote in news:y42dnfPZC9VKGj3InZ2dnUU78Q- > Dependencies on concrete classes are considered harmful and should be > replaced with dependencies on abstractions. Over-engineering is also considered harmful. > A class should not new its > member objects for example but rather should use a factory passed into > its constructor. Any C++ class with no public data is already at pretty high abstraction level. Virtual interfaces are just one of many abstraction methods which can be used in C++. > is concerned as certain optimizations cannot be peformed if all function > calls are via abstract interfaces (virtual functions). Any thoughts on > how to square this circle? Common sense? |
| JiiPee <no@notvalid.com>: Jul 11 08:28AM +0100 On 11/07/2015 08:06, Paavo Helde wrote: >> Dependencies on concrete classes are considered harmful and should be >> replaced with dependencies on abstractions. > Over-engineering is also considered harmful. agree. As Brarne puts ""simple things should be done in a simple way" >> calls are via abstract interfaces (virtual functions). Any thoughts on >> how to square this circle? > Common sense? As somebody already said, if the speed benefit is not esssential (after proper testing) then making things complicated is not worth of it. |
| Reinhardt Behm <rbehm@hushmail.com>: Jul 11 03:48PM +0800 Paavo Helde wrote: >> calls are via abstract interfaces (virtual functions). Any thoughts on >> how to square this circle? > Common sense? Another quote from from Edsger W. Dijkstra: "Simplicity is prerequisite for reliability." -- Reinhardt |
| Mr Flibble <flibble@i42.co.uk>: Jul 11 05:49PM +0100 On 11/07/2015 04:09, Ian Collins wrote: >> Dependencies on concrete classes are considered harmful and should be >> replaced with dependencies on abstractions. > By whom? Go learn the SOLID principles; anyone who does not know and/or follow SOLID is not a very good engineer IMO. >> member objects for example but rather should use a factory passed into >> its constructor. > Why? Good luck unit testing a class that has lots of dependencies on concretions. /Flibble |
| Mr Flibble <flibble@i42.co.uk>: Jul 11 06:10PM +0100 On 11/07/2015 17:55, Stefan Ram wrote: > more attention to such general OO topics than the C++ crowd. > C++ is more multi-paradigm and is often using generic > programming instead of OO. Yes C++ is multi-paradigm and yes you should be using generic programming just as often as OOP, however OOP is no less important than any other C++ paradigm. *When* performing OOP with C++, SOLID should be followed. My post was intended to solicit opinions on if/when we should ignore SOLID principles for the sake of performance. Should 90% of your OO code follow SOLID as only 10% of your code is critical path as far as performance is concerned? /Flibble |
| Martin Shobe <martin.shobe@yahoo.com>: Jul 11 01:33PM -0500 On 7/11/2015 12:10 PM, Mr Flibble wrote: > ignore SOLID principles for the sake of performance. Should 90% of your > OO code follow SOLID as only 10% of your code is critical path as far as > performance is concerned? I would expect that you'd see much more than 90% if 10% of your code was performance critical and you used SOLID everywhere performance concerns didn't indicate otherwise. But to answer your original question, you'd cease using SOLID to gain performance only when your measurements indicate that you can gain the performance you need to meet your projects requirements. Whether or not you should be using SOLID is another can of worms. Martin Shobe |
| woodbrian77@gmail.com: Jul 11 02:12PM -0700 On Friday, July 10, 2015 at 11:07:29 PM UTC-5, Alf P. Steinbach wrote: > > Kindle Edition. > Note: I find the discussion over on SO perplexing. But then much is > perplexing there. It's the #1 Herb Schildt area of the net, AFAIK. It's kind of a site for control freaks. The site waxed for years and now I think it will be waning. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Ian Collins <ian-news@hotmail.com>: Jul 12 09:17AM +1200 Mr Flibble wrote: >> By whom? > Go learn the SOLID principles; anyone who does not know and/or follow > SOLID is not a very good engineer IMO. Well I certainly know about them and consider them guidelines, not hard and fast rules. If you follow any set of guidelines as if they were gospel, you'll end up like the religious zealots who pop up here from time to time. Oh by the way, I also use int in my code, so I guess by your standards I'm already not a very good engineer. >>> its constructor. >> Why? > Good luck unit testing a class that has lots of dependencies on concretions. I've been unit testing everything I write for over a decade now and I've yet to encounter problems with non-abstract base classes. Go and and learn about mock objects. -- Ian Collins |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 12 12:16AM +0100 On Sat, 11 Jul 2015 04:04:55 +0100 > C++ is concerned as certain optimizations cannot be peformed if all > function calls are via abstract interfaces (virtual functions). Any > thoughts on how to square this circle? Yes, use generics. However, the "D" part of SOLID is contentious and of itself too abstract to be provable: another product of the OOP fad of the 1990s. The C++ standard library is stuffed fully of concrete classes (for good reason), many or most of them templated. Small one purpose concrete classes giving effect to the single responsibility principle, but using generics where necessary, can form an excellent basis for composition. Edsger Dijkstra (needs no introduction): "Object-oriented programming is an exceptionally bad idea which could only have originated in California." Rob Pike (one of the originators of Go and of UTF-8 and a member of the unix team): "Object-oriented design is the roman numerals of computing." Chris |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 11 03:25AM >Dependencies on concrete classes are considered harmful and should be >replaced with dependencies on abstractions. In C++, the term »concrete class« already has a different meaning than assumed above. At least according to Bjarne Stroustrup who explained: »The basic idea of concrete classes is that (...) In many important cases, such as a vector, that representation is only one or more pointers to more data stored elsewhere, but it is present in each object of a concrete class.« So, if I understand Bjarne Stroustrup right, ::std::vector is /not/ a concrete class, because its representation is stored outside of its instances. But according to your terminology, it would be a »concrete class«, because it implements all it's member functions. >A class should not new its member objects for example but >rather should use a factory passed into its constructor. That is a funny pun: You can say »not new its member objects« or »not knew its member objects«, well: »know«. Yeah, I too have heard of »dependency injection«! >is concerned as certain optimizations cannot be peformed if all function >calls are via abstract interfaces (virtual functions). Any thoughts on >how to square this circle? C++ offers you a range of choices from compile-time polymorphism with templates to run-time frameworks with an arbitrary number of indirections. You can square the circle by taking into account additional information about the nature of a project that were not given in you post or by evaluating 4 * atan2( 1, 1 ). |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 11 03:42PM >Another quote from from Edsger W. Dijkstra: >"Simplicity is prerequisite for reliability." "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." ---C.A.R. Hoare, The 1980 ACM Turing Award Lecture |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 11 04:55PM >>By whom? >Go learn the SOLID principles; anyone who does not know and/or follow >SOLID is not a very good engineer IMO. I still remember reading Robert C. Martin ("Uncle Bob"), who invented SOLID, in »comp.object«. That group »comp.object« would possibly be a fine place for your topic, but today it is deserted. Usually the Java crowd, especially the Java EE crowd, pays more attention to such general OO topics than the C++ crowd. C++ is more multi-paradigm and is often using generic programming instead of OO. |
| Paul <pepstein5@gmail.com>: Jul 10 11:38PM -0700 On Friday, July 10, 2015 at 5:27:26 PM UTC+1, Richard wrote: > or data member. (Note that the nested name needn't be a name > introduced by a typedef but it often is. It could be a nested class > or struct or union as well.) Thanks. Now might be a good time to reveal the corrected code. Feedback is welcome. Thanks again, Paul template <typename RandomAccessIterator> // 1st use of typename keyword void quicksort(RandomAccessIterator begin, RandomAccessIterator end) { if (begin != end) { //typedef typename std::iterator_traits<RandomAccessIterator>::value_type // 2nd use of typename keyword iterator_value_type; RandomAccessIterator pivot = std::partition(begin, end, bind2nd(std::less<iterator_value_type>(), *begin)); quicksort( begin, pivot); quicksort((begin == pivot ? ++begin : pivot),end); } } |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment