Reputation
6,774
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
3 21 30
Newest
 Nice Answer
Impact
~177k people reached

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
23
comment Am I doing wrong in my programming learning journey?
@user2212907: no, once you get a little farther into development, provided you take the time to learning the broader technology, you will start to notice all the similarities. Picking up new stuff will go faster and faster because you will recognize the similarities and just hunt for the differences.
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.
Jun
16
answered Is it normal that I can't keep in my head more than three bugs assigned to me, nor can I understand a thousand lines of spaghetti code?
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.