Reputation
7,098
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
3 23 30
Newest
 Guru
Impact
~213k people reached

Jun
25
comment Why do certain sites don't allow Back / Forward / Refresh?
IRCTC? Do you actually mean "IRCTC Online Passenger Reservation System"? Or is this some acronym that I can't find the meaning of?
Jun
25
comment Can too much abstraction be bad?
@CongXu: Btw I have gone at it from the other end: googling for "Bjarne Stroustrup quotes" and have not found a single reference of Bjarne having uttered the "adding another layer of indirection" phrase... Not conclusive of course but does make it highly unlikely he was the first to utter it.
Jun
25
comment Can too much abstraction be bad?
@CongXu: Thanks for the extra links ! Sorry if I sounded a bit curt or terse. I admit I am a bit sensitive when it comes to people using wikipedia as the source of "truth". :}
Jun
24
comment SOLID Principles and code structure
@Euphoric: +1 on your comment. Have you read DIP in the wild? It is a nice discussion and clarifies why DIP <> DI <> IoC
Jun
24
comment SOLID Principles and code structure
@Andy: what helps as well is unit tests defined on the interfaces against which all implementers (any class that can/is instantiated) are tested.
Jun
24
comment SOLID Principles and code structure
+1 but Dependency Inversion <> Dependency Injection. They play well together, but dependency inversion is much more than just dependency injection. Reference: DIP in the wild
Jun
24
comment Can too much abstraction be bad?
@CongXu: While David Wheeler may often be quoted as saying that, do you know for a fact that he was the first to utter this? Or is it possible that Bjarne Stroustrup said it first? And please don't use wikipedia to convince my or anyone else. While it often is right, it just as often is wrong.
Jun
22
comment Two contradicting definitions of Interface Segregation Principle – which one is correct?
The second definition doesn't care about the implementers. It defines interfaces from the perspective of the callers and doesn't make any assumptions about whether implementers already exist or not. It probably assumes that when you follow ISP and come to implement those interfaces, you would, of course, follow SRP when creating them.
Jun
22
comment Two contradicting definitions of Interface Segregation Principle – which one is correct?
Btw: it is not considered "playing nice" to extend your question in this way. I understand in this case because you have fairly long text, but these should really have been comments to my answer.
Jun
22
comment Two contradicting definitions of Interface Segregation Principle – which one is correct?
No of course the client's need don't take precedence over the cohesiveness of an interface. You can take this "rule" way to far and end up with single method interfaces all over the place that make absolutely no sense whatsoever. Stop following rules and start thinking of the goals for which these rules were created. With "classes not following SRP" I wasn't talking about any specific classes in your example or that they were not already following SRP. Read again. The first definition only leads to splitting an interface if the interface isn't following ISP and the class is following SRP.
Jun
22
comment Two contradicting definitions of Interface Segregation Principle – which one is correct?
@user61852: If interface declaration and implementer are in the same unit, I do immediately get a dependency on that implementer. Not necessarily at run time, but most certainly on the project level, simply by the fact that it is there. The project can no longer compile without it or whatever it uses. Also, Dependency Injection is not the same as the Dependency Inversion Principle. You might be interested in DIP in the wild
Jun
21
revised Two contradicting definitions of Interface Segregation Principle – which one is correct?
added 287 characters in body
Jun
21
comment Two contradicting definitions of Interface Segregation Principle – which one is correct?
I so disagree with your assertion that "client" is implementor in SOLID talk. For one it is linguistic nonsense to call a provider (implementer) a client of what it is providing (implementing). I also have not seen any article on SOLID that tries to convey this, but I may simply have missed that. Most importantly though it sets up the implementer of an interface as the one deciding what should be in the interface. And that makes no sense to me. The callers/users of an interface define what they need out of an interface and the implementers (plural) of that interface are bound to provide it.
Jun
21
answered Two contradicting definitions of Interface Segregation Principle – which one is correct?
Jun
21
answered Finally block for methods - is it a bad idea?
Jun
21
answered Storing data in 2 different systems/database structures
Jun
21
comment What's with the aversion to documentation in the industry?
Code can lie. Comments should not say what the code is doing, but what the code is intended to do. The actual code may be wrong and without the comment you won't know whether the code is doing what it is supposed to do or contains a bug.
Jun
19
comment Help me to understand following points about the strategy pattern, how it relates to open/closed principle
+1 though when extending you have to be careful not to violate the Liskov Substitution Principle (LSP) - ie you can't go "against" the class you are extending from.
Jun
17
awarded  Nice Answer
Jun
16
comment How to ask a programmer a question without getting a solution as the answer
+1 Very nice write up of the XY problem.