クラスで「最終」を使用することが本当に悪いのはなぜですか？

PHP OOPレガシーWebサイトをリファクタリングしています。

クラスの「最終」を「make it explicit that the class is currently not extended by anything」に使い始めたいと思います。クラスに行くと、これにより多くの時間を節約でき、protectedプロパティまたはメソッドの名前を変更/削除/変更できるかどうか疑問に思っています。クラスを本当に拡張したい場合は、最後のキーワードを削除して、拡張のためにロックを解除します。

すなわち、もし子クラスのないクラスに来たら、そのクラスを決勝にマークすることでその知識を記録することができます。次回、コードベースを再検索して、子があるかどうかを確認する必要はありません。したがって、リファクタリング中の時間を節約できます。

それはすべて賢明な時間節約のアイデアのように思えます...しかし、クラスはまれ/特別な場合にのみ「最終」にすべきであると読んでいます。

Mockオブジェクトの作成を台無しにしたり、私が考えていない他の副作用があるかもしれません。

私は何が欠けていますか？

クラスはまれ/特別な場合にのみ「最終」にすべきだとよく読んでいます。

それを書いた人は誰でも間違っています。final自由に使用して、それは何も悪いことはありません。クラスは継承を念頭に置いて設計されたものではないことを文書化しており、これは通常、デフォルトですべてのクラスに当てはまりfinalます。多くの注意が必要です。

したがってfinal、デフォルトで使用することは決して悪いことではありません。実際、多くの人々は、これがデフォルトであると提案します、例えば、ジョン・スキート。

たぶんそれはモックオブジェクトの作成を台無しにします…

これは確かに警告ですが、クラスをモックする必要がある場合はいつでもインターフェイスに頼ることができます。これは、モックの目的のためだけにすべてのクラスを継承に対してオープンにするよりも確かに優れています。

クラスにサブクラスがないという注意を自分に残したい場合は、必ずサブクラスを使用してコメントを使用してください。「最終」キーワードはコメントではありません。言語キーワードを使用して何かを伝えるだけで（そしてそれが何を意味するかを知っているのはあなただけです）、悪い考えです。

「いつfinalクラスを宣言するか」についての素晴らしい記事があります。それからいくつかの引用：

TL; DR：finalインターフェイスを実装し、他のパブリックメソッドが定義されていない場合は、常にクラスを作成します

なぜ使用しなければならないのfinalですか？

1. 破滅の大規模な継承チェーンの防止
2. 有望な組成
3. 開発者にユーザーのパブリックAPIについて考えるように強制する
4. 開発者にオブジェクトのパブリックAPIを縮小させる
5. finalクラスは常に拡張可能行うことができます
6. extends カプセル化を破る
7. あなたはその柔軟性を必要としません
8. コードを自由に変更できます

回避する場合final：

最終クラスは、次の前提の下でのみ効果的に機能します。

1. finalクラスが実装する抽象化（インターフェース）があります
2. 最終クラスのパブリックAPIはすべて、そのインターフェイスの一部です

これらの2つの前提条件のいずれかが欠落している場合、コードが実際に抽象化に依存していないため、クラスを拡張可能にする時点に達する可能性があります。

PS素晴らしい読書をしてくれた@ocramiusに感謝します！

クラスの「最終」とは、サブクラスが必要ですか？先に進み、「最終」サブクラスを必要なだけ削除しますが、機能しない場合は文句を言わないでください。あなたは自分でしています。

クラスをサブクラス化できる場合、他のクラスが依存する動作であるため、サブクラスが従う抽象的な用語で説明する必要があります。呼び出し元は、ある程度のばらつきを想定して作成する必要があります。ドキュメントは慎重に作成する必要があります。ソースコードがまだないので、人々に「ソースコードを見ている」と言うことはできません。それはすべての努力です。クラスがサブクラス化されることを期待しない場合、それは不必要な努力です。「最終」は、この努力がなされていないことを明確に示し、公正な警告を与えます。

あなたが考えていない可能性があります一つのことは事実であるANYクラス手段の変化は、それが新しいQAテストを受けることがあること。

あなたが本当に、本当にそれを意味しない限り、物事を最終としてマークしないでください。

「最終」を使用すると、コードを使用する他の人の自由が奪われます。

あなたが書いたコードがあなただけのためのものであり、決して一般公開や顧客に公開されないなら、あなたはもちろんあなたが望むコードでそれを行うことができます。そうしないと、他の人がコードを作成するのを防ぐことができます。必要に応じて簡単に拡張できるAPIを使用しなければならないことが多かったのですが、「最終」に妨げられました。

また、そこに多くの場合、より良いはずですコードではない行うことがprivate、しかしprotected。確かに、private「カプセル化」を意味し、実装の詳細と見なされるものを隠します。しかし、APIプログラマーとして、メソッドxyzが実装の詳細であると見なされているため、将来のバージョンで変更/削除される可能性があるという事実を文書化することもできます。したがって、警告にもかかわらずこのようなコードに依存するすべての人は、自分の責任でそれを行っています。しかし、彼は実際にそれを実行し、（できればテスト済みの）コードを再利用し、ソリューションをより迅速に作成できます。

もちろん、API実装がオープンソースの場合、「最終」を削除するか、メソッドを「保護」するだけでかまいませんが、コードを変更してパッチの形で変更を追跡する必要があります。

ただし、実装がクローズドソースの場合、回避策を見つけることができず、最悪の場合、カスタマイズ/拡張の可能性に関する制限が少ない別のAPIに切り替えることになります。

「最終」または「プライベート」は悪ではないことに注意してください。ただし、プログラマはコードの再利用と拡張の観点から自分のコードについて考えなかったため、あまりにも頻繁に使用されると思います。