"Bên ngoài" trong ngữ cảnh này có nghĩa là "có thể quan sát được cho người dùng". Người dùng có thể là con người trong trường hợp ứng dụng hoặc các chương trình khác trong trường hợp API công khai.
Vì vậy, nếu bạn di chuyển phương thức M từ lớp A sang lớp B và cả hai lớp đều nằm sâu trong một ứng dụng và không người dùng nào có thể quan sát bất kỳ thay đổi nào trong hành vi của ứng dụng do thay đổi, thì bạn có thể gọi nó là tái cấu trúc.
Nếu, OTOH, một số hệ thống / thành phần con cấp cao khác thay đổi hành vi hoặc phá vỡ do thay đổi, đó thực sự là (thường) có thể quan sát được đối với người dùng (hoặc ít nhất là đối với nhật ký kiểm tra sysadins). Hoặc nếu các lớp của bạn là một phần của API công khai, có thể có mã bên thứ 3 ngoài đó phụ thuộc vào M là một phần của lớp A, chứ không phải B. Vì vậy, cả hai trường hợp này đều không được cấu trúc lại theo nghĩa nghiêm ngặt.
có một xu hướng gọi bất kỳ mã làm lại nào là tái cấu trúc, theo tôi đoán là không chính xác.
Thật vậy, đó là một hậu quả đáng buồn nhưng được mong đợi của việc tái cấu trúc trở thành mốt. Các nhà phát triển đã thực hiện việc làm lại mã theo cách thức không thường xuyên từ lâu và chắc chắn việc học một từ thông dụng mới dễ dàng hơn là phân tích và thay đổi thói quen ăn sâu.
Vì vậy, từ thích hợp cho việc làm lại thay đổi hành vi bên ngoài là gì?
Tôi sẽ gọi nó là thiết kế lại .
Cập nhật
Rất nhiều câu trả lời thú vị về giao diện, nhưng sẽ không di chuyển phương thức tái cấu trúc thay đổi giao diện?
Của cái gì? Các lớp học cụ thể, vâng. Nhưng những lớp học này có thể nhìn thấy trực tiếp ra thế giới bên ngoài theo bất kỳ cách nào? Nếu không - bởi vì chúng nằm trong chương trình của bạn và không phải là một phần của giao diện bên ngoài (API / GUI) của chương trình - không có sự thay đổi nào được thực hiện bởi các bên ngoài (tất nhiên trừ khi thay đổi phá vỡ điều gì đó).
Tôi cảm thấy rằng có một câu hỏi sâu sắc hơn thế này: liệu một lớp cụ thể có tồn tại như một thực thể độc lập không? Trong hầu hết các trường hợp, câu trả lời là không : lớp chỉ tồn tại như một phần của thành phần lớn hơn, hệ sinh thái của các lớp và đối tượng, mà không có nó không thể được khởi tạo và / hoặc không thể sử dụng được. Hệ sinh thái này không chỉ bao gồm các phụ thuộc (trực tiếp / gián tiếp) mà còn bao gồm các lớp / đối tượng khác phụ thuộc vào nó. Điều này là do không có các lớp cấp cao hơn này, trách nhiệm liên quan đến lớp của chúng tôi có thể là vô nghĩa / vô dụng đối với người dùng hệ thống.
Ví dụ, trong dự án của chúng tôi liên quan đến cho thuê xe, có một Chargelớp học. Lớp này không sử dụng cho chính người dùng hệ thống, bởi vì các đại lý trạm cho thuê và khách hàng không thể làm gì nhiều với một khoản phí riêng lẻ: họ giải quyết toàn bộ hợp đồng cho thuê (bao gồm một loạt các loại phí khác nhau) . Người dùng chủ yếu quan tâm đến tổng số các khoản phí này, cuối cùng họ phải trả; đại lý quan tâm đến các lựa chọn hợp đồng khác nhau, thời gian thuê, nhóm xe, gói bảo hiểm, các mặt hàng phụ, v.v. được chọn, (thông qua các quy tắc kinh doanh tinh vi) chi phối các khoản phí được trình bày và cách tính khoản thanh toán cuối cùng ra khỏi những. Và đại diện quốc gia / nhà phân tích kinh doanh quan tâm đến các quy tắc kinh doanh cụ thể, sức mạnh tổng hợp và tác động của họ (đối với thu nhập của công ty, v.v.).
Gần đây tôi đã tái cấu trúc lớp này, đổi tên hầu hết các trường và phương thức của nó (để tuân theo quy ước đặt tên Java tiêu chuẩn, hoàn toàn bị bỏ qua bởi những người đi trước của chúng tôi). Tôi cũng có kế hoạch tái cấu trúc hơn nữa để thay thế Stringvà charcác lĩnh vực với các loại enumvà phù hợp hơn boolean. Tất cả điều này chắc chắn sẽ thay đổi giao diện của lớp, nhưng (nếu tôi thực hiện đúng công việc của mình) thì không ai trong số đó sẽ hiển thị cho người dùng ứng dụng của chúng tôi. Không ai trong số họ quan tâm đến cách tính phí riêng lẻ, mặc dù họ chắc chắn biết khái niệm về phí. Tôi có thể đã chọn làm ví dụ cho hàng trăm lớp khác không đại diện cho bất kỳ khái niệm miền nào, do đó thậm chí còn vô hình về mặt khái niệm đối với người dùng cuối, nhưng tôi nghĩ sẽ thú vị hơn khi chọn một ví dụ có ít nhất khả năng hiển thị ở cấp độ khái niệm. Điều này cho thấy độc đáo rằng các giao diện lớp chỉ là đại diện cho các khái niệm miền (tốt nhất), không phải là thực tế *. Các đại diện có thể được thay đổi mà không ảnh hưởng đến khái niệm. Và người dùng chỉ có và hiểu khái niệm; nhiệm vụ của chúng ta là thực hiện ánh xạ giữa khái niệm và biểu diễn.
* Và người ta có thể dễ dàng thêm rằng mô hình miền, mà lớp chúng ta đại diện, bản thân nó chỉ là một đại diện gần đúng của một số "thực tế" ...