218 reputation
17
bio website
location
age
visits member for 2 years, 6 months
seen 22 hours ago

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.
Oct
5
answered When writing object-oriented code, should I always be following a design pattern?
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
revised Design pattern for modifying state and notifying the other modifiers without a loop
typos, your grammar
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.).
Sep
13
suggested suggested edit on Design pattern for modifying state and notifying the other modifiers without a loop
Aug
2
revised Implementation of strategy design pattern
changed image to editable one via PlantUML
Aug
2
suggested suggested edit on Implementation of strategy design pattern
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
29
awarded  Yearling
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
answered Should we avoid using design patterns in constantly changing projects?