251 reputation
17
bio website
location
age
visits member for 2 years, 8 months
seen 4 hours ago

4h
comment Design solution for communicating between multiple layers
Can you provide information about layer communication? Is it the Layers architectural pattern (top layers see lower layers but not the other way) or is it more like OSI layers (communication only with adjacent layer(s))?
Nov
29
comment Why do code-bases in n-tier development have an equal amount of, if not more, JavaScript code now?
@gnat I appreciate the feedback. I cited the various parts of the question (namely compiled vs script and imperative vs functional) that weren't answered elsewhere. I've gotten 3 upvotes on this, so I can see it's a mixed reaction.
Nov
19
comment Why do code-bases in n-tier development have an equal amount of, if not more, JavaScript code now?
Would love if the down-voter had the courage to say which part(s) of my answer(s) she didn't like?
Nov
17
comment Generalization of phase based systems for card and board games
This is a hard problem to solve top-down. Make it work for one game, then extend it to another, and another, until it's pretty general. If you make it work for at least two, it's hardly futile.
Oct
28
comment Why bother differentiating between functional and nonfunctional requirements?
+1 for NFRs being tied to architecture. It's harder to make them happen if you don't look at the system as a whole. Performance and fault tolerance are great examples of NFRs that often need to be designed at the system level.
Oct
28
comment Why bother differentiating between functional and nonfunctional requirements?
"only test the functional requirements" -- how about a non-functional requirement that says the "system should tolerate database failures" (good luck not testing that and see how your client likes it). I agree with @gbjbaanb that Nonfunctional requirements (which are usually handled at an architectural level!) are not going to be given to junior team members. Do you understand really what NFRs are?
Oct
16
comment Designing classes the right way
Also, this sounds like it could be homework. If it is, you should say so. meta.stackexchange.com/questions/10811/…
Oct
16
comment Designing classes the right way
You could also do an object-oriented analysis of the problem (a domain model) before you start coding it up.
Oct
16
comment Best Practices To Create Error Codes Pattern For an Enterprise Project in C#
There's the ugliness of not understanding error code 12345 as opposed to a message "Disk full" -- Microsoft Windows updates sometimes fail, and I get error codes as opposed to messages. Googling them is not much help - just did this yesterday for Code 80070103 -- "Get help with this error" is a mess. Perhaps this is more a problem with Microsoft than the error-code approach, but in 2014 I think users shouldn't see error codes.
Oct
5
comment When writing object-oriented code, should I always be following a design pattern?
@Cerad Secular programmers don't use Factories, as they're creationist. Genetic algorithms are OK, though.
Sep
13
comment Design pattern for modifying state and notifying the other modifiers without a loop
What do you mean by "without a loop"? It's not clear in the text of your question.
Sep
13
comment Design pattern for modifying state and notifying the other modifiers without a loop
Standard Observer (GoF) will notify all observers when a state changes, so you'd have to tweak the pattern to fulfill the requirement of prevent[ing] the third party from receiving a notification when itself modifies the state.
Sep
13
comment Design pattern for modifying state and notifying the other modifiers without a loop
Not sure why you say "observers don't know anything about the subject except it is observable." This is not my understanding of the observer pattern. Observers surely DO know about subjects, and it's entirely OK to have that dependency. Observable as a class usually is provided to facilitate subscribing and unsubscribing functionality (it's reusable code, there's a list of observers, etc.).
Aug
2
comment Implementation of strategy design pattern
+1 Other reasons the non-OO (if/else) solution can be bad is that each condition, if it's complex, might require using other objects, thereby creating coupling between Soldier and those other objects. The Strategy approach encapsulates that coupling into the Weapon object. Soldier has less responsibilities (higher cohesion) and is simpler. Also, you're using your improperly as well as it's its sometimes.
Jul
24
comment Should an abstract class always abstract its methods to an interface?
By no example, I mean that a and b are not real classes. Telastyn's answer programmers.stackexchange.com/a/250909/51948 gets to the issue when you consider if there are traits or concreteness. With a real example, you could see. Also, regarding compiler options: Your question says "should it always" -- if there was a yes answer to "always", I'd write my compiler to enforce the rule. Good compilers do push us to do things a certain way when it's really better. Many warnings exist just for this reason.
Jul
24
comment Should an abstract class always abstract its methods to an interface?
Discussions like this without a real example tend to generate more heat than light. If one way really were better, some compiler option/warning wouldn't allow you both ways. Oops - maybe there is such an option?
Jul
24
comment Are Get-Set methods a violation of Encapsulation?
Instead of religiously regarding encapsulation as a kind of commandment, it's better to understand why it's important. Encapsulation is a means to hiding information. That is an old concept that applies to lots of system design (not just OO). It's better to hide details because 1) it make things simpler to the outside, 2) any details that are hidden to the outside can be changed without a negative impact on the outside. So, when a get or set reveals or provides access to information that should be hidden, you're making your design more complex/fragile. There is no universal yes/no answer.
Jul
18
comment Should we avoid using design patterns in constantly changing projects?
@Cornelius Doc Brown said it's hard without concreteness. Requirements going from a word processor to a flight simulator would not be reasonable; no design pattern would help. There's a whole lot of gray area in between his example and, say, adding a new file format to a word processor's Save function (which is very reasonable). Without specifics, it's hard to discuss. Also, it's not that one wouldn't want to change. It's that such changes are difficult, if you already made a design choice early based on a requirement. The word processor vs. flight sim is a great example of early choice.
Jul
18
comment Should we avoid using design patterns in constantly changing projects?
+1, but "or at least better evolvable (that means: easier to be adapted to changing requirements)" -- I'd qualify this with reasonably changing requirements, right?
Jul
18
comment Should we avoid using design patterns in constantly changing projects?
The real problem is constantly changing requirements. No design [pattern] is impervious to that!