Skip to main content

Posts

Showing posts with the label design-patterns

How to improve the builder pattern?

Motivation Recently I searched for a way to initialize a complex object without passing a lot of parameter to the constructor. I tried it with the builder pattern, but I don't like the fact, that I'm not able to check at compile time if I really set all needed values.

Design Patterns used in the jQuery library

jQuery is highly focused on the DOM and provides a nice abstraction around it. In doing so, it makes use of various well known design patterns which just hit me yesterday. One obvious example would be the Decorator pattern. The jQuery object provides new and additional functionality around a regular DOM object. For example, the DOM has a native insertBefore method but there is no corresponding insertAfter method. There are various implementations available to fill this gap, and jQuery is one such library that provides this functionality: $(selector).after(..) $(selector).insertAfter(..) There are many other examples of the Decorator pattern being heavily used in jQuery. What other examples, big or small, of design patterns have you noticed that are part of the library itself? Also, please provide an example of the usage of the pattern. Making this a community wiki as I believe that various things people love about jQuery can be traced back to well known design patterns, j

Is it bad practice to make a setter return "this”?

Is it a good or bad idea to make setters in java return "this"? public Employee setName(String name){ this.name = name; return this; } This pattern can be useful because then you can chain setters like this: list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!")); instead of this: Employee e = new Employee(); e.setName("Jack Sparrow"); ...and so on... list.add(e); ...but it sort of goes against standard convention. I suppose it might be worthwhile just because it can make that setter do something else useful. I've seen this pattern used some places (e.g. JMock, JPA), but it seems uncommon, and only generally used for very well defined APIs where this pattern is used everywhere. Update: What I've described is obviously valid, but what I am really looking for is some thoughts on whether this is generally acceptable, and if there are any pitfalls or related best practices. I know about the Builder pattern

Strategy pattern in Symfony2

I'm trying to build simple service for rendering various types of pages. Basic concept is having something like: $somePageType = new PageType(...); $this->get('page.service')->render($somePagetype); ...which would be designed as Strategy pattern . Page types would implement interface with render method and page.service would call it. The problem is I'd like to use Doctrine in page type classes. What are my options here? I'd like to avoid creating service for each of these classes. Is that even possible? Is it possible to make them container aware without being services? Possibly, in the future, some page type might need something more than only Doctrine, so I need to keep in mind also that.