519 reputation
15
bio website flexdiary.blogspot.com
location
age
visits member for 1 year, 9 months
seen Jul 9 at 21:15

Mar
20
answered Why should one subclass instead of composite when using the Factory Method design pattern?
Mar
18
comment Do Design Patterns Stifle Creativity
IMO the creativity is in finding an implementation of the pattern that exactly suits your particular problem, plus, on an application-level scale, gluing all those patterns together in a way that's maintainable and somewhat legible.
Mar
18
comment Do Design Patterns Stifle Creativity
But isn't learning about design patterns a great way to see concrete examples of how to think about code? What things would you look at to learn how to think about code if not problems + general solutions that solve the problems and example code that implements the solution?
Feb
6
comment Choosing the right Design Pattern
I agree with @pdr. I think about what I need to do, and remembering the name of the pattern helps me name the Class so others know what it does as well.
Jan
5
comment Scrum decision making versus maintainability and development time?
+1 for sometimes it's true. It's horrible to be on a project with iterative requirements but a waterfall deadline.
Dec
20
awarded  Yearling
Nov
21
comment Static factory vs factory as a singleton
Also, you might want to check out this link about the problems with static methods (even the Math ones!)
Nov
21
comment Static factory vs factory as a singleton
If Foo is meant to be extended, then that right there is a reason for the Factory to be an instance--you provide the correct instance of the factory to give you the correct Subclass rather than calling if (this) then {makeThisFoo()} else {makeThatFoo()} all through your code. One thing that I've noticed about people with chronically bad architecture is that they're like people in chronic pain. They don't actually know what it feels like not to be in pain, so the pain they're in doesn't seem all that bad.
Nov
21
answered Static factory vs factory as a singleton
Nov
21
comment Static factory vs factory as a singleton
I think you've misunderstood that group's use of lowercase singleton (one single instance is created, not a Class that idiotically enforces that there can only be one instance). I find it literally impossible to believe that they'd be as insistent on proper dependency injection as you've described, yet ok with the anti-pattern of capital S Singleton.
Nov
19
answered Interface Dependencies or Abstract Classes
Nov
10
comment The clock problem - to if or not to if?
Since you're already calculating the modulo, why would you do an extra check on it rather than just assigning the result to the value (or parseInt(value/60), where appropriate)? This seems like it's not only mostly unnecessary code, it is also likely to be inaccurate.
Nov
10
comment The clock problem - to if or not to if?
I would think the browser would do the important if checking.
Nov
8
answered Design Patterns - Why the need for interfaces?
Nov
4
comment MVVM and service pattern
Well, certainly it must have the ability to request that a View be made somewhere. But to make it itself? Not in my world :). But then again, in the world I live in, we call VM "Presentation Model."
Nov
4
comment MVVM and service pattern
"Will sometimes" and "should" are two different animals ;)
Nov
4
comment MVVM and service pattern
I think the "right" way to do it is to create a separate layer that calls the services and does whatever casting is necessary to create the ViewModel. Your ViewModels should not be responsible for creating themselves.
Nov
4
comment Dependency inversion always includes dependency injection?
What is the ISomeService doing in the second example?
Nov
3
comment MVC shared model different required fields on different type
Another way to implements this that avoids either the model or the view having any smarts about these differences is to have View subclasses that are used for each car type that are simply ard-coded to act in the desired way. In some circumstances, this can be actually less brittle than trying to write a lot of logic around state in either the model or the View--the only decision to be made is which View to use, which is relatively simple.
Oct
26
comment Is there a pattern to restrict which classes can update another class?
Why not just refuse to give access to the Class to just anybody--anyone who wants to change the data has to make a request of a gateway Class that vets the requests?