204 reputation
17
bio website
location
age
visits member for 2 years, 3 months
seen 14 hours ago

1d
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?
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
awarded  Citizen Patrol
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?
Apr
19
answered Relative encapsulation design
Mar
29
answered Model-View-Controller: Does the user interact with the View or with the Controller?
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
25
answered Does the Composite design pattern implement recursive behavior?
Mar
23
awarded  Scholar