Reputation
6,913
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
3 22 30
Newest
 Yearling
Impact
~201k people reached

Dec
1
comment Are there any significant disadvantages to depending upon abstractions?
Obligatory statement: "Yagni is only a viable strategy if the code is easy to change"
Nov
21
comment How to mitigate complexity of fallbacks introduced to automatically retry upon failure?
"How can you mitigate some of this complexity?" Abstraction. Your classes look like they have a truckload of tool-specific methods on them (eg ZenDesk and SalesForce). You can write out an entire sync app without ever referring to specific apps and protocols. Advantage is that you can concentrate on the big picture and don't get bogged down by the app/protocol specific details. You put those details in descendant/implementing classes that you instantiate as needed by the specific sync. Bonus advantage: it also allows for a clean path forward when you need to add syncs with other apps.
Oct
27
comment Dependency Injection: Field Injection vs Constructor Injection?
@hstoerr Nice. However, that must mean that Mockito is using reflection (or whatever the Java equivalent of that is called)...
Oct
27
comment Is it a good idea to make method behavior depend on the calling thread?
+1 This should be the accepted answer. Seems to me that this would get you both the "ease of use" (less boilerplate) and explicitness I like.
Oct
27
comment Is it a good idea to make method behavior depend on the calling thread?
Thanks @Brian! Didn't about that feature. Love to learn. And seems to me that this would get you both the "ease of use" (less boilerplate) and explicitness I like.
Oct
26
answered Is it a good idea to make method behavior depend on the calling thread?
Oct
26
comment Better To Call In Dive Into Submethods Or Pass Around a result
Oh and by the way, provided the method names in your actual code make it obvious what is going on, I would prefer option 1 if the steps are fairly independent and may even be optional. This way the recipe for returning and verifying a result is easily understood from OnRequest. Much more so than in option 2, where much of the logic is hidden "downward".
Oct
26
comment Better To Call In Dive Into Submethods Or Pass Around a result
I can understand - sort of - why you would call method2 from method1, but why is verify(result) in method3? Wouldn't it be better if the verification of the returned result was as close to the request as possible, ie in OnRequest, after the call to Method1 that creates it?
Oct
26
comment Better To Call In Dive Into Submethods Or Pass Around a result
+1 My vote goes to making them protected and using a test descendant (your accessor class). It is only a small tweak for testability in the production code as the test descendant itself would only have to live in the test project. (Yes, reflection wouldn't require any tweaks, but I like to keep my test code as independent from reflection as possible).
Oct
26
comment In Scrum, should developers talk directly to customers (bypassing the PO)?
+1 if doing scrum in an agile way, then a business expert would probably be part of the team and available anyway...
Oct
25
answered How to use DAO effectively in my MMO server
Oct
25
answered Dependency Injection: Field Injection vs Constructor Injection?
Oct
25
comment Dependency Injection: Field Injection vs Constructor Injection?
+1 You hit a nerve. I don't like needing reflection or a DI/IoC framework to instantiate a class. It's like driving to Rome to get to Paris from Amsterdam. Mind you I love DI. Just not sure about the frameworks.
Oct
25
comment Initialize in Field, Constructor, or Argument
By the way, I don't see how encapsulation is broken by a parameter being passed in? Yes, there is a problem in the list being shared by caller and callee. Not sure that is what is meant by "breaking encapsulation" though. Encapsulation certainly isn't broken by implementation details leaking out. The class can still decide to use a different implementation of a list regardless of what is passed in, though it would have to change from a simple assignment to something else to accommodate that.
Oct
25
comment Initialize in Field, Constructor, or Argument
What the caller does with the passed in list, is only going to affect you if you use it "as is". When you initialize using the passed in list, but not simply by keeping a reference to it, ie copy the contents or pick and choose what you need, then there is no problem.
Sep
11
awarded  Yearling
Jul
27
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy and where did I say that it was ok to pretend everything is fine? There is a difference between continuing as best you can with restrictions in place, exiting gracefully, and crashing. Boy, do you assume a lot.
Jul
27
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy, Read back my original comments again and then tell me where I am applying dogma. As far as I can tell, I am asking questions. You on the other hand are the one making assumptions and statements based on those assumptions. The only relevant point you made was that the file system is moot when you are logging to a remote db. My counter point would have been that when you are logging remote, the manner in which that log service stores the log messages should not be a concern of the sender It should just call some API. And then for that "logger" machine we are back to the original issue.
Jul
26
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy yes, whether you like it or not, error recovery is part and parcel of developing applications. Out of disk space and programs running out of memory may not occur as frequently as they once used to do, but that doesn't mean they are in the realm of "acceptable to crash over". Rationalization doesn't come into it.
Jul
26
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy out-of-disk space is a normal operating condition, not an exception (even though you may be made aware of it through a run time exception). That is not what I consider a file system failure. A file system failure is when the file system fails to operate at all, regardless of the amount of available disk space.