| JiiPee <no@notvalid.com>: Feb 17 10:57PM I have had this many times that I have some global (or static) non-class function which I want to get access to a certain class but not its private members. Just to illustrate (not a perfect example..): class Human { public: string getName(); protected: int getID() const; private: string m_name; int m_ID; /// humans id }; So lets say I do not want to expose at all the ID here for some reason. But I want to give a certain global function access to it: bool checkHumansLegalStatus(const Human& human) { // uses getID... int id = human.getID(); ... } So I want only this function to get access to getID but on the other hand I do not want to make if a friend becouse I do not want it to get direct acces to the private data members (then it could also get access to other data members which it does not need). Protected kind of security would be pretty close what would do the job, but there is no "protected friend". What to do? I dont want it to be a friend, to expose ALL privates ... would be nice if C++ had a "conditional friend" .. so I could say which members it can get access to , like here. is there any other way to do this (for a global function)? |
| Ian Collins <ian-news@hotmail.com>: Feb 18 12:05PM +1300 JiiPee wrote: > What to do? I dont want it to be a friend, to expose ALL privates ... > would be nice if C++ had a "conditional friend" .. so I could say which > members it can get access to , like here. In this case, id being (presumably) unique and constant I would make it a public const member. Generally, I've never had this issue, it looks like something that should be addressed in the design. If a friend function only sees a const version of the objects, what harm can it do? -- Ian Collins |
| red floyd <no.spam@its.invalid>: Feb 17 03:12PM -0800 On 2/17/2016 2:57 PM, JiiPee wrote: > would be nice if C++ had a "conditional friend" .. so I could say which > members it can get access to , like here. > is there any other way to do this (for a global function)? You might want to look into the "Attorney" class idiom. http://www.drdobbs.com/friendship-and-the-attorney-client-idiom/184402053 |
| Wouter van Ooijen <wouter@voti.nl>: Feb 16 05:16PM +0100 Op 16-Feb-16 om 10:12 AM schreef Juha Nieminen: > abstraction of your designs and create tests for your modules at > the same time? > Why this hate of TDD? I don't understand. TDD is just a term/word/phrase, nothing to hate or love. What I don't like is the set of 3 rules. (And the implied 4'th rule, that someone who doesn't always use TDD is not a professional.) If that is different from TDD, please interpret my objections (or even hate) as directed to those 3 rules. But if those 3 rules are essential to TDD, yes, *then* I hate TDD. I have no objection to TDD as a suggestion of how to organise your work, alsongside other suggestions like (rapid) prototyping, waterfall (yes!), agile, scrum, peer programming, egoless programming, and a long list of others. As always, the job of an engineer is to choose the right tool for the job at hand. Wwouter van Ooijen |
| Juha Nieminen <nospam@thanks.invalid>: Feb 17 11:26AM > As always, the job of an engineer is to choose the right tool > for the job at hand. I don't think anybody (who knows anything) is claiming that TDD is the silver bullet, the perfect tool for every possible situation. However, when properly used, properly applied, and when rigorously followed, it increases the quality and design of programming projects. It might not test every single potential bug that a program may have (not even nearly), but it catches early on easy mistakes (and often even more obscure ones). The time you "waste" on the TDD part can well be saved in avoiding the bug hunting later on. Also, the design decisions you do in order to make TDD work can pay off all in themselves as well. That's not to say that the program cannot be designed poorly even when using TDD properly. But there's a reason why so many people advocate it. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 17 04:55PM On 17/02/2016 11:26, Juha Nieminen wrote: > the silver bullet, the perfect tool for every possible situation. > However, when properly used, properly applied, and when rigorously > followed, it increases the quality and design of programming projects. Quite the contrary: TDD is anathema to good design. /Flibble |
| Wouter van Ooijen <wouter@voti.nl>: Feb 17 06:57PM +0100 Op 17-Feb-16 om 12:26 PM schreef Juha Nieminen: > the silver bullet, the perfect tool for every possible situation. > However, when properly used, properly applied, and when rigorously > followed, it increases the quality and design of programming projects. When I read these two scentences they seem to contradict each other. PS Uncle Bob *does* claim that TTD is *the* tool to apply to every programming problem. > you do in order to make TDD work can pay off all in themselves as well. > That's not to say that the program cannot be designed poorly even when > using TDD properly. But there's a reason why so many people advocate it. Against those assertions I assert that there is a reason so many people are against it. Wouter |
| Ian Collins <ian-news@hotmail.com>: Feb 18 08:00AM +1300 Mr Flibble wrote: >> However, when properly used, properly applied, and when rigorously >> followed, it increases the quality and design of programming projects. > Quite the contrary: TDD is anathema to good design. How's your critique of Uncle Bob's paper coming along? -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 18 08:02AM +1300 Wouter van Ooijen wrote: >> using TDD properly. But there's a reason why so many people advocate it. > Against those assertions I assert that there is a reason so many people > are against it. The reason is they don't understand TDD or have experienced it done badly. -- Ian Collins |
| Wouter van Ooijen <wouter@voti.nl>: Feb 17 08:11PM +0100 Op 17-Feb-16 om 8:02 PM schreef Ian Collins: >> Against those assertions I assert that there is a reason so many people >> are against it. > The reason is they don't understand TDD or have experienced it done badly. That's your assertion. I assert that they have good reasons. (Of course when you define 'doing it well' as 'when it works' *any* methodology works well....) Wouter |
| Ian Collins <ian-news@hotmail.com>: Feb 18 08:23AM +1300 Wouter van Ooijen wrote: >>> are against it. >> The reason is they don't understand TDD or have experienced it done badly. > That's your assertion. I assert that they have good reasons. Some people will find the process difficult. Whenever I have introduced TDD into a team there have always been some who initially opposed the change and even some who at best grudgingly accepted it once the process has bedded in. I think this comes down to personality type. Some feel uneasy uneasy without detailed planning, others find planning stressful. The same apples to development methodologies. -- Ian Collins |
| Wouter van Ooijen <wouter@voti.nl>: Feb 17 08:32PM +0100 Op 17-Feb-16 om 8:23 PM schreef Ian Collins: > has bedded in. I think this comes down to personality type. Some feel > uneasy uneasy without detailed planning, others find planning stressful. > The same apples to development methodologies. You seem to be more reasonable than the 3-rule evangelists ( http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ). What is in your opinion a good description of TDD? Wouter |
| Ian Collins <ian-news@hotmail.com>: Feb 18 08:54AM +1300 Wouter van Ooijen wrote: > You seem to be more reasonable than the 3-rule evangelists ( > http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ). What is > in your opinion a good description of TDD? I guess that comes from being an early adopter (around 2002) who has lost the evangelical zeal :) I do follow the three rules, along with my fourth rule: 4) You are not allowed to fix any bug without adding a failing unit test. TDD suites my way of thinking. I like to know, as that article says that a minute ago all my code worked! I like just to be able to revert a commit rather than mess with a debugger. I like to know that when I change code I haven't broken it. -- Ian Collins |
| legalize+jeeves@mail.xmission.com (Richard): Feb 17 09:08PM [Please do not mail me a copy of your followup] Wouter van Ooijen <wouter@voti.nl> spake the secret code >PS Uncle Bob *does* claim that TTD is *the* tool to apply to every >programming problem. What I've seen him claim is that he hasn't found anything better than TDD. If you can show him something better than TDD, then he'll be talking about that. If you have something you think is better than TDD, bring it Uncle Bob and get him to champion it. If you can convince Uncle Bob, I'm very interested in hearing about it. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Cholo Lennon <chololennon@hotmail.com>: Feb 17 05:19PM -0300 On 02/17/2016 04:32 PM, Wouter van Ooijen wrote: > You seem to be more reasonable than the 3-rule evangelists ( > http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ). What is > in your opinion a good description of TDD? IMHO that's the problem of TDD: The strict dogmas. I think (at least in my experience) the TDD evangelists (teachers, bosses) are inflexible with the methodology. I prefer guidelines or tips that you can pick/discard if they are useful or not for you. TDD is for me another tool to develop my software, sometimes it can works well, sometimes it doesn't. Regards -- Cholo Lennon Bs.As. ARG |
| Ian Collins <ian-news@hotmail.com>: Feb 18 10:28AM +1300 Cholo Lennon wrote: > my experience) the TDD evangelists (teachers, bosses) are inflexible > with the methodology. I prefer guidelines or tips that you can > pick/discard if they are useful or not for you. That will depend on the coach. None of my teams followed a "strict" (if there is such a thing) XP process, they all adopted the process to fit their people and external processes. In my opinion that is how agile should be, every work environment is different, so there isn't a one size fits all process. The same applies to managing a project with Scrum, no two teams end up with the exact same process. The Dogma goes against the philosophy of agile software development. If I were starting with a new team today, I would would *start out* by following a "strict" process and then adapt. That is the agile way: tweak the process to fit the people, don't force the process on the people. > TDD is for me another tool to develop my software, sometimes it can > works well, sometimes it doesn't. Hopefully more the former! If find something doesn't appear to suit TDD, I tend to have a good look at when I and doing and find out why. -- Ian Collins |
| legalize+jeeves@mail.xmission.com (Richard): Feb 17 09:28PM [Please do not mail me a copy of your followup] Wouter van Ooijen <wouter@voti.nl> spake the secret code >(Of course when you define 'doing [TDD] well' as 'when it works' *any* >methodology works well....) As someone that has introduced TDD to every team I've worked on for the past 10 years, I can pretty quickly tell the difference between someone doing it right and someone doing it wrong. What is "doing it wrong"? Dr. Evil gives a nice example: <http://cdn.meme.am/instances/54444468.jpg> In general, the people I see struggling the most with TDD are the same ones that struggle to make small methods and small classes. They routinely violate SRP and the other SOLID OO design principles. <https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)> When practicing TDD, if your tests start getting complicated, that is a signal being given to you by your code. The tests are telling you that your implementation/design is too complex. Someone who is used to writing long complicated methods and isn't used to following SRP chafes against TDD because it is actively making it hard for them to do what they are used to doing. Psychologically this puts you in a bind. You want to embrace SRP and other SOLID design principles, because everyone knows they are intrinsicly "good". Historically your code doesn't embody those principles, but this hasn't been explicitly brought to your attention or you've rationalized away your violations of those design principles through utility or necessity. TDD is putting your feet to the fire and forcing you to adhere to those principles in practice and not just in theory. Doing this means changing the way you've been writing code. It's uncomfortable. It's painful to write code in the familiar way with TDD because your tests get really complicated and painful to write. I've seen people work their way out of this psychological bind in two ways: 1. Change your coding habits to adhere to the SOLID principles more directly and embrace TDD's ability to keep you honest. 2. Discard TDD and complain about how it makes you write really complicated tests and wastes time. The people I've seen choosing option 2 keep writing long methods and big classes and keep producing code that is very difficult, and sometimes impossible, for their teammates to understand, maintain and enhance. Their productivity remains unchanged. The people I've seen choosing option 1 are initially going slower because they are retraining their mental programming muscles to operate in a different fashion. After they build up their TDD muscles, they end up moving faster than those that chose option 2 because they are able to produce code at the same quality faster or better quality in the same time as those choosing option 2. Here "time" has to be measured across design, develop, test and ship lifecycle of a product/release and not just the "develop" part. The empirical studies on TDD being introduced to teams show similar results to what I've witnessed in my personal experience. Don't like TDD? Fine, don't use it. I would suggest that you try it for real before you decide that it has no merit. I've seen enough people doing it wrong to know that it is difficult for some people to understand what TDD is really asking them to do. It's less about the physical tests than most people think. Trying to convince me that TDD is a waste of time? You'll have to show me how to achieve the same or better results with something else. I've spent more years doing non-TDD development than I have spent doing TDD. I have plenty of experience doing things both ways. My experience has shown me and my immediately coworkers that TDD allows us to ship better code with the same effort. Obligatory comment for wood brain dead 77: shitty shit, shit shit shit. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Wouter van Ooijen <wouter@voti.nl>: Feb 17 11:08PM +0100 Op 17-Feb-16 om 10:08 PM schreef Richard: > If you have something you think is better than TDD, bring it Uncle Bob > and get him to champion it. If you can convince Uncle Bob, I'm very > interested in hearing about it. I'd rather convert the pope to shintoism and the Bush family to atheism than trying to convert Uncle Bob away from his rules. The chance of success seems much higher. The way he is talking he doesn't seem to have much experience in my main field, which is low-level microcontroller embedded real-time programming, so I don't regards his opinion as very relevant to me to begin with, and his dogmatism doesn't make it any better. Still, I think something like TDD can have some use for me in some situations, but 'the three rules' when taken literally are (at least for me) absurd. I like test, I like short code fragments (I don't use classic OO, so I don't mention about classes or methods.) But I also like to think, and write a bunch of test in one go, or a 100+ lines of code in one go. The 'three rules' seem to rule that out (is that a correct interpretation?) so anyone who thinks I should obey them literally to be a professional is, as far as I am concerned, a joke. Of course that doesn't rule out that the method works for some other people. I never did much user interface stuff (I don't think I ever felt the urge to use the MVC pattern, and I haven't touched a database for 30 years) so I am clearly in a different world than most of you :) Wouter van Ooijen |
| Ian Collins <ian-news@hotmail.com>: Feb 18 11:19AM +1300 Wouter van Ooijen wrote: > field, which is low-level microcontroller embedded real-time > programming, so I don't regards his opinion as very relevant to me to > begin with, and his dogmatism doesn't make it any better. My first XP (hence TDD) projects were low-level microcontroller embedded real-time as was my most recent... > code in one go. The 'three rules' seem to rule that out (is that a > correct interpretation?) so anyone who thinks I should obey them > literally to be a professional is, as far as I am concerned, a joke. Let me ask you why you wouldn't obey the rules for say a device driver? I certainly do and for such low level fiddly code I find TDD to be an ideal tool. I like to step through, almost bit by bit, tasks such as setting up device registers. The steps, both conceptually and in code, are small and ideally suited to an incremental test/code/refactor cycle such as TDD. Being close to a pure coding exercise, any objections to TDD and design are irrelevant at this level. -- Ian Collins |
| 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