Reputation
43,430
Next tag badge:
205/100 score
16/20 answers
Badges
13 108 195
Newest
 Enlightened
Impact
~1.2m people reached

Jul
1
comment Is testable code better code?
Doesn't really answer your question, but you should keep in mind that good test coverage makes code easier to refactor and refactoring often leads to better code.
Jul
1
awarded  Enlightened
Jun
22
awarded  Good Answer
Jun
16
awarded  Enlightened
Jun
16
awarded  Nice Answer
Jun
15
awarded  Good Answer
Jun
15
awarded  Nice Answer
Jun
15
revised How to quantify the work perfomed by a developer/programmer?
added 8 characters in body
Jun
15
revised How to quantify the work perfomed by a developer/programmer?
added 651 characters in body
Jun
15
revised How to quantify the work perfomed by a developer/programmer?
added 651 characters in body
Jun
15
answered How to quantify the work perfomed by a developer/programmer?
Jun
8
comment A Factory could be replaced by a key on the web.config? How would be the trade-offs of each approach?
Are you sure that it was instead of the factory? It seems to me that you have a factory either way, but one uses the environment name to decide which class to return and the other uses a config setting.
May
27
answered Design patterns for implementing optionally supported features
May
26
comment Design patterns for implementing optionally supported features
I think the point here is that P_User doesn't EXPECT anything of m_p, but if things are provided then it uses them. I don't see how DIP solves that problem.
May
26
comment Design patterns for implementing optionally supported features
I see why it appears that way, but it's not. As opposed to "if this condition, use this type, else if this condition, use another type, etc" this is "if the current protocol supports X, use it; if it supports Y, use it; if it supports Z, use it." The alternative is to have no-op methods in each protocol class and call them all, which is pretty hard to follow at scale. "Can" methods, as you point out, are no different from is and as.
May
26
comment Design patterns for implementing optionally supported features
"it does look suspiciously cumbersome" In what way?
May
24
awarded  Guru
Apr
16
awarded  Nice Answer
Apr
2
comment Is it a bad practice to separate the unit tests for a class?
@AvetisG: People don't have to elaborate on their downvotes and it's unfair to ask them to. But I'll try to help you ... Only the first paragraph here even attempts to answer the question. The rest is an opinion, which some people wouldn't share. I, personally, agree with your opinion but I don't agree with the one paragraph that's relevant to the question, and I don't see the connection you're making. Mike's answer is correct: "Each test class (like any other class) should have a clear focus." That may or may not be the same focus as for your classes under test.
Mar
19
awarded  Nice Answer