Thanks all for the feedback. I didn't think I messed up so much but anyway I have to find a way to improve everything. I knew patterns is a risky topic and difficult to handle. Any suggestions to help me improve this talk are much than welcome.
Good talk, but unfortunately beginner level as already mentioned. Little I could take away personally. Yet, good examples, and covered the most important patterns.
I agree with the comments above about the beginner level. Maybe adding 'beginners' or something like that in the title of the talk would prevent people from being disappointed.
Didn't like the font of the slides too.
I have mixed feelings with this talk. It was definitely aimed at beginners with little to no experience with design patterns. I think the general approach to the subject is actually quite good, but the content could use a little bit of work. I think that the delivery was excellent.
As far as the content:
I feel that the treatment of the Facade pattern left a lot to be desired. The way it was described by Hugo personally wasn't bad, but the example showed was not really good for understanding the Facade pattern, down to the point that the way it was presented basically implies that any class is a Facade since it abstracts functionality. The traditional definition of the Facade pattern ( http://sourcemaking.com/design_patterns/facade ) is more that it abstracts a series of other classes, providing a simpler interface. Since the provided "Facade" example only called methods on itself, it really just felt like a regular class, and not abstracting other classes. This created quite a confusing message that I feel did the pattern disjustice. I would have preferred to see other external classes being called to enforce the message that it's abstracting a series of classes, not just functinality...
The treatment of the Adapter pattern ( http://sourcemaking.com/design_patterns/facade ) I also felt left something to be desired. I feel that it should have been made clearer the relationship of adapters to groups of code. The way the example was presented, where the final class depended on an instance of the WeatherServiceAdapter blurs this line further. In a proper Adapter implementation, the adapter adapts one interface to another. Not to itself. So a clearer example may have depended on an implementation of a WeatherService interface, which the adapter resolved. This makes it clear that you're not depending on receiving an "adapter", but an interface that can be an adapter, or a concrete dependency directly. While this may seem like a minor point, I think it's extremely fundamental to the understanding of an Adapter. It converts one *interface* to *another*. So it's an abstraction that neither class (the class you pass it into, and the class/layer it "wraps") should ever know about or depend upon.
I think the Template Method pattern was dealt with quite nicely.
I also feel the Strategy pattern was handled well.
The Decorator pattern I felt missed a bit. The UML that was displayed was basically identical to Bridge, considering that the root element wasn't distinguished that it was an interface, not a class. This made it rather confusing in the context (to me). Additionally, the cons listed for the Decorator also leave a bit to be desired IMHO, as the opposite usually applies (construction becomes easier, and testing becomes easier).
I think the treatment of the Composite pattern was absolutely excellent. The use of the form example I feel fit really nicely and it clearly showed the usefulness of the pattern. In my opinion, it's a pattern that's pretty easy to explain, but quite hard for most people to grasp the benefits. But the way you presented the example, and the pattern was really good, and worked well for me.
I felt that the treatment of the template method was pretty good as well. The only suggestion that I have there is to provide one final example slide bringing it together (showing why it's useful). One thing that I found confusing with the example was the interchange between "file" and "document". The factory's method was "newDocument", but the factory classes were named "ImageFile" and "TextFile". This felt off, as a File is usually a special instance, or a serialization of a document. So perhaps I'm just getting hung up on the names, but something that could be cleared up (again, not a major issue)...
The coverage of Observer was pretty good. The only issue that I had is that you mentioned "Symfony's Event Dispatcher is an Observer". It's not. It's an implementation of the Mediator pattern. It's a very similar concept, but they have very different semantics. The Observer requires listeners to bind directly on the object that raises events. With the mediator, you have a middle layer that handles and "routes" events. An observer couples the object instances together, where the mediator decouples them. Therefore, the Event Dispatcher in Symfony 2 is a mediator by definition.
After comment by Anthony there is not a lot to add. He covered everything perfectly. One thing not about content, but about style of presentation. Even if you notice that you are ahead of schedule - you sould not say that out loud (not to mention repeating it several times).
Interesting topic and overall quite nice presentation. After Anthony's comments I am not going to say anything about the content and focus my comments on the presentation.
At some points it was just a little bit difficult to hear and understand all the words, partly because of the accent, but maybe it would help to try and speak a little bit more clearly. Not a big problem, but something to think about.
Also I think it would be helpful to ask after each pattern if the audience has any questions regarding that particular pattern. I think that would help you connect with the audience a little better. Especially if you are ahead of schedule and have time to answer questions.
Comments
Comments are closed.
really beginner level but well done talk.
Quite confusing, the only thing to appreciate was the composite
Thanks all for the feedback. I didn't think I messed up so much but anyway I have to find a way to improve everything. I knew patterns is a risky topic and difficult to handle. Any suggestions to help me improve this talk are much than welcome.
Good talk, but unfortunately beginner level as already mentioned. Little I could take away personally. Yet, good examples, and covered the most important patterns.
Good talk but as mentioned beginner level. I really liked the examples as it directly makes clear how it works.
I agree with the comments above about the beginner level. Maybe adding 'beginners' or something like that in the title of the talk would prevent people from being disappointed.
Didn't like the font of the slides too.
Diving into Practical Design Patterns in PHP. Great talks for beginners
I have mixed feelings with this talk. It was definitely aimed at beginners with little to no experience with design patterns. I think the general approach to the subject is actually quite good, but the content could use a little bit of work. I think that the delivery was excellent.
As far as the content:
I feel that the treatment of the Facade pattern left a lot to be desired. The way it was described by Hugo personally wasn't bad, but the example showed was not really good for understanding the Facade pattern, down to the point that the way it was presented basically implies that any class is a Facade since it abstracts functionality. The traditional definition of the Facade pattern ( http://sourcemaking.com/design_patterns/facade ) is more that it abstracts a series of other classes, providing a simpler interface. Since the provided "Facade" example only called methods on itself, it really just felt like a regular class, and not abstracting other classes. This created quite a confusing message that I feel did the pattern disjustice. I would have preferred to see other external classes being called to enforce the message that it's abstracting a series of classes, not just functinality...
The treatment of the Adapter pattern ( http://sourcemaking.com/design_patterns/facade ) I also felt left something to be desired. I feel that it should have been made clearer the relationship of adapters to groups of code. The way the example was presented, where the final class depended on an instance of the WeatherServiceAdapter blurs this line further. In a proper Adapter implementation, the adapter adapts one interface to another. Not to itself. So a clearer example may have depended on an implementation of a WeatherService interface, which the adapter resolved. This makes it clear that you're not depending on receiving an "adapter", but an interface that can be an adapter, or a concrete dependency directly. While this may seem like a minor point, I think it's extremely fundamental to the understanding of an Adapter. It converts one *interface* to *another*. So it's an abstraction that neither class (the class you pass it into, and the class/layer it "wraps") should ever know about or depend upon.
I think the Template Method pattern was dealt with quite nicely.
I also feel the Strategy pattern was handled well.
The Decorator pattern I felt missed a bit. The UML that was displayed was basically identical to Bridge, considering that the root element wasn't distinguished that it was an interface, not a class. This made it rather confusing in the context (to me). Additionally, the cons listed for the Decorator also leave a bit to be desired IMHO, as the opposite usually applies (construction becomes easier, and testing becomes easier).
I think the treatment of the Composite pattern was absolutely excellent. The use of the form example I feel fit really nicely and it clearly showed the usefulness of the pattern. In my opinion, it's a pattern that's pretty easy to explain, but quite hard for most people to grasp the benefits. But the way you presented the example, and the pattern was really good, and worked well for me.
I felt that the treatment of the template method was pretty good as well. The only suggestion that I have there is to provide one final example slide bringing it together (showing why it's useful). One thing that I found confusing with the example was the interchange between "file" and "document". The factory's method was "newDocument", but the factory classes were named "ImageFile" and "TextFile". This felt off, as a File is usually a special instance, or a serialization of a document. So perhaps I'm just getting hung up on the names, but something that could be cleared up (again, not a major issue)...
The coverage of Observer was pretty good. The only issue that I had is that you mentioned "Symfony's Event Dispatcher is an Observer". It's not. It's an implementation of the Mediator pattern. It's a very similar concept, but they have very different semantics. The Observer requires listeners to bind directly on the object that raises events. With the mediator, you have a middle layer that handles and "routes" events. An observer couples the object instances together, where the mediator decouples them. Therefore, the Event Dispatcher in Symfony 2 is a mediator by definition.
So definitely a talk with a lot of potential.
After comment by Anthony there is not a lot to add. He covered everything perfectly. One thing not about content, but about style of presentation. Even if you notice that you are ahead of schedule - you sould not say that out loud (not to mention repeating it several times).
Interesting topic and overall quite nice presentation. After Anthony's comments I am not going to say anything about the content and focus my comments on the presentation.
At some points it was just a little bit difficult to hear and understand all the words, partly because of the accent, but maybe it would help to try and speak a little bit more clearly. Not a big problem, but something to think about.
Also I think it would be helpful to ask after each pattern if the audience has any questions regarding that particular pattern. I think that would help you connect with the audience a little better. Especially if you are ahead of schedule and have time to answer questions.