管理者を煙に巻く buzzword はどうでも良い(?)が、技術者を煙に巻くものは許せない

定義無しに謎概念に名前の付いたものがコード上に現れたときに感じること。

最近 DI (Dependency Injection)とか言って、カプセル化を破壊する過去に戻るような概念がもてはやされたりしてます。
自分は昔から設定ファイルベースの pluggable な仕組み自体は多用していたからこそ言いますが、DI が buzzword 化して流行りだすととんでもないことになります。

hibernate 等では RDB のリレーションを解決する方法を hibernate 側の設定として書けることを以て、「依存性を外部で定義する」＝DI の一種と呼ばれているように思います(詳しくは知らないので間違っていたらご指摘ください)。
こういうのは、はっきり言って外部化したことが便利なのではなく、コード中でリレーションを解決するコードを書くと長くなりがちで、最終的なオブジェクトグラフが読み取りにくくなるため、宣言的記法によって解消する、といった可読性面の意義でしかないと考えます。他に、依存性定義を一箇所にかけるなどがりますが、一元化したければ関数(static メソッド)にでもすればいいのです。

もし、ここで「ソースを書き換えなくても依存性の変更が可能」等と言い出してしまうと、buzzword の罠にはまっています。
そんなことができても便利にはならないです。そのかわりに失っているものがあるのだということが世間的に気づかれるのはあと１年くらいかかるかもしれません。

なお、hibernate は私もかなりいいツールだと思っています。使い手の問題なんです。

J2EE が間接参照を多用して、「柔軟性を上げた」と標榜して、概念の複雑化と実装負担(書かなければならないものの種類の増加)で嫌われた流れを踏襲するという予感がひしひしとします。

しかし、「謎概念」ってのがまた問題で、自分だけ知らなくて実は設計上当たり前ということも確かにあって、この業界では、知らないことが罪みたいな空気もなくはないので面倒です。デザインパターンなんてその典型です。しかも、言葉を知っているかどうかだけが重要視されていて、その意味は知らなくても良いかのような空気が:p。

新しい概念を定義し、名前をつけることは重要なのですが、過度に抽象化された定義が流行ると必ず正確な意図は掻き消えて、とんでもない使い方のほうが蔓延するものです。
技術者たるもの、宗教家のように論理的に説明できない用語を乱発するより具体的な定義を提唱することを心がけるべきでは？と思います。ちなみに(少なくとも GoF の)「デザインパターン」はかなり厳密に定義されています。念のため。

ところで、タイトルですが、管理者が buzzword に踊らされると使いたくないものを使わされて大変な思いをするということも一般的にはありがちではあるんですけどね…。私の場合、技術者が buzzword を生み出すことのほうがいやんな感じがするということです。