より正式な方法でリファクタリングを定義する方法を知っている人はいますか?
アップデート。
リファクタリングは、R = (pre; T) のペアです。ここで、pre はプログラムが満たさなければならない前提条件であり、T はプログラムの変換です。
より正式な方法でリファクタリングを定義する方法を知っている人はいますか?
アップデート。
リファクタリングは、R = (pre; T) のペアです。ここで、pre はプログラムが満たさなければならない前提条件であり、T はプログラムの変換です。
これは興味深い質問であり、私が考えたこともありませんでした。私は少しグーグルで調べて、AOP でのリファクタリングに関するこの論文(PDF)を思いつきました。これは、いくつかの数学的モデリングをアスペクトに適用して、機能面が従来のアスペクトと同じ柔軟性を持っているが、複雑さが軽減されていることを示すことを試みています。論文全体を読んだわけではありませんが、そこに何かが見つかるかもしれません。
もう 1 つの興味深いアイデアは、コンパイラーの最適化と同じ方向に沿ってリファクタリングを考えることです。コードレベルのリファクタリングとは目的が異なりますが、基本的に、コンパイラはコードをオンザフライでリファクタリングします。特定のリファクタリングがどのように影響するかを実証するには、合理的な方法でコードの複雑さと可読性を何らかの方法で定量化する必要があります。モデルを考え出すのはおそらく難しい部分です。
また、オブジェクト指向プログラミングの代数を確立し、いくつかの基本的な法則を導き出し、それらの基本的な規則を使用してより複雑なリファクタリングを導き出すこの論文も見つけました。
興味深いもの。お役に立てれば。
ほとんどのリファクタリングはペアで行われることに注意してください。
ペアの2つのリファクタリングを適用することは、ヌル変換です。
リファクタリングペアRの場合、R':
R'(R(コード))=コード
リファクタリングは一連の正確性を維持する変換ですが、リファクタリングは元のコードよりも一般的なコードになる可能性があります
したがって、プログラムPのリファクタリング変換Tがリファクタリングの前後で同じプロパティRを持っていると断言することはできませんが、リファクタリングされたプログラムP'のプロパティR'は少なくともRと同等である必要があります。
given program P implies R
refactoring transformation T(P) produces P'
where (P' implies R') and (R' is equivalent to or subsumes R')
入力と出力が同じまたは同等のままであると断言することもできます
しかし、あなたの例に従うために、おそらくリファクタリング変換Tを4タプルP、I、O、Rとして定義したいと思います。ここで、Pは元のプログラム、Iは入力および/または前提条件、Oは出力および/または事後条件、およびRは変換されたプログラムであり、次に(時相論理を使用して?)
P:I -> O
変換前に保持
T(P) -> R
変換を定義し、
R:I -> O
変換後に保持
私の記号数学はさびていますが、それは一般的な方向です
これは良い修士論文になります、ところで
直接的ではありませんが、お金の面では、イエスと言えます。私はそれについての方程式を思いつくことができません:)
コードが適切に作成され、複雑さがなく (リファクタリングが原因である可能性があります)、時間と労力を節約できるため、費用を節約できます。