0

私は壊れやすい基本クラスの問題を研究しており、次の論文が興味深いものであることがわかりました: https://www.research.ibm.com/haifa/info/ple/papers/class.pdf

この論文では、Java に「封印された」アクセス修飾子があれば素晴らしいだろうと主張しています。Java の「final」キーワードに相当する C# の「sealed」とは異なります。提案されたシール機構は、これらのシールされたクラスをパッケージの外に拡張することを不可能にします。

しかし、FBC の問題について私が見つけた資料のほとんどは 90 年代後半から 00 年代前半にさかのぼるので、「問題」がもはや主要な問題ではないかどうか疑問に思います。

Joshua Bloch が、特にライブラリ間での継承の使用を制限することを提唱していることを私は知っています。彼は確かに Java の権威であるようです。

プライベート コンストラクターを持つクラスから継承する一連の最終的な内部クラスを作成することで寡占を実現する方法は知っていますが、これはどういうわけか少し不適切に思えます。

提案されたシーリングは、クラスをデフォルト/パッケージプライベートにするのと基本的に似ていますか、それとも今日の Java には実際にある種のクラス シーリング メカニズムがありますか?

4

3 に答える 3

2

しかし、FBC の問題について私が見つけた資料のほとんどは 90 年代後半から 00 年代前半にさかのぼるので、「問題」がもはや主要な問題ではないかどうか疑問に思います。

問題がよりよく理解されるようになったと思います。同様に、問題とその対処方法について議論している最近の論文があまり多くGOTOないのは、これらの問題がもはや存在しないからではなく、人々がそれらの問題を回避する方法を知っているからです。

[提案されたクラス シール メカニズム] は、基本的にクラスをデフォルト/パッケージ プライベートにすることと同じではないのですか?

いいえ。パッケージ プライベート クラスと "sealed" クラスは、どちらもパッケージ外のクラスによって拡張できないという点で似ていますが、前者もパッケージ外のクラスで使用できないという点で異なります。つまり — クラスXがパッケージプライベートの場合、そのパッケージ外のクラスはXno extends X、 no X x = new X()、 noを参照することさえできませんClass<X> clazz = X.class。ただし、単にシールされているだけの場合、別のパッケージのクラスは を書き込むことはできませんが、書き込むことはできextends Xます。(同様に重要なことは、 がサブクラスである場合でも、 を書き込めることです。したがって、それ自体は を拡張できなくても、 の型階層を利用できます。)X x = new X()Class<X> clazz = X.classX x = new Y()YXX

于 2013-03-10T23:52:42.047 に答える
0

プライベート コンストラクターを持つクラスから継承する一連の最終的な内部クラスを作成することで寡占を実現する方法は知っていますが、これはどういうわけか少し不適切に思えます。

この手法が不適切だとは言いません。本当の問題は、主流の OOP 言語にはケースごとに型を定義するメカニズムがないことです。これを行うと、ケースと型が混同されますが (サブクラスを非公開にしてサブクラスを非表示にしない限り)、Java で使用できる唯一のオプションです。

ruakh の回答は、シーリング メカニズムに関するあなたの質問に対応しているため、スキップします。Fragile Base Class Problem の回避に関しては、このホワイト ペーパーでは、現在 Java で機能するソリューションを紹介します。アイデアは、すべてのパブリック メソッドを作成しfinal、メソッドの観点からそれらを実装することprotectedです。これにより、サブクラスは、安全と見なされるメソッドのみをオーバーライドできるようになります。

主流の OOP 言語で実装されている継承の問題は、オプトインする必要があるときにオプトアウトする必要があることです。そうは言っても、ケースごとにタイプを定義する以外に、集約/構成に置き換えたほうがよい継承の用途が他にあるのかわかりません。

于 2014-01-16T20:09:09.113 に答える
-1

ウィキペディアのページがあり、 StackOverflowの質問さえあるにもかかわらず、実際に は脆弱な基本クラスの問題のようなものはありません。最近の参照が見つからない理由は、80年代半ばに「無能なプログラマーの問題」に名前が変更されたためです。

名前が変更された理由は、誰かがそれが説明する問題に最終的に気付いたためです。基本クラスで一見取るに足らないメソッドを変更すると、継承されたすべてのサブクラスに広範囲にわたる結果が生じますが、実際にはoopの問題ではなく、基本クラスに間違ったコードを入れます。

oopを適切にコーディングし、継承を利用したい場合は、基本クラスに完全に安定した完全に信頼できるコードのみが含まれていることを確認する必要があります。あなたがそれから派生し始めるとあなたは立ち往生しているからです。基本クラスから数回派生した後、基本クラスを変更したい場合は、基本的にすでに足を撃ちました。

奇妙なプライベート階層をいじくり回すのは答えではありません。

于 2013-03-11T00:17:12.123 に答える