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

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
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
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
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.
Jun
16
comment How to ask a programmer a question without getting a solution as the answer
Because more senior programmers know that most questions asked of them are XY-questions.
Jun
16
comment Object Initializer in C# problem with readability
Ah ok. Yes, I agree that it is not a best practice, in C# or in Delphi.
Jun
16
comment Object Initializer in C# problem with readability
Constructors not protected against exceptions? Wow. This is a huge mental shift for someone coming from Delphi, where an exception thrown in a constructor automatically results in the destructor being called and the var which would have received the reference guaranteed to be nil.
Jun
16
comment Object Initializer in C# problem with readability
+10 (Though SE makes you settle for +1) Thanks for a great concise yet comprehensive tutuorial on this subject.
Jun
15
comment Do all programs run in a loop?
@gnat: yeah, you are right.
Jun
15
comment Do all programs run in a loop?
@gnat: Exactly. The distinguishing factor isn't the interface - commandline or (G)UI - but whether the program is interactive or not.