400 reputation
213
bio website
location Germany
age 43
visits member for 3 years, 8 months
seen Jun 27 '14 at 18:18

Software Engineer. Mostly Java atm.


Nov
19
awarded  Popular Question
Nov
15
comment Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?
For the records, I chose this answer because it answers the title of the question literally, as well as giving a better alternative. But I found other answers equally as good with this one.
Nov
15
accepted Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?
Nov
15
answered Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?
Nov
15
comment Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?
I quite like your answer. I think it deserves more votes.
Nov
15
comment Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?
+1 in general, and in particular for the "mammoth". LOL!
Nov
15
awarded  Nice Question
Nov
15
revised Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?
Summariesed suggestion proposed in answers
Nov
15
asked Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?
Sep
17
accepted How do you call a “Proxy” that delegates to *several* implementations?
Sep
17
comment How do you call a “Proxy” that delegates to *several* implementations?
And while I agree with your answer (+1), I'll go with Marjan. A Facade doesn't stop being a Facade because it expose the same interface as the objects it delegates to.
Sep
17
comment How do you call a “Proxy” that delegates to *several* implementations?
I don't think Mediator is correct either, because it's goal is to "prevent" the different objects implementing the behavior to "know each other". But in my proposed design, I don't want to prevent FragmentB of knowing FragmentA, I just want to enable FragmentB to exist without knowing the concrete implementation of FragmentA.
Sep
17
asked How do you call a “Proxy” that delegates to *several* implementations?
Sep
15
awarded  Scholar
Sep
15
accepted Is there a specific design strategy that can be applied to solve most chicken-and-egg problems while using immutable objects?
Sep
13
comment Is there a specific design strategy that can be applied to solve most chicken-and-egg problems while using immutable objects?
I'm not actually trying to use "functional language" because I just don't get it! The only thing I normally retain from any non-trivial functional programming example is: "Damn, I which I was more clever!" It's just beyond me how this can make sense to anyone. From my students days, I remember that Prolog (logic-based), Occam (everything-runs-in-parallel-by-default) and even assembler made sense, but Lisp was just crazy stuff. But I do get you point of moving the code that cause a "state change" outside the "state".
Sep
13
comment Is there a specific design strategy that can be applied to solve most chicken-and-egg problems while using immutable objects?
@Rachel Strictly speaking, they aren't proper singletons, and I don't use static, but rather an "object registry" (OSGi). OTOH, this got me thinking. Traditionally, in a tree-shaped data-model, the "parents" know the "children", so the problem is only when the children need to know the parent or siblings. But if the roots of the tree are accessible "from anywhere" (either through static, or the "object registry" in my case, the child can get a reference to anything by traversing the data-model, so that IS a solution (although a complex and expensive one).
Sep
13
awarded  Commentator
Sep
13
comment Is there a specific design strategy that can be applied to solve most chicken-and-egg problems while using immutable objects?
The answer to this other question seem to confirm my suspicion that things get complicated really quickly with immutables: programmers.stackexchange.com/questions/68058/…
Sep
13
comment Is there a specific design strategy that can be applied to solve most chicken-and-egg problems while using immutable objects?
@DeadMG Well, OK. They are not real Java Singletons. I just mean that there is no point to create more than one instance of each, since they are immutable and would be equal to each other. In fact, I won't have any real static instances. My "root" objects are OSGi services.