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

2d
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.
2d
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.
2d
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!
Jul
11
comment Is this a good practice or not?
@user140149 Team Geek also has great advice about how to constructively deal with conflicts in teams. Perhaps much harder when the team member is one's boss, but maybe you can start by buying him that book -- after you've read it and found it to be AMAZING ;-)?
Jul
8
comment What is a helper? Is it a design pattern? Is it an algorithm?
Searching Google with keywords helper pattern antipattern reveals a lot of controversy. Not sure it needs asking here.
Apr
24
comment Visitor only applicable when using the Composite pattern?
That seems bad. Why?
Mar
29
comment Model-View-Controller: Does the user interact with the View or with the Controller?
The reason views exist as an abstraction is so we can substitute them easily when necessary. A controller for an app on various platforms can be the same, but the views have to recognize user gestures differently and translate them into controller operations. I disagree, therefore, that users interact directly with controllers.
Mar
29
comment Model-View-Controller: Does the user interact with the View or with the Controller?
Views recognize user gestures and translate them to controller actions. Think of Siri on the iPhone or the Kinect on the Xbox. Of course, clicking a button in the GUI is a gesture, too, albeit very easy to recognize.
Mar
28
comment Alternatives to inheritance on complex structures?
This would make sense if there is some client method in all the controllers that is similar to operation() in the Decorator pattern. My experience with controllers is limited, but I am not sure this exists.
Mar
28
comment Alternatives to inheritance on complex structures?
Favor composition over inheritance is a design principle.
Mar
22
comment How to use the Decorator pattern to add little functionality to big objects?
+1 for stating the cohesion problem (too many responsibilities is 15 methods) and using interfaces.
Mar
22
comment OOP what is meant by object-to-object communication
Check out Pebble for a somewhat complex domain model of a blog system. Not saying it's good or bad, but it might give you some ideas of what behaviors exist in the objects in this domain.
Mar
22
comment Inverse of Extract Interface refactoring
I found this blog that speaks of Merge Interface and Implementation (and it's spot-on to the gist of my question). It also states that no popular IDEs offer this refactoring, which also kind of answers my question at the same time. @david.pfx I recommend you submit your remark as an answer.