“重构”有正式的定义吗?

发布于 2024-07-08 23:06:27 字数 132 浏览 16 评论 0原文

有人知道如何以更正式的方式定义重构吗?

更新。

重构是一对 R = (pre; T),其中 pre 是前提条件 程序必须满足,T为程序变换。

Anyone knows a way to define refactoring in a more formal way?

UPDATE.

A refactoring is a pair R = (pre; T) where pre is the precondition that
the program must satisfy, and T is the program transformation.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

鯉魚旗 2024-07-15 23:06:27

这是一个有趣的问题,也是我没有考虑过的问题。 我做了一些谷歌搜索,并想出了这篇论文< /a> (PDF) 关于 AOP 中的重构,尝试将一些数学建模应用于方面,以表明功能方面具有与传统方面相同的灵活性,但复杂性降低。 我没有阅读整篇论文,但你可能会在那里找到一些东西。

另一个有趣的想法是将重构视为与编译器优化相同的思路。 本质上,编译器会动态重构代码,尽管其目标与代码级重构不同。 您必须以某种合理的方式量化代码的复杂性和可读性,以证明特定的重构如何影响它。 提出模型可能是最困难的部分。

我还发现了这篇论文,它建立了代数OO编程并导出一些基本规则,然后使用这些基本规则导出更复杂的重构。

有趣的东西。 希望这可以帮助。

It's an interesting question and one I hadn't considered. I did a little googling and came up with this paper (PDF) on refactoring in AOP that attempts to apply some mathematical modeling to aspects to show the that functional aspects have the same flexibility as traditional aspects but with reduced complexity. I didn't read the whole paper, but you might find something there.

Another interesting idea would be to think of refactorings along the same lines as compiler optimizations. Essentially, the compiler refactors your code on the fly, although with different goals than code-level refactoring. You'd have to somehow quantify code complexity and readability in a reasonable way to demonstrate how a particular refactoring affects it. Coming up with the model would probably be the hard part.

I also found this paper that establishes an algebra of OO programming and derives some basic laws, then uses those basic rules to derive a more complicated refactoring.

Interesting stuff. Hope this helps.

葬﹪忆之殇 2024-07-15 23:06:27

重构是一系列保留正确性的转换,但是重构可能会产生比原始代码更通用的代码

,因此我们不能仅仅断言程序 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

在转换之后保持

我的符号数学生锈了,但这是一个总体方向,

这将成为一篇很好的硕士论文,顺便说一句

refactoring is a series of correctness-preserving transformations, but refactoring may result in more general code than the original

so we can't just assert that a refactoring transformation T on program P has the same properties R before and after refactoring, but the properties R' of the refactored program P' should be at least equivalent to R

given program P implies R
refactoring transformation T(P) produces P'
where (P' implies R') and (R' is equivalent to or subsumes R')

we can also assert that the inputs and outputs remain the same or equivalent

but to follow your example, perhaps we want to define a refactoring transformation T as a 4-tuple P,I,O,R where P is the original program, I is the inputs and/or preconditions, O is the outputs and/or postcondition, and R is the transformed program, then assert (using temporal logic?) that

P:I -> O

holds before transformation

T(P) -> R

defines the transformation, and

R:I -> O

holds after transformation

my symbolic math is rusty, but that's a general direction

this would make a good master's thesis, BTW

只是在用心讲痛 2024-07-15 23:06:27

有趣的是,大多数重构都是成对出现的:

  • 添加参数 - 删除参数
  • 提取类/方法 - 内联类/方法
  • 上拉字段/方法 - 下拉字段/方法
  • 将双向关联更改为单向 - 将单向关联更改为双向
  • ...

应用该对的两个重构是空转换。

对于重构对 R, R' :

R'(R(代码)) = 代码

It could be interesting to note that most of the Refactorings come in pairs:

  • Add Parameter - Remove Parameter
  • Extract Class/Method - Inline Class/Method
  • Pull Up Field/Method - Pull Down Field/Method
  • Change Bidirectional Association to Unidirectional - Change Unidirectional Association to Bidirectional
  • ...

Applying the two refactorings of the pair is a null transformation.

For a refactoring pair R, R' :

R'(R(code)) = code

深海夜未眠 2024-07-15 23:06:27

好吧,不是直接的,但就金钱而言 - 我可以说是的。 我无法提出一个方程式:)

编写良好、不复杂(可能是由于重构)的代码可以节省时间/精力,从而节省金钱。

Well not directly, but in terms of money - I can say Yes. I can't come up with an equation on that :)

Code well-written, free of complexity (that could be due to refactoring) can save time/effort and hence money.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文