Reputation
449
Top tag
Next privilege 500 Rep.
Access review queues
Badges
2 10
Impact
~17k people reached

Jul
21
comment Unknown design pattern
Blog post about mandatory methods in a builder... Refers to answers on SO... jayway.com/2012/02/07/builder-pattern-with-a-twist
Jul
16
comment What is the name of the pattern for passing an incomplete object to a constructor?
a reference to where this term is used would be more convincing in your answer
Jun
22
comment Design Pattern for retry and error handling
You might want to look at Hanmer's Patterns for Fault-tolerant software wiley.com/WileyCDA/WileyTitle/productCd-1118351541.html -- the patterns are generalized (you probably want Rollback, and Limit Retries). They're not OO patterns per se, but they're certainly compatible with JavaScript.
Jun
22
comment Expandable alternative to Visitor pattern for tree traversal?
If the behaviors of the subclasses are the same, it's somewhat exceptional. Why define subclasses that are the same as the base class?
Jun
22
comment Expandable alternative to Visitor pattern for tree traversal?
Design patterns often allow easily extending code. For example, it's easy to add a new Visitor, and the Node classes don't require changes. However, Visitor doesn't tolerate easily changing the Node classes. If you add a new concrete type of Node, that will require a new visit method in all the Visitor classes. See en.wikipedia.org/?title=Visitor_pattern#Diagram as an example. If you add a new Door class to the CarElement hierarchy, you will need to have a visit(Door door) method that needs implementing in all of the visitors.
Jun
19
comment Expandable alternative to Visitor pattern for tree traversal?
There is the Acyclic Visitor pattern described by R. Martin, but it has dynamic_cast, too: objectmentor.com/resources/articles/visitor.pdf
Jun
19
comment Expandable alternative to Visitor pattern for tree traversal?
Visitor allows you to add new functionalities easily as subtypes of Visitor, but doesn't really tolerate new subtypes of Node. Can you give concrete examples of what you want to do? It's hard to give good answers when the question is generalized.
May
26
comment How can I have objects interacting and communicating with each other without forcing a hierarchy?
The problem of allowing classes to collaborate with one another without knowledge of each other is solved by the Mediator design pattern. Have you looked at it?
May
21
comment Is Visitor Pattern valid in this scenario?
What's missing (to me) for Visitor is the class structure that accepts visitors. The motivation for Visitor is that you have many class types in some aggregate that need visiting, and it's not convenient to modify their code for each new functionality (operation). I still don't see what those aggregate objects are, and think that Visitor is not appropriate. If it's the case, you should edit your question (which refers to visitor).
May
21
comment Is Visitor Pattern valid in this scenario?
The GoF Visitor pattern says it "lets you define a new operation without changing the classes of the elements on which it operates." I think RecurringTask is the kind of operation you'd want to add easily, but I fail to see what are the "classes of the elements on which it operates." The only problem you clearly state is "where should I put EmailService?" and that's not a pattern-type problem.
May
7
comment Should I use the State Design pattern for only two states? Also, what if one object's state is affected by another state?
If the logic for changing states is simple, and you only have two states (and don't expect more), then State Pattern might be overdesign. Consider the solution that's simple. It sounds as if you're looking for a problem to solve with a pattern, rather than the other way around. To use another analogy, just because you have a drill in your toolbox, don't go looking for places to put holes in your house.
May
2
comment In MVC, who is in charge of handling observers?
If you use a real object rather than objectA, say engineTemperature, then your view that displays the temperature would surely know what it's displaying. It's normal for views to be coupled to the model elements they display. The other way around, however, is different. engineTemperature should not know how it's being displayed, or who's displaying it, etc. It (as a Subject in the Observer pattern) only knows it has Observers, which all support the Observer API. Have a look at martinfowler.com/eaaDev/uiArchs.html#ModelViewController
May
2
comment In MVC, who is in charge of handling observers?
MVC isn't about total decoupling. It's about avoiding coupling to elements that are unstable. Views tend to be less stable than the model, because they're the UI (users tend to want new ways to view, etc.) E.g. how many times the GUI for Microsoft Word has changed, yet the model of a document has not changed much. Views are directly coupled to the model classes because they're more stable. Model classes are coupled to views via the Observer pattern. The Observer API is very stable, even if the views that implement it are not. So it's OK to have coupling the way you have described it.
May
2
comment In MVC, who is in charge of handling observers?
I disagree with @RobertHarvey in that MVC Views are often Observers of Model classes. The patterns are indeed related; one isn't required to use Observer with MVC, however.
May
2
comment In MVC, who is in charge of handling observers?
We've now coupled the View into the internals of the Model, which I believe violates the Law of Demeter. I'm pretty sure this also violates the concept of MVC by definition. The second point is wrong. Views do know the model. By definition, view code changes more often, so you don't want model code being coupled to it directly. As for Law of Demeter, you'd have to show why you think it violates it. It's not a hard and fast principle, either, despite it's name having the word "Law" in it. It's nearly impossible not to violate it at some point.
Apr
10
comment Is it OK to deprecate methods that need to be public due to the packaging model but are not to be used outside the codebase in Java?
A UML sequence diagram would be helpful to see the flow.
Apr
10
comment Is it OK to deprecate methods that need to be public due to the packaging model but are not to be used outside the codebase in Java?
There's a convention in Eclipse Java to use internal path for having private methods that should not be used by external classes. However, I'm not sure it solves your problem since Message can't be both internal and not (for the methods people should call).
Feb
14
comment Possible way to make java class builder more abstract by using interface required keys
Related blog explaining this builder/required technique: blog.crisp.se/2013/10/09/perlundholm/…
Feb
5
comment How to add permissions checks 'after the fact'
I think this is a great answer because it points out the trade-off between flexibility and the added complexity (obscurity) of a design pattern.
Feb
4
comment One controller to rule them all?
I would also not try to come up with your own way, before checking out recommended ways. Google found me this tutorial: pluralsight.com/training/…