Add link to "PublishedInterface"

「公布済みインターフェイス」記事へのリンク切れについて修正しました。
ただし、_posts/2003-05-14-ProtectedData.md ないの記述については、
元記事がリンクになっていなかったため、翻訳のみのリンクなしとしました。

_posts/2000-01-01-InterfaceImplementationPair.md

@@ -27,6 +27,6 @@ http://martinfowler.com/bliki/InterfaceImplementationPair.html
 よくあることだが、これも、アプリケーションのクラスを作っているのか、ライブラリを作っているのかによって、トレードオフの仕方が変わってくる。
 アプリケーションを作っている場合だと、インタフェースが用意されていない場合は[インタフェースの抽出](http://www.refactoring.com/catalog/extractInterface.html)を行えばよい。それで終わりだ。
 公布済みのライブラリだと、ユーザは素早いフィードバックを受けられないので、公布済み型のインタフェースを作るとよいだろう。
-ただし、[[PublishedInterface]]の中でクラスを実装したかのようにするだけでは、うまくはいかない。
+ただし、[公布済みインターフェイス](PublishedInterface)の中でクラスを実装したかのようにするだけでは、うまくはいかない。
 インタフェースは様々なクライアントの要求に合わせて設計される必要があるが、
 インタフェースが実装に合わないこともしばしばあるのだ。

_posts/2003-05-14-ProtectedData.md

@@ -31,7 +31,7 @@ protected [アクセス修飾子](/AccessModifier)の意味が言語によって
 
 このように、データをprotectedにすることは、常に良いとも悪いとも言えません。
 まったく知らない人間がオーバーライドするようなクラスの場合は、
-protectedな機能をPublishedInterfaceの一部として扱うべきです。
+protectedな機能を公布済みインターフェイスの一部として扱うべきです。
 結果として気をつける必要も出てきますが。
 フィールドを公開するというのはよくありません。
 私ならこういう場合でもそんなことはしません。

_posts/2003-05-18-FrameworkBuilding.md

@@ -9,7 +9,7 @@ http://www.martinfowler.com/bliki/FrameworkBuilding.html
 
 よくある質問です。簡単に言うと、答えは「使えます」。リファクタリングは、フレームワークの構築に大変有用です。ただし、フレームワークの寿命次第なところがあります。フレームワークをどのように構築するのかという点に関わってくる部分もあります。
 
-こういった疑問を抱く人たちは、フレームワークのユーザーは安定したインターフェイスを必要としていると考えており、リファクタリングなど行えるはずはないと思っています。たしかにインターフェイスを変更すると影響は甚大です。私なりの言葉で言うと、フレームワークは[公布済みインターフェイス](/PublishedInterface)を備えているのです。公布済みインターフェイスのリファクタリングは面倒です。というのも、そのインターフェイスは既に一般に公開されているため、変更が困難だからです。
+こういった疑問を抱く人たちは、フレームワークのユーザーは安定したインターフェイスを必要としていると考えており、リファクタリングなど行えるはずはないと思っています。たしかにインターフェイスを変更すると影響は甚大です。私なりの言葉で言うと、フレームワークは[公布済みインターフェイス](PublishedInterface)を備えているのです。公布済みインターフェイスのリファクタリングは面倒です。というのも、そのインターフェイスは既に一般に公開されているため、変更が困難だからです。
 
 これがあまり問題にならないのは、フレームワークに対して行うリファクタリングはたいてい、公布済みインターフェイスに影響を及ぼさないからです。non-publishedの境界内では、自由にリファクタリングできます。ただ残念なことに、これが公布済みインターフェイスだというふうにマークすることは言語の仕様上できません。そのため、公布済みインターフェイスの部分をきちんとセットアップするという余分な仕事をしなくてはいけません。
 
@@ -24,4 +24,3 @@ FoundationFrameworkが必ずしもベストではありません。この方法
 * 2004-04-16 (金) 15:05:05 ''[[holic]]'' : "Published Interface" と "published interface"で後者を公開インタフェースくらいにしてしまうと、訳語がすっきりしますかね。"Public Interface" は固有名詞？
 * 2004-04-16 (金) 16:00:16 ''[[kdmsnr]]'' : 少し変えてみました。
 * 2004-05-08 (土) 00:01:26 ''[[名無しさん]]'' : 「FoundationFrameworkはダメだというわけではありません」には違和感があります。文法(?)的にも話の流れ的にも、「必ずしもベストじゃない(良いわけじゃない)」と言っているような気が。
-

_posts/2006-05-12-CodeOwnership.md

@@ -15,7 +15,7 @@ http://martinfowler.com/bliki/CodeOwnership.html
 
 このなかで私が大嫌いなのは、強いコードの所有である。他の人のコードを変更しなければならないことは多々ある。変更を頼んで修正を待っていては時間がかかりすぎてしまい、問題の修正が遅れ、事態は深刻になる。変更がシンプルな場合はなおさらイライラすることになる。
 
-シンプルな変更とは、たとえばpublicメソッドのリネームなどである。現代のリファクタリングツールは、安全にすべてのpublicメソッドを変更することができる。しかしこのメソッドが複数のモジュールにまたがっている場合、コードの所有を違反してしまうことになる。基本的に、開発者間のインタフェースは、変更によるオーバーヘッドも含めて、すべて[PublishedInterface](/PublishedInterface)に置き換えるべきだ。
+シンプルな変更とは、たとえばpublicメソッドのリネームなどである。現代のリファクタリングツールは、安全にすべてのpublicメソッドを変更することができる。しかしこのメソッドが複数のモジュールにまたがっている場合、コードの所有を違反してしまうことになる。基本的に、開発者間のインタフェースは、変更によるオーバーヘッドも含めて、すべて[公布済みインターフェイス](PublishedInterface)に置き換えるべきだ。
 
 さらによくないのは、実装の変更を行う場合だ。すぐには変更できないので、自分のモジュールにその外部コードをコピーし、そのコピーを呼び出しながら変更を行うことになる。もちろん、あとからきちんと整理する必要がある。
 

_posts/2007-09-02-IsChangingInterfacesRefactoring.md

@@ -30,8 +30,8 @@ http://www.martinfowler.com/bliki/IsChangingInterfacesRefactoring.html
 
 
 インタフェースの変更によるリファクタリングは、あなたがすべての呼び出し元を把握しているという前提に立っている。
-そのため、PublishedInterfaceを扱うときには注意が必要だ。
-PublishedInterfaceでは、インタフェースそのものがシステムの振る舞いとみなされるからだ。
+そのため、[公布済みインターフェイス](PublishedInterface)を扱うときには注意が必要だ。
+公布済みインターフェイスでは、インタフェースそのものがシステムの振る舞いとみなされるからだ。