実装した本人はなにか悪意があってそうしたわけではない。ちょっとした問題を、自身のひらめきで、あるいは伝承された秘伝で解決した結果、そうなってしまう。

頻出する「問題」があり、ある種の人々がたどりついてしまう「解決」（決して完全な未解決ではない）であるからこそパターンと呼ばれる。

アンチパターンには明確なマイナスがある

アンチパターンは、それぞれ何かが致命的に欠けているためにアンチパターンとされている。

ある条件下（しかも頻度が高い）で確実にパフォーマンスが低下する、スケーラビリティが極めて低い、明確なバグの原因になる、実装の把握が困難である（保守が難しい）、その他。

開発においてはコストを増大させることが多く、運用においては速度低下などでその価値を下げてしまうものもある。

最高のカタログ

これをそれぞれ開発経験や先輩からの口伝で一つずつ学ぶには膨大な時間が必要だろう。なかには悪いと気づかずに何十年も開発を続けてしまう人もいるだろう（いた）。

それをこういう綺麗な形でまとめあげて、しかもそれぞれの問題に対するわかりやすい処方箋までついている。

避ける方法だけではなく、良くするための攻める方法まで載っているというわけで、最高。

実際の話、アルゴリズムの選択と同じく、空間コストと時間コスト、そのほかにも保守性や堅牢性のなどさまざまな要素の組み合わせの中でのトレードオフがあり、あえて選択されるパターンもある。

ただそれは「あえて」であって「なんとなく」とか「こうしてきたから」ではない。メリットデメリットを把握した上での選択であれば、理路整然とその理由を説明できるし、貴重なご意見も怖くない。

解決策に入る前にアンチパターンのまずい点をことこまかに説明してくれているおかげで、なぜその解決策を用いた方がいいのかよくわかる。

そして、この本ではアンチパターンを最良の方法ではないとしながらも、しかし、それを選択しうる場合も紹介している。

やはりアンチパターンはアンチパターンであって、ごく限られた場合でないと使っていけないなという感じはした。