2008-11-19 18 views
8

Bất cứ ai cũng biết cách xác định tái cấu trúc theo cách chính thức hơn?Có định nghĩa chính thức nào cho "tái cấu trúc" không?

CẬP NHẬT.

Tái cấu trúc là cặp R = (trước; T) trong đó tiền tố là điều kiện tiên quyết là và T là chương trình chuyển đổi.

+0

mở cửa trở lại và bỏ phiếu tán - đây là một câu hỏi tuyệt vời –

+0

gì trên trái đất về tấn công là điều này? Một câu hỏi rất hay. – tvanfosson

+0

Biến đổi có thể lặp lại bao gồm các điều kiện tiên quyết của riêng chúng, do đó, nó có vẻ dư thừa trong đặc tính này. –

Trả lời

-2

Cũng không trực tiếp, nhưng xét về tiền - tôi có thể nói Có. Tôi không thể đưa ra một phương trình trên đó :)

Mã được viết tốt, không phức tạp (có thể do tái cấu trúc) có thể tiết kiệm thời gian/công sức và do đó kiếm tiền.

3

Đó là một câu hỏi thú vị và một câu hỏi mà tôi chưa từng cân nhắc. Tôi đã googling một chút và đã đưa ra điều này paper (PDF) về tái cấu trúc trong AOP cố gắng áp dụng một số mô hình toán học cho các khía cạnh để cho thấy các khía cạnh chức năng có tính linh hoạt tương tự như các khía cạnh truyền thống nhưng với độ phức tạp giảm. Tôi đã không đọc toàn bộ bài báo, nhưng bạn có thể tìm thấy một cái gì đó ở đó.

Một ý tưởng thú vị khác là suy nghĩ về các phép tái cấu trúc dọc theo các dòng giống như tối ưu hóa trình biên dịch. Về cơ bản, trình biên dịch sẽ tái cấu trúc mã của bạn một cách nhanh chóng, mặc dù với các mục tiêu khác với việc tái cấu trúc cấp mã. Bạn sẽ phải bằng cách nào đó định lượng mã phức tạp và dễ đọc một cách hợp lý để chứng minh làm thế nào một refactoring cụ thể ảnh hưởng đến nó. Đến với mô hình có lẽ sẽ là một phần khó khăn. Tôi cũng tìm thấy điều này paper thiết lập một đại số của lập trình OO và xuất phát một số luật cơ bản, sau đó sử dụng những quy tắc cơ bản đó để lấy được một phép tái cấu trúc phức tạp hơn.

Thú vị. Hi vọng điêu nay co ich.

+0

tìm thấy tuyệt vời! –

2

refactoring là một loạt các biến đổi đúng đắn bảo quản, nhưng refactoring có thể dẫn trong mã tổng quát hơn so với bản gốc

vì vậy chúng tôi không thể chỉ khẳng định rằng một T chuyển đổi refactoring về chương trình P có tính chất tương tự R trước và sau khi tái cấu trúc, nhưng các thuộc tính R 'của chương trình P refactored' nên có ít nhất tương đương với R

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

chúng ta cũng có thể khẳng định rằng các đầu vào và đầu ra vẫn như cũ hoặc tương đương

nhưng để làm theo ví dụ của bạn, có lẽ chúng ta muốn định nghĩa một phép chuyển đổi cấu trúc lại T như một P-I 4, I, O, R trong đó P là chương trình gốc, tôi là đầu vào và/hoặc điều kiện tiên quyết, O là kết quả đầu ra và/hoặc postcondition, và R là chương trình biến đổi, sau đó khẳng định (sử dụng logic thời gian?) Mà

P:I -> O 

nắm giữ trước khi chuyển đổi

T(P) -> R 

xác định chuyển đổi, và

R:I -> O 

nắm giữ sau khi chuyển đổi

toán mang tính biểu tượng của tôi là Rusty, nhưng đó là một hướng đi chung

điều này sẽ làm luận án một bậc thầy ngon, BTW

+0

Không. Bước tái cấu trúc có thể thay đổi ngữ nghĩa của chương trình. Cân nhắc việc bỏ một đối số khỏi một cuộc gọi hàm. –

+0

@ [Ira Baxter]: có - Tôi đang đề cập đến các đầu vào và đầu ra của chương trình P, không phải là một hàm riêng lẻ trong P. Tất nhiên bạn có thể thả đầu vào cho chương trình nếu nó không được sử dụng, nhưng nếu nó không được không được sử dụng sau đó các ngữ nghĩa thực tế (như trái ngược với chính thức) của chương trình vẫn không thay đổi anyway ;-) –

2

Nó có thể là thú vị để lưu ý rằng hầu hết các phép tái cấu trúc đi theo cặp:

  • Thêm Parameter - Hủy bỏ Parameter
  • Extract Lớp/Phương pháp - Inline Lớp/Phương pháp
  • Trường/Phương thức kéo xuống - Trường kéo xuống/Phương thức
  • Thay đổi liên kết hai chiều thành một chiều - Thay đổi một chiều liên kết thành hai chiều
  • ...

Áp dụng hai phép tái cấu trúc của cặp là một phép biến đổi rỗng.

Đối với một cặp refactoring R, R ':

R' (R (code)) = mã

Các vấn đề liên quan