This notion is illustrated in the c

This notion is illustrated in the change scenario 2, which focuses on modifying
the HW layers to add new use cases. The activity to add constrained modules
(contracted classes and methods) is performed by one layer (concern) at a time. For
instance, there are situations where the view layer is under modification to adhere the
new constrained modules, but the DbC features (such as preconditions) are propagated
to other layers such as the business layer. More specifically, in the view layer
there is an interface called IFacade, but as a limitation of the OO decomposition,
we cannot add any precondition to this component, so we should propagate this
change to the modules a®ected (the classes which implement such interface) by such
interface. As a result, we have two classes implementing this interface: the RMIServletAdapter
in the same view layer and the HealthWatcherFacade class in the
business layer. This way, the attempt to add a precondition to a method of the
IFacade interface, results in changes in two components, one of them localized in
another unrelated layer (the business layer where the HealthWatcherFacade class is declared). In the same sense, while reasoning about the correctness of a method at
the RMIServletAdapter class, if we change a precondition in this class, we might
change the related precondition in the HealthWatcherFacade class as well. Thus,
these result in negative changes caused by OO ripple-e®ects. These negative changes
can be avoided in AO implementation since AspectJ-like languages can instrument
an interface and its hierarchy.

ผลลัพธ์ (ไทย) 1:

ความคิดนี้จะอธิบายสถานการณ์การเปลี่ยนแปลง 2 ซึ่งมุ่งเน้นการปรับเปลี่ยนชั้น HW เพิ่มกรณีใช้ใหม่ กิจกรรมการเพิ่มโมดูลจำกัด(สัญญาเรียนและวิธีการ) ดำเนินการ โดยหนึ่งชั้น (กังวล) ครั้ง สำหรับอินสแตนซ์ มีที่ชั้นมองอยู่ภายใต้การปรับเปลี่ยนตามสถานการณ์เผยแพร่โมใหม่จำกัด แต่คุณลักษณะ DbC (เช่นเงื่อนไขเบื้องต้น)ไปชั้นอื่น ๆ เช่นชั้นธุรกิจ อื่น ๆ โดยเฉพาะ ในชั้นดูมีอินเทอร์เฟซที่เรียกว่า IFacade แต่ เป็นข้อจำกัดของการดาเน่าเราไม่สามารถเพิ่มเงื่อนไขใด ๆ คอมโพเนนต์นี้ ดังนั้นเราควรเผยแพร่เปลี่ยนโมเป็น ® ected (สอนการใช้อินเทอร์เฟซดังกล่าว) ด้วยเช่นอินเตอร์เฟซ ดังนั้น เรามีสองชั้นที่ใช้อินเทอร์เฟซนี้: RMIServletAdapterในชั้นมุมมองเดียวและคลา HealthWatcherFacade ในการชั้นธุรกิจ วิธีนี้ ความพยายามในการเพิ่มเงื่อนไขวิธีการติดต่อ IFacade ผลลัพธ์ในการเปลี่ยนแปลงในส่วนสอง หนึ่งของพวกเขาเป็นภาษาท้องถิ่นไม่เกี่ยวข้องเลเยอร์อื่น (ธุรกิจชั้นที่ประกาศคลาส HealthWatcherFacade) ในความรู้สึกเดียวกัน ในขณะที่เหตุผลเกี่ยวกับความถูกต้องของวิธีการที่เรียน RMIServletAdapter ถ้าเราเปลี่ยนเงื่อนไขในชั้นนี้ เราอาจเปลี่ยนแปลงเงื่อนไขที่เกี่ยวข้องในคลา HealthWatcherFacade ด้วย ดังนั้นเหล่านี้มีผลเปลี่ยนแปลงเชิงลบที่เกิดจากระลอกคลื่นอีดา ® ects เปลี่ยนแปลงเหล่านี้เป็นค่าลบสามารถหลีกเลี่ยงในอ่าวนำเนื่องจากเหมือน AspectJ ภาษาสามารถตราอินเทอร์เฟซและลำดับชั้นของ

ผลลัพธ์ (ไทย) 2:

ความคิดนี้เป็นตัวอย่างในสถานการณ์การเปลี่ยนแปลง 2 ซึ่งมุ่งเน้นไปที่การปรับเปลี่ยน
ชั้น HW ที่จะเพิ่มกรณีการใช้งานใหม่ กิจกรรมที่จะเพิ่มโมดูล จำกัด
(ชั้นเรียนและวิธีการทำสัญญา) จะดำเนินการโดยชั้นหนึ่ง (กังวล) ในเวลา สำหรับ
ตัวอย่างเช่นมีสถานการณ์ที่ชั้นมุมมองที่อยู่ภายใต้การปรับเปลี่ยนให้เป็นไปตาม
ข้อ จำกัด โมดูลใหม่ แต่คุณสมบัติ DbC (เช่นปัจจัยพื้นฐาน) จะแพร่กระจาย
ไปยังชั้นอื่น ๆ เช่นชั้นธุรกิจ โดยเฉพาะอย่างยิ่งในชั้นมุมมอง
ที่มีอินเตอร์เฟซที่เรียกว่า IFacade แต่เป็นข้อ จำกัด ของการสลายตัว OO,
เราไม่สามารถเพิ่มเงื่อนไขใด ๆ ในส่วนนี้ดังนั้นเราจึงควรเผยแพร่นี้
การเปลี่ยนแปลงโมดูลa®ected (ชั้นเรียนซึ่งดำเนินการดังกล่าว อินเตอร์เฟซ) ด้วยเช่น
อินเตอร์เฟซ เป็นผลให้เรามีสองคลาสการใช้อินเตอร์เฟซนี้: RMIServletAdapter
ในชั้นมุมมองเดียวกันและระดับ HealthWatcherFacade ใน
ชั้นธุรกิจ วิธีนี้ความพยายามที่จะเพิ่มเงื่อนไขวิธีการของ
อินเตอร์เฟซ IFacade ผลให้เกิดการเปลี่ยนแปลงในสองส่วนหนึ่งของพวกเขาที่มีการแปลใน
ชั้นที่ไม่เกี่ยวข้องอีก (ชั้นธุรกิจที่ชั้น HealthWatcherFacade มีการประกาศ) ในความรู้สึกเดียวกันในขณะที่เหตุผลเกี่ยวกับความถูกต้องของวิธีการที่
ชั้น RMIServletAdapter ถ้าเราเปลี่ยนเงื่อนไขในชั้นนี้เราอาจจะ
มีการเปลี่ยนแปลงเงื่อนไขที่เกี่ยวข้องในชั้นเรียน HealthWatcherFacade ได้เป็นอย่างดี ดังนั้น
ผลให้เกิดการเปลี่ยนแปลงในเชิงลบเหล่านี้เกิดจากการ OO ระลอกe®ects การเปลี่ยนแปลงในเชิงลบเหล่านี้
สามารถหลีกเลี่ยงได้ในการดำเนินการตั้งแต่ AO ภาษา AspectJ เหมือนเครื่องมือที่สามารถ
อินเตอร์เฟซและลำดับชั้นของ

ผลลัพธ์ (ไทย) 3:

ความคิดนี้จะถูกแสดงในการเปลี่ยนแปลงสถานการณ์ที่ 2 ซึ่งเน้นการปรับเปลี่ยน
hw ชั้นเพื่อเพิ่มกรณีใช้ใหม่ กิจกรรมการเพิ่มขยายโมดูล
( ควบชั้นเรียนและวิธีการ ) จะดำเนินการโดยหนึ่งชั้น ( กังวล ) ในเวลา
สำหรับอินสแตนซ์ มีสถานการณ์ที่มุมมองชั้น ภายใต้การปรับเปลี่ยนที่จะปฏิบัติตาม
ใหม่กำหนดโมดูลแต่ DBC คุณลักษณะ ( เช่น preconditions ) ขยายพันธุ์
เลเยอร์อื่น ๆ เช่น ชั้นธุรกิจ มากขึ้นโดยเฉพาะในชั้น วิว
มีอินเตอร์เฟซที่เรียกว่า ifacade แต่เป็นข้อจำกัดของ OO การสลายตัว
เราไม่สามารถเพิ่มเงื่อนไขในส่วนนี้ ดังนั้น เราจึงควรเผยแพร่การเปลี่ยนแปลงนี้
กับโมดูลเป็น®ประมวล ( เรียนที่ใช้เช่น interface ) ด้วยเช่น
อินเตอร์เฟซเป็นผลให้เรามีสองบทเรียนการใช้อินเตอร์เฟซนี้ : rmiservletadapter
ในเลเยอร์เดียวกันและ healthwatcherfacade คลาสใน
ชั้นธุรกิจ วิธีนี้ พยายามที่จะเพิ่มเงื่อนไขให้วิธีการของ
ifacade อินเตอร์เฟซ , ผลในการเปลี่ยนแปลงในองค์ประกอบสองส่วน หนึ่ง ของพวกเขาใน
ถิ่นชั้น ( ชั้นอื่นที่ไม่เกี่ยวข้องกับธุรกิจที่ healthwatcherfacade คลาสประกาศ ) ในความรู้สึกเดียวกัน ในขณะที่เหตุผลเกี่ยวกับความถูกต้องของวิธีที่ rmiservletadapter
เรียน ถ้าเราเปลี่ยนเงื่อนไข ในชั้นนี้เราอาจ
เปลี่ยนเงื่อนไขที่เกี่ยวข้องใน healthwatcherfacade ชั้นเรียนได้เป็นอย่างดี ดังนั้น
ผลลบการเปลี่ยนแปลงที่เกิดจาก OO ripple-e ® ectsการเปลี่ยนแปลง
ลบเหล่านี้สามารถหลีกเลี่ยงได้ในอ่าวการใช้งานตั้งแต่ aspectj ชอบภาษาสามารถเรียบเรียง
อินเตอร์เฟซและลำดับขั้น