Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 21 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
21
Dung lượng
179,73 KB
Nội dung
trêng ®¹i häc KINH TÕ QUèC D¢N VIỆN CÔNG NGHỆ THÔNG TIN – KINH TẾ TIỂU LUẬN SVTH: PHẠM ANH TÚ MSV: 11134279 MÔN: NGUYÊN LÝ NGÔN NGỮ LẬP TRÌNH ĐỀ TÀI: Nghiên cứu các vấn đề về nguyên lý ngôn ngữ lập trình hướng đối tượng và cài đặt thử nghiệm bài toán tự chọn bằng ngôn ngữ lập trình hướng đối tượng C++. HÀ NỘI THÁNG 4 NĂM 2015 MỤC LỤC I, Nguyên lý Open-Closed……………………………………………trang 3 II, Nguyên lý Nghịch đảo phụ thuộc…………………………… trang 9 III, Nguyên lý Thay thế Liskov…………………………… trang 12 IV, Nguyên lý Phân tách interface…………………………… trang 17 Nguyên Lí Của Lập Trình Hướng Đối Tượng 2 2 Phương pháp lập trình hướng đối tượng đã được nghiên cứu và phát triển từ lâu nhưng việc vận dụng nó như thế nào cho hiệu quả trong việc xây dựng phần mềm là điều vẫn còn khá mơ hồ đối với nhiều người. Thế nào là một phần mềm hướng đối tượng ? Đâu là những cơ sở nền tảng để xây dựng được phần mềm theo tư tưởng hướng đối tượng đúng nghĩa ? Bài viết này trình bày về các nguyên lý lập trình hướng đối tượng. Đó là những quy tắc phân tích thiết kế hướng đối tượng cơ bản, mang tính chất khái quát. Do là nguyên lý nên nó có tính trừu tượng cao chứ không đi vào chi tiết cách thức giải quyết vấn đề cụ thể (việc hiện thực hóa những nguyên lý lập trình hướng đối tượng đòi hỏi chúng ta phải xem xét đến Design Patterns) I, Nguyên lý Open-Closed (The Open-Closed Principle) 1. Phát biểu Các thực thể phần mềm (hàm, đơn thể, đối tượng, …) nên được xây dựng theo hướng mở cho việc mở rộng (be opened for extension) nhưng đóng đối với việc sửa đổi (be closed for modification). 2. Nội dung Các thực thể trong một phần mềm không đứng riêng lẻ mà có sự gắn kết chặt chẽ với nhau. Chúng phối hợp hoạt động để cùng nhau thực hiện các chức năng của phần mềm. Do đó, việc nâng cấp, mở rộng một thực thể nào đó sẽ ảnh hưởng đến những thực thể liên quan. Điều này có thể dẫn đến việc phải nâng cấp, mở rộng cả những thực thể liên quan đó. Và trong thời đại đầy biến động hiện nay, việc phải thường xuyên nâng cấp, mở rộng các thực thể trong phần mềm là điều khó tránh khỏi. Để làm cho quá trình bảo trì, nâng cấp, mở rộng phần mềm diễn ra dễ dàng và hiệu quả hơn, các thực thể phần mềm nên được xây dựng tuân theo nguyên lý Open-Closed. Điều này có nghĩa là các thực thể phần mềm nên được xây dựng sao cho việc nâng cấp, mở rộng đồng nghĩa với việc thêm vào những cái mới chứ không phải là thay đổi những cái hiện có, từ đó tránh 3 3 được việc phải thay đổi các thực thể liên quan. Xét ví dụ một đoạn chương trình vẽ đường thẳng và hình chữ nhật bằng C#. public enum ShapeType { LINE, RECTANGLE } public abstract class Shape { public abstract ShapeType getType(); } public class Line: Shape { public override ShapeType getType() { return ShapeType.LINE; } public void drawLine() { // Draws the line } } public class Rectangle: Shape 4 4 { public override ShapeType getType() { return ShapeType.RECTANGLE; } public void drawRectangle() { // Draws the rectangle } } public void draw(ArrayList shapeList) { Line line; Rectangle rectangle; foreach (Shape s in shapeList) switch (s.getType()) { case ShapeType.LINE: line = (Line)s; line.drawLine(); break; case ShapeType.RECTANGLE: rectangle = (Rectangle)s; 5 5 rectangle.drawRectangle(); break; } } Đoạn chương trình trên hoạt động rất tốt cho đến khi có sự nâng cấp, mở rộng. Giả sử chúng ta cần nâng cấp, mở rộng đoạn chương trình trên để nó có thể vẽ thêm được hình tròn. Lúc bấy giờ ta phải chỉnh sửa lại hàm “draw”, thêm vào một trường hợp vẽ hình tròn. Và trong nhiều tình huống, việc chỉnh sửa hàm “draw” sẽ dẫn đến việc chỉnh sửa những hàm khác liên quan. Hàm “draw” được viết theo cách này được nói là không tuân thủ nguyên lý Open-Closed. Để đoạn chương trình trên tuân thủ nguyên lý Open-Closed, chúng ta sử dụng tính đa hình của lập trình hướng đối tượng. public abstract class Shape { public abstract void draw(); } public class Line: Shape { public override void draw() { // Draws the line } } public class Rectangle: Shape { public override void draw() { // Draws the rectangle } 6 6 } class Circle: Shape { public override void draw() { // Draws the circle } } public void draw(ArrayList shapeList) { foreach (Shape s in shapeList) s.draw(); } Với đoạn chương trình trên, khi thêm một hình mới vào, chúng ta chỉ việc thêm lớp đối tượng cho hình đó (kế thừa từ Shape) mà không cần phải chỉnh sửa lại hàm “draw”. Nó vẫn hoạt động tốt với những hình mới thêm vào. Ghi chú i) Không phải lúc nào tất cả các thực thể trong phần mềm đều có thể tuân thủ nguyên lý Open-Closed. Nhưng mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho số lượng các thực thể tuân thủ nguyên lý là lớn nhất, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý. ii) Việc tuân thủ nguyên lý Open-Closed của một thực thể phần mềm chỉ mang tính tương đối, phụ thuộc vào ngữ cảnh. Có thể trong ngữ cảnh này, thực thể thỏa nguyên lý, nhưng trong một ngữ cảnh khác, thực thể này không còn tuân thủ nguyên lý nữa. Mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho có nhiều thực thể phần mềm nhất tuân thủ nguyên lý trong ngữ cảnh thường xảy ra nhất của phần mềm, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý. Ví dụ trường hợp hàm “draw” như trong đoạn chương trình vẽ hình trên. public void draw(ArrayList shapeList) { 7 7 foreach (Shape s in shapeList) s.draw(); } Hàm “draw” chỉ thỏa nguyên lý trong ngữ cảnh nâng cấp mở rộng là “thêm hình mới”. Nếu chúng ta cần nâng cấp, mở rộng theo hướng thay đổi thứ tự vẽ các hình thì hàm “draw” như trên là không thể đáp ứng được. Khi đó nó không còn tuân thủ nguyên lý nữa. iii) Một tính chất quan trọng trong lập trình hướng đối tượng giúp cho các thực thể phần mềm tăng khả năng tuân thủ nguyên lý Open-Closed là tính đóng gói (encapsulation). Đối tượng nắm giữ thông tin và chịu trách nhiệm trên thông tin mình nắm giữ. Điều này giúp hạn chế sự kết dính (coupling) giữa các lớp đối tượng với nhau. Trường hợp lý tưởng là tất cả thuộc tính của đối tượng được đặt tầm vực private. việc thay đổi trên thuộc tính chỉ có thể được thực hiên thông qua những xử lý của phương thức. Những phương thức của đối tượng khác, kể cả đối tượng kế thừa không thể truy xuất được đến những thuộc tính này. iv) Việc hạn chế sử dụng ép kiểu động (runtime type-casting) trong các thực thể phần mềm cũng sẽ giúp làm tăng khả năng tuân thủ nguyên lý Open-Closed của chúng. Vì bản chất của việc ép kiểu động là làm việc với một kiểu dữ liệu cụ thể. Khi muốn nâng cấp, mở rộng thực thể để nó có thể làm việc với những kiểu dữ liệu khác, đoạn chương trình sử dụng ép kiểu động phải được thay đổi để có thể làm việc được với các kiểu dữ liệu khác này. public void doSomething(Vehicle vehicle) { Car car = (Car)vehicle; car.run(); car.stop(); } Khi cần nâng cấp, mở rộng để đoạn chương trình trên có thể làm việc được với các lớp đối tượng khác kế thừa từ “Vehicle”, chúng ta phải chỉnh sửa lại nó. 8 8 Ý nghĩa: Nguyên lý Open-Closed là nguyên lý cốt lõi và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng. Nó giúp cho phần mềm dễ bảo trì, nâng cấp và mở rộng. II, Nguyên lý Nghịch đảo phụ thuộc (The Dependency Inversion Principle) 1. Phát biểu: Các thành phần trong phần mềm không nên phụ thuộc vào những cái riêng, cụ thể (details) mà ngược lại nên phụ thuộc vào những cái chung, tổng quát (abstractions) của những cái riêng, cụ thể đó. Những cái chung, tổng quát (abstractions) không nên phụ vào những cái riêng, cụ thể (details). Sự phụ thuộc này nên được đảo ngược lại. 2. Nội dung Những cái chung, tổng quát là tập hợp của những đặc tính chung nhất từ những cái riêng, cụ thể. Những cái riêng, cụ thể dù khác nhau thế nào đi nữa cũng đều tuân theo các quy tắc chung mà cái chung, tổng quát của nó đã định nghĩa. Những cái chung, tổng quát là những cái ít thay đổi và ít biến động. Trong khi đó, sự thay đổi lại thường xuyên xảy ra ở những cái riêng, cụ thể. Việc phụ thuộc vào những cái chung, tổng quát sẽ giúp cho các thành phần trong phần mềm trở nên linh động (flexible) và thích ứng tốt với sự thay đổi thường xuyên diễn ra ở những cái riêng, cụ thể. Khi phụ thuộc vào những cái chung, tổng quát, các thành phần trong phần mềm vẫn có thể hoạt động tốt mà không cần phải sửa đổi một khi cái riêng, cụ thể được thay thế bằng một cái riêng, cụ thể khác cùng loại. Lấy ví dụ đoạn chương trình đọc dữ liệu từ bàn phím và xuất ra máy in. public void copy() { Keyboard keyboard = new Keyboard(); Printer printer = new Printer(); char c; 9 9 while ((c = keyboard.read()) != ‘q’) printer.write(c); } Khi nâng cấp, mở rộng đoạn chương trình trên để nó có thể xuất dữ liệu ra máy in hoặc tập tin thì chúng ta phải chỉnh sửa lại đoạn chương trình trên như sau. public void copy(OutputType type) { Keyboard keyboard = new Keyboard(); Printer printer = new Printer(); File file = new File(); char c; while ((c = keyboard.read()) != ‘q’) if (type == OutputType.PRINTER) printer.write(c); else if (type == OutputType.FILE) file.write(c); } Rõ ràng hàm “copy” như trên đã vi phạm nguyên lý Open-Closed do khi mỗi lần cần thêm một thiết bị đọc ghi mới vào, chúng ta phải chỉnh sửa lại nó. Nguyên nhân làm cho hàm “copy” vi phạm nguyên lý Open-Closed là do nó làm việc với từng thiết bị đọc ghi cụ thể. Khi thêm một thiết bị đọc ghi mới, chúng ta phải thêm vào hàm “copy” đoạn lệnh để làm việc với thiết bị đọc ghi mới. Khi đó chúng ta nói hàm “copy” vi phạm nguyên lý Nghịch đảo phụ thuộc. Để đoạn chương trình trên tuân thủ Nguyên lý Nghịch đảo phụ thuộc, từ đó tuân thủ Nguyên lý Open-Closed, chúng ta phải cho nó làm việc với thiết bị đọc ghi tổng quát. public void copy(Reader reader, Writer writer) { char c; while ((c = reader.read()) != ‘q’) 10 10 [...]... chúng ta phải viết lại nó Điều này làm cho hàm “func” vi phạm nguyên lý Open-Closed Khi đó ta nói hàm “func” vi phạm nguyên lý Thay thế Liskov Chú ý i) Nguyên lý Thay thế Liskov có mối liên hệ mật thiết với Nguyên lý Open-Closed Sự vi phạm nguyên lý Thay thế Liskov sẽ dẫn đến sự vi phạm nguyên lý Open-Closed Một thực thể phần mềm vi phạm nguyên lý Thay thế Liskov sẽ cư xử khác nhau trên các đối tượng của... thuộc vào ngữ cảnh Có thể trong ngữ cảnh này, thực thể thỏa nguyên lý, nhưng trong một ngữ cảnh khác, thực thể này không còn tuân thủ nguyên lý nữa Mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho có nhiều thực thể phần mềm nhất tuân thủ nguyên lý trong ngữ cảnh thường xảy ra nhất của phần mềm, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý iv) Quan... với chúng Điều này rõ ràng làm cho “Resistor” và “Lamp” vi phạm nguyên lý Open-Closed một cách “không chính đáng” Chú ý i) Nguyên lý Phân tách interface có mối liên hệ với nguyên lý Open-Closed Sự vi phạm nguyên lý Phân tách interface có khả năng dẫn đến sự vi phạm nguyên lý Open-Closed (xem phân tích ở trên) ii) Để tránh vi phạm nguyên lý Phân tách Inteface, chúng ta nên giữ cho interface của lớp đối... này dẫn đến vi phạm nguyên lý Open-Closed ii) Không phải lúc nào tất cả các thực thể trong phần mềm đều có thể tuân thủ nguyên lý Thay thế Liskov Nhưng mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho số lượng các thực thể tuân thủ nguyên lý là lớn nhất, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý iii) Việc tuân thủ nguyên lý Thay thế Liskov của... essential.” Chú ý i) Nguyên lý Nghịch đảo phụ thuộc có mối liên hệ mật thiết với nguyên lý OpenClosed Một khi nguyên lý Nghịch đảo phụ thuộc bị vi phạm, có nghĩa là những thành phần trong phần mềm phụ thuộc vào những cái riêng, cụ thể, việc nâng cấp, mở rộng ở những cái riêng, cụ thể (điều này rất thường xảy ra) buộc những thành phần phụ thuộc vào nó bị thay đổi theo Điều này dẫn đến vi phạm nguyên lý Open-Closed... kế thừa interface và sử dụng composition thay cho việc kế thừa Ý nghĩa: Nguyên lý Thay thế Liskov có mối liên hệ mật thiết với nguyên lý OpenClosed và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng Nó giúp nâng cao tính tái sử dụng và bền vững của phần mềm trước những sự thay đổi IV, Nguyên lý Phân tách interface (The Interface Segregation) 1 Phát biểu Không nên... doSomething(Vehicle vehicle) { vehicle.run(); vehicle.stop(); } Trong hai đoạn chương trình trên, đoạn chương trình thứ hai vẫn làm việc tốt khi chúng ta thêm vào các đối tượng khác cùng loại với “Car” mà kế thừa từ “Vehicle” Ý nghĩa: Nguyên lý Nghịch đảo phụ thuộc có mối liên hệ mật thiết với nguyên lý Open-Closed và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng Nó giúp cho... mềm vi phạm nguyên lý Nghịch đảo phụ thuộc sẽ có tính tái sử dụng (reusability) không cao Việc mang những thành phần này sử dụng vào một ngữ cảnh khác với những cái riêng, cụ thể khác là khó có thể thực hiện được nếu như không thực hiện việc chỉnh sửa nào trên chúng iv) Một quy ước trong lập trình hướng đối tượng giúp cho các thành phần trong phần 11 11 mềm tăng khả năng tuân thủ nguyên lý Nghịch đảo... phạm nguyên lý Thay thế Liskov Để hàm “doSomething” có thể làm việc được trên cả “Rectangle” và “Square” chúng ta phải chỉnh sửa lại nó Như vậy việc vi phạm nguyên lý Thay thế Liskov đã làm cho hàm “doSomething” vi phạm nguyên lý Open-Closed v) Nguyên lý Thay thế Liskov có mối liên hệ mật thiết với kỹ thuật “Design by Contract” được đề cập bởi Bertrand Meyers Kỹ thuật này chỉ ra rằng: mỗi phương thức trong... kế thừa từ một lớp đối tượng hỗ trợ một phần interface chúng cần và thực hiện composition đối với những đối tượng hỗ trợ phần interface còn lại Ý nghĩa Nguyên lý Phân tách interface có mối liên hệ với nguyên lý Open-Closed và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng Nó giúp giảm sự cồng kềnh, dư thừa không cần thiết cho phần mềm và quan trọng hơn là giảm . 11134279 MÔN: NGUYÊN LÝ NGÔN NGỮ LẬP TRÌNH ĐỀ TÀI: Nghiên cứu các vấn đề về nguyên lý ngôn ngữ lập trình hướng đối tượng và cài đặt thử nghiệm bài toán tự chọn bằng ngôn ngữ lập trình hướng đối. phạm nguyên lý Open-Closed. Khi đó ta nói hàm “func” vi phạm nguyên lý Thay thế Liskov. Chú ý i) Nguyên lý Thay thế Liskov có mối liên hệ mật thiết với Nguyên lý Open-Closed. Sự vi phạm nguyên. rộng thỏa nguyên lý. ii) Việc tuân thủ nguyên lý Open-Closed của một thực thể phần mềm chỉ mang tính tương đối, phụ thuộc vào ngữ cảnh. Có thể trong ngữ cảnh này, thực thể thỏa nguyên lý, nhưng