﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>dotnetchris commented on Design patterns in the test of time</title><description>I'm pretty sure when I was in college we used that exact same book just like the 5th edition instead. That class, "Software Architecture" was one of only maybe 4 classes that I use every day in software development.

To anyone that says patterns are worthless or similar, I'm glad I'm not on your software team. And if you were on mine, i'd probably fire you.

Going to a book and picking out random patterns to build software does not make sense. But you need to understand these building blocks, and when each one is needed. At this point, alot of the patterns have been enshrined into packages that are highly specialized versions of them, but to not understand why they are that and what you're using. Well that's like running with scissors in the dark, it's not a question of if you'll trip over something only a question of a when and whether the scissors are going into your eye or not.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment18</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment18</guid><pubDate>Tue, 30 Oct 2012 12:45:12 GMT</pubDate></item><item><title>Federico Orlandini commented on Design patterns in the test of time</title><description>I think that design patterns are usefull even in the .NET/HTTP/Multithreading/Mobile time like now. Widespread software requires a good designed (and robust) business logic and in this field design patters can help.

At least.....I agree with Q: the QoF book is unreadable! Try this one: "Head first Design Pattern" (http://shop.oreilly.com/product/9780596007126.do), surely an easier book ;-)</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment17</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment17</guid><pubDate>Thu, 25 Oct 2012 20:10:39 GMT</pubDate></item><item><title>Q commented on Design patterns in the test of time</title><description>Just wrote a WinRT app using MvvM. About half way through I realized I could delete about half of the code moving my vm to the code behind. Goodby reverse command. Goodby reference to the dispatcher for wcf stuff. Goodby overcomplicated abstraction. Hello reality.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment16</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment16</guid><pubDate>Thu, 25 Oct 2012 16:15:17 GMT</pubDate></item><item><title>Jonathan Allen commented on Design patterns in the test of time</title><description>I read that book in 1998 and found it to be garbage. Since then my opinion of it has only gotten worse.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment15</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment15</guid><pubDate>Wed, 24 Oct 2012 23:17:52 GMT</pubDate></item><item><title>Kurt commented on Design patterns in the test of time</title><description>I look forward to what you have to say.

I agree completely with the part that design patterns should be used to simplify code. I have seen many projects (and I unfortunately also implemented one - I learned my lesson) where they were used for the sake of using them and in turn turning what should be a relatively simple application into a beast.

I regularly use State, Observer, Factory and Builder. Less often the others.

GoF was right for its day. I found it a brief and concise introduction to be able to explore patterns further. I read Heads-First when it came out and found it both easy to read and informative.

I also bought the 'Design Patterns (Erich Gamma et. al.)  in 2002 and found it almost unreadable. 

</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment14</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment14</guid><pubDate>Wed, 24 Oct 2012 22:31:12 GMT</pubDate></item><item><title>Dennis commented on Design patterns in the test of time</title><description>Design Patterns are a language that designers use to describe solutions, and potential solutions. If you need to look at a book to USE a design pattern you are doing code wrong. The design pattern emerges from the code required to solve the problem in a maintainable fashion.

Also I recommend the Head First Design Patterns book as well. Much more palatable than the GoF offering.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment13</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment13</guid><pubDate>Wed, 24 Oct 2012 12:24:10 GMT</pubDate></item><item><title>Henrik commented on Design patterns in the test of time</title><description>The idea of design patterns is still relevant, I think. However just blindly ripping them from GoF and using today in any old language is not a good idea. I mainly code Ruby today and one of my favorite Ruby books is an adaption of the relevant GoF patterns to the Ruby way of thinking and coding. (http://designpatternsinruby.com).</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment12</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment12</guid><pubDate>Wed, 24 Oct 2012 11:13:04 GMT</pubDate></item><item><title>Ayende Rahien commented on Design patterns in the test of time</title><description>Vincent, 
Did you missed the part where I setup the context?

"And because I know the nitpickers, let me setup the context. We are talking about building design patterns within the context of .NET application, aimed at either system software (like RavenDB) or enterprise applications"</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment11</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment11</guid><pubDate>Wed, 24 Oct 2012 11:10:09 GMT</pubDate></item><item><title>Vincent commented on Design patterns in the test of time</title><description>&gt; None of those assumptions are relevant to how we build software today

FOR YOU - may be. Life is changed so much that all those GoF you can use in toilet. Really.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment10</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment10</guid><pubDate>Wed, 24 Oct 2012 10:54:57 GMT</pubDate></item><item><title>Rob G commented on Design patterns in the test of time</title><description>Much of the advice in the book has entered into common parlance. Visitors, strategies, etc. are widely useful and still used - and really help establish a common vocabulary.

Some of these really address shortcomings in languages though. The Visitor pattern, for example, is less necessary in languages with true dynamic binding.

The one which really should be in an anti-pattern book is the Singleton pattern. I still regularly see implementations posted in various languages (one in the last 2 days in C++ in Reddit for example).</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment9</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment9</guid><pubDate>Wed, 24 Oct 2012 10:38:44 GMT</pubDate></item><item><title>Andy commented on Design patterns in the test of time</title><description>The GoF book almost turned me off OO for life when someone gave me a copy 12 years ago. It's huge, mind-numbingly boring, and I don't think I ever finished the first chapter. Don't get me wrong - I've read more 1000+ page programming books from cover to cover than I can remember, but Design Patterns just didn't float my boat. It was far too academic, and reading it was like wading through treacle. For anyone wanting a "lighter" introduction to design patterns I would recommend "Head First Design Patterns", or the excellent "Applying UML and Patterns" which I wish I'd read years ago.
I realise your blog isn't about this book in particular though, and I'm looking forward to following.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment8</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment8</guid><pubDate>Wed, 24 Oct 2012 07:27:16 GMT</pubDate></item><item><title>Arnon Rotem-Gal-Oz commented on Design patterns in the test of time</title><description>Design patterns aim to solve deficits in a language by providing a standardized solution to these deficits (i.e. common problems).
Specifically, the GoF patterns solved 1994 C++ problems. 
It shouldn't be surprise that modern languages and techniques solves these problems better.

I think the importance of the book is in the pattern thinking that it brought into the software world - the fact that solutions are only good in context and  the technique to describe these solutions and problems, building a vocabulary etc. </description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment7</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment7</guid><pubDate>Wed, 24 Oct 2012 04:46:49 GMT</pubDate></item><item><title>Gene Hughson commented on Design patterns in the test of time</title><description>I would blame the Cargo Cult mentality on those who seek prescriptions rather than understanding.  Whether the individual Go4 patterns are still relevant or not is less interesting than whether the concept of patterns is still relevant.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment6</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment6</guid><pubDate>Tue, 23 Oct 2012 12:48:00 GMT</pubDate></item><item><title>Dooh commented on Design patterns in the test of time</title><description>cool! looking forward for the upcoming posts</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment5</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment5</guid><pubDate>Tue, 23 Oct 2012 11:58:14 GMT</pubDate></item><item><title>Rodrigo Giosa commented on Design patterns in the test of time</title><description>Nice!</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment4</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment4</guid><pubDate>Tue, 23 Oct 2012 11:26:37 GMT</pubDate></item><item><title>Frank Quednau commented on Design patterns in the test of time</title><description>Obligatory Link to Resign Patterns: Ailments of Unsuitable Project-Disoriented Software (http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns).</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment3</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment3</guid><pubDate>Tue, 23 Oct 2012 10:46:34 GMT</pubDate></item><item><title>Craig commented on Design patterns in the test of time</title><description>The reason for the Cargo Cult mentality with design patterns is people forget they are meant to fall out of good code, rather than be injected into bad code.</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment2</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment2</guid><pubDate>Tue, 23 Oct 2012 10:16:37 GMT</pubDate></item><item><title>andrew commented on Design patterns in the test of time</title><description>You old fart! Can't wait to see what you have to say on this! Keep 'em coming - and thx!</description><link>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment1</link><guid>http://ayende.com/159329/design-patterns-in-the-test-of-time#comment1</guid><pubDate>Sun, 21 Oct 2012 23:14:15 GMT</pubDate></item></channel></rss>