Design Patterns and Principles

[StevenACoffman]

Many of the workshoppers focus on techniques more than principles and patterns. What does good design look like? How do SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) principles apply to JavaScript? I've seen it applied to Functional paradigm in Clojure, but would appreciate hands on exercises in JavaScript.

[linclark]

Interesting idea.

Do you have any thoughts on how the problems might be set up? What challenge would be posed to the learner, and how would the system determine that they passed?

[StevenACoffman]

I had imagined that selecting an exercise would generate a file that passed some unit tests, but was in dire need of refactoring according to a design pattern or SOLID principle. The problem description would explain the pattern/principle, with some other example code that follows that pattern/principle.

The exercise verify could easily insure that the unit tests still pass. That might be good enough, but it is true that it wouldn't really test adherence to the design pattern or principle (as verify would pass with no modification of the file). Truly testing adherence to a design principle or pattern would require some static analysis with Esprima or something that would be way beyond me. I'm not sure it's necessary, though.

[grabbou]

I think would be nice to cover some patterns described by Andy here http://shop.oreilly.com/product/0636920025832.do. The book is available for free somewhere in the web, but just can't find the link atm. I am only afraid how we can check all of the design patterns speaking implementation wise as lots of them may pass unit tests no matter how they are implemented. Would be actually better to check them all in person which makes it a better choice for hands-on workshop than for a workshopper module.

[kalinchernev]

The book is indeed available for free online, it's the first result on Google for "JavaScript design patterns"