Open

Tiếp nối loạt bài viết dịch cuốn sách "Agile Software Development, Principles Patterns và Practices", ngày hôm nay, bọn họ đến với cơ chế thức nhị trong thi công linh hoạt, chính là OCP.

Bạn đang xem: Open

Nguyên tắc đóng góp mở - Open-Closed Principle

*

Dutch Door - (danh từ) Một cánh cửa được chia làm hai phần theo hướng ngang, do thế mỗi yếu tắc đều có thể mở thanh lịch trái hoặc đóng.

The American Heritage - Dictionary of the English Language: Fourth Edition. 2000

Ivar từng nói, "Tất cả hệ thống đều biến hóa trong vòng đời của nó. Cần luôn có vào đầu suy xét xây dựng một hệ thống tồn tại lâu dài hơn nữa những phiên bản đầu tiên". Làm phương pháp nào để bọn họ thiết kế đông đảo phiên bản ổn định với những đổi khác và tổn tại thọ dài? Betrand Meyer cho bọn họ định hướng từ năm 1988 với cái tên Nguyên tắc đóng mở (Open-Closed Principle).

OCP: cơ chế đóng mở (Open-Closed Principle)

Các thành phần của phần mềm (class, mô-đun, hàm,...) phải mở mang đến sự mở rộng nhưng đóng với sự thay đổi

Khi một chuyển đổi ở lịch trình dẫn đến biến hóa ở những thành phần, xây cất sẽ tất cả mùi cứng nhắc (Rigidity). OCP cho họ lời răn dạy về việc tái cấu tạo chương trình, nhằm các biến hóa sẽ không gây nên vượt nhiều chuyển đổi trong những thành phần của chương trình. Ví như OCP được thực hiện đúng, những biến đổi kiểu này sẽ giành được bằng vấn đề viết thêm hầu hết dòng code, ko phải biến đổi những chiếc code cũ đã hoạt động tốt.

Đây có vẻ như là kim chỉ nam quá xa cách - một mục tiêu vàng gần như là không thể dành được - tuy nhiên, thực tế có rất nhiều chiến lược đơn giản dễ dàng và kết quả giúp dành được lý tưởng này.

Mô tả

Mô-đun thoả mãn hiệ tượng đóng mở sẽ có được hai tính chất.

"Mở cho sự mở rộng" - "Open for extension"

Điều đó có nghĩa là hành vi của mô-đun hoàn toàn có thể mở rộng. Khi yêu cầu khối hệ thống thay đổi, chúng ta cũng có thể mở rộng lớn mô-đun để rất có thể đáp ứng những hành vi new thoả mãn yêu thương cầu. Nói một giải pháp khác, chúng ta có thể thay đổi cách mà mô-đun làm việc.

"Đóng với sự thay đổi" - "Closed for modification"

Mở rộng mô-đun không kéo theo việc thay đổi mã mối cung cấp của mô-đun. Tập tin cất mã nhị phân vào vai trò tiến hành của mô-đun, hoặc là các thư viện liên kết, DLL tuyệt Java .jar đều không bị đụng va đến.

Có vẻ hai tính chất này đang xích míc và trái ngược nhau. Các thông thường để mở rộng hành vi của mô-đun là chuyển đổi nó. Một mô-đun không bị chuyển đổi thông thường xuyên đã gồm hành vi nuốm định.

Làm phương pháp nào để một mô-đun rất có thể được đổi khác mà không đổi khác mã nguồn của nó? Làm giải pháp nào để biến hóa cách nhưng mà mô-đun làm việc, nhưng không biến hóa mô-đun?

Trừu tượng là chìa khoá

Trong C++, Java hay bất kể ngôn ngữ thiết kế hướng đối tượng nào (OOPL), bạn cũng có thể trừu tượng hóa những hành vi lý lẽ ngay tự trước trong một nhóm giới hạn max các hành vi gồm thể.Sự trừu tượng biểu lộ ở class trừu tượng cơ sở, trong những lúc một lương không giới hạn các hành vi có thể được thể hiện ở các class quá kế từ class cơ sở.

Chúng ta trả toàn hoàn toàn có thể điều khiển một mô-đun dưới hiệ tượng trừu tượng. Rất nhiều mô-đun như vậy rất có thể đóng với sự chuyển đổi bởi chúng nhờ vào vào một tờ trừu tượng sẽ được cầm định.Tuy nhiên, hành vi của mô-đun đó rất có thể mở rộng bằng phương pháp tạo ra class tạo ra từ lớp trừu tượng.

Hình 9-1 thể hiện một thiết kế đơn giản và dễ dàng không thỏa mãn nhu cầu OCP. Cả class Client và Server phần lớn rời rạc. Client áp dụng class Server. Nếu bọn họ mong chờ đối tượng người tiêu dùng Client sử dụng các đối tượng người dùng Server khác nhau,class Client cần chuyển đổi để hotline tên class vps mới.

*

Hình 9-2 cho thấy thêm một thiết kế phù hợp, vừa lòng OCP. Trong trường phù hợp này, class Client
Interface là một trong những lớp trừu tượng với thủ tục trừu tượng. Class Client áp dụng tính trừu tượng này, tuy nhiênđối tượng của class Client phải sử dụng đối tượng người sử dụng được sinh ra từ class Server. Nếu chúng ta muốn đối tượng người sử dụng của class Client sử dụng đối tượng người tiêu dùng khác của class Server,khi đó một phiên bạn dạng khác xuất hiện từ Client
Interface có thể được chế tạo ra. Vì vậy, class Client rất có thể giữ ko đổi.

*

Class Client tất cả một vài quá trình cần làm, vì thế nó khái niệm những quá trình đó vào lớp trừu tượng Client
Interface. Những lớp bé của Client
Interface hoàn toàn có thể định nghĩa theo bất kỳ cách làm sao mà chúng muốn.Do vậy, hành động của Client hoàn toàn có thể mở rộng và cố gắng đổi bằng cách tạo ra lớp con của Client
Interface.

Bạn hoàn toàn có thể đặt câu hỏi, lý do tôi đánh tên là Client
Interface như trên. Vì sao tôi không hotline là Abstract
Interface? Lý do, sẽ tựa như các gì họ thấy sinh sống sau,class trừu tượng sẽ gần gũi với class áp dụng nó hơn là class thực hiện nó.

Hình 9-3 biểu hiện một kiến trúc khác. Class Policy tất cả một tập những phương thức công khai nhằm thực hiện chính sách của một vài đối tượng. Hệt như với những phương thức của Client ở hình 9-2.Cũng như trên, số đông hàm thực hiện chế độ đó quan niệm một số quá trình cần được thực hiện trong phạm trù của một lớp trừu tượng.Tuy nhiên, trong trường hợp này, lớp trừu tượng là một trong những phần của chính lớp Policy. Trong C++, nó cần là một hàm ảo đơn thuần (pure virtual function) cùng trong Java chúng bắt buộc là cách thức trừu tượng (abstract method).Những hàm này được định nghĩa trong các lớp kề cận của Policy. Vày vậy, các hành vi được chỉ dẫn trong class Policy rất có thể mở rộng lớn và đổi khác trong những lớp kề cận được hiện ra từ Policy.

*

Hai quy mô trên là hai cách phổ biến nhất để thỏa mãn nhu cầu OCP. Nó cho biết thêm sự bóc biệt rõ ràng giữa các hàm bao quát với những hàm chi tiết được chế tác ra.

Ứng dụng Shape

Ví dụ sau được nêu ra trong không ít sách về kiến thiết hướng đối tượng (OOD). Nó là một trong ví dụ sai lạc nổi giờ "Shape". Nó thường được sử dụng để miêu tả cách mà đa hình hoạt động.Tuy nhiên, bọn họ sẽ dùng nó sinh hoạt đây để làm rõ OCP.

Chúng ta gồm một ứng dụng rất có thể vẽ hình tròn và hình vuông vắn trên giao diện bối cảnh cơ bản. Hình tròn và hình vuông vắn cần được vẽ theo một lắp thêm tự nhất định. Một danh sách những hình trụ và hình vuông sẽ được tạo nên theo một sản phẩm tự ưa thích hợp,và chương trình bắt buộc kiểm tra lần lượt danh sách đó với vẽ những hình đam mê hợp.

** phạm luật OCP **

Trong C, thực hiện lập trình giấy tờ thủ tục sẽ không vừa lòng OCP. Bạn có thể giải việc như đoạn code dưới đây. Ở đây chúng ta định nghĩa một tập các cấu tạo dữ liệu bao gồm khởi tạo hệt nhau nhưng sẽ khác biệt khi chạy chương trình.Thành phần đầu tiên của mỗi cấu trúc sẽ là một trong những mã để rành mạch xem kia là hình vuông hay hình chữ nhật. Hàm Draw
All
Shapes chuyên chú một mảng các con trỏ đến kết cấu dữ liệu này,kiểm tra mã hình kế tiếp gọi hàm thích hợp (Draw
Circle giỏi Draw
Square).

// -- shape.h --enum Shape
Type circle, square;struct Shape Shape
Type its
Type;// -- circle.h --struct Circle Shape
Type its
Type; double its
Radius; Point its
Center;void Draw
Circle(struct Circle*);// -- square.h --struct Square Shape
Type its
Type; double its
Side; Point its
Top
Left;void Draw
Square(struct Square*);// -- draw
All
Shapes.c --typedef struct Shape *Shape
Pointer;void Draw
All
Shapes(Shape
Pointer list<>, int n) int i; for (i = 0; i its
Type)case square: Draw
Square((Struct Square*) s); break;case circle: Draw
Circle((Struct Circle*) s); break; }Hàm Draw
All
Shapes không vừa lòng OCP bởi nó không thể đóng góp với một loại hình mới. Nếu như tôi muốn không ngừng mở rộng hàm này để có thể vẽ một danh sách hình trong số đó có cả hình tam giác,tôi vẫn phải biến hóa chính hàm này. Thực sự, tôi buộc phải phải biến hóa hàm này để nó có thể chấp nhận bất cứ hình gì.

Đương nhiên lịch trình trên là 1 trong những chương trình rất đối kháng giản. Vào thực tế, câu lệnh switch trong hàm Draw
All
Shapes sẽ nên lặp đi lặp lại không hề ít lần ở các hàm trong toàn ứng dụng,mỗi hàm sẽ có một các bước hơi khác biệt một chút. Đó rất có thể là hàm để kéo thả hình, không ngừng mở rộng hình, dịch rời hình, xóa,... Câu hỏi thêm một hình cho vận dụng loại này tức là sẽ nên săn tìm toàn bộ những vị trí mới có câu lệnh switch,(hoặc rất có thể là if/else) và sau đó là thêm cùng với hình mới.

Hơn nữa, họ không có thể là các câu lệnh switch hay if/else sẽ tiến hành tổ chức y như trong hàm Draw
All
Shapes. Trong thực tế, điều thường diễn ra là chúng ta sẽ kết hợp câu lệnh điều kiện của if với những toán tử logic, hoặc ghép những trường đúng theo của câu lệnh switchlại để "đơn giản hóa" phép toán logic của bọn chúng ta. Trong một vài ngôi trường hợp, sẽ sở hữu được những hàm thao tác với hình vuông như nhau với hình tròn. đầy đủ hàm này còn chả có câu lệnh switch tốt if/else.Do vậy, sự việc của việc tìm kiếm với hiểu tất cả những địa điểm mà hình mới đề nghị thêm vào trở phải không dễ dàng và đơn giản chút nào.

Tiếp theo, hành để ý loại biến hóa mà họ sẽ làm. Chúng ta cần thêm 1 thành viên cho kiểu tài liệu enum Shape
Type. Bởi toàn bộ hình đang phục ở trong vào dạng hình dự liệu này, chúng ta sẽ phải biên dịch lại bọn chúng từ đầu. Bọn họ cũng đề xuất biên dịch lại toàn bộ các mô-đun có liên quan đến Shape.

Do vậy, họ không đều chỉ phải biến đổi câu lệnh switch xuất xắc if/else, ngoài ra phải đổi khác các tập tin nhị phân (thông qua quá trình biên dịch lại) của toàn bộ các mô-đun sử dụng cấu trúc dữ liệu Shape.Thay thay đổi tập tin nhị phân có nghĩa là biến đổi DLL, thư viện share hay bất cứ thành phần nhị phân nào gồm liên quan. Hành động đơn giản dễ dàng là thêm 1 hình kéo theo sản phẩm loạt biến hóa đến hệ thống từ mã nguồn cho tới các tập tin nhị phân.Rõ ràng, tác động của việc thêm một hình là khôn cùng lớn.

** thiết kế tồi.**

Cùng chú ý lại một lần nữa. Giải mã đưa ra sống trên là cứng nhắc (Rigid) bởi việc thêm hình tam giác tạo cho Shape, Square, Circle, Draw
All
Shapes cần được biên dịch lại.Nó dễ vỡ (Fragile) bởi không ít câu lệnh switch/case hoặc if/else khó để tìm kiếm kiếm tương tự như sửa chữa đúng đắn. Nó bất động (Immobile) bởi bất kể ai ước ao tái sử dụng Draw
All
Shapes trong lịch trình khác sẽ đề xuất mang theo cả Square cùng Circle của cả khi bọn họ không yêu cầu nó.Do vậy, đoạn code trên đang có quá nhiều dấu hiệu của thiết kế tồi.

** thỏa mãn nhu cầu OCP **

Đoạn code sau đây cung ứng lời giải cho việc hình tròn/ hình vuông vắn thỏa mãn OCP. Vào trường hợp này, bọn họ tạo ra một tờ trừu tượng Shape. Lớp trừu tượng này có một hàm trừu tượng là Draw.Cả nhì class Circle với Square đông đảo được xuất hiện từ class Shape.

// giải thuật OOD cho câu hỏi Square/Circleclass Shape public: virtual void Draw() const = 0;;class Square : public Shape public: virtual void Draw() const;;class Circle : public Shape public: virtual void Draw() const;;void Draw
All
Shapes(vector& list) vector::iterator i; for (i=list.begin(); i != list.end(); i++) (*i)->Draw(); Chú ý rằng nếu bọn họ muốn không ngừng mở rộng hành vi của hàm Draw
All
Shapes để vẽ được hình khác, tất cả những gì họ cần là tạo thành một class sinh từ Shape. Hàm Draw
All
Shapes không cần thiết phải thay đổi.Do vậy hàm Draw
All
Shapes thỏa mãn nhu cầu OCP. Hành vi của nó rất có thể mở rộng nhưng không cần biến đổi nó. Thiệt sự, bài toán thêm class Triangle tuyệt đối không tạo thành bất cứ tác động nào đến bất kể mô-đun như thế nào đã tạo ra.Rõ ràng một vài thành phần của hệ thống cần đổi khác để thao tác với class Triangle, nhưng tất cả những cái code ở trên phần nhiều không đề nghị thay đổi.

Trong thực tế, class Shape tất cả thể có rất nhiều phương thức hơn. Mặc dù nhiên, việc thêm hình vào trong ứng dụng của họ là rất đơn giản dễ dàng bởi tất cả những gì họ cần là tạo thêm class thực hiện Shape.Chúng ta không nhất thiết phải dò tra cứu toàn vận dụng xem ở đâu cần nắm đổi. Bởi vì vậy, đó là một giải thuật không dễ dàng vỡ (not Fragile).

Nó cũng không cứng ngắc (not Rigid). Không tồn tại mã mối cung cấp nào nên thay đổi, và nếu không tồn tại ngoại lệ, thì cũng không có tập tin nhị phân làm sao bị nắm đổi. Mô-đun tạo nên thực thể cho class mới thực hiện Shape buộc phải thay đổi. Thường thì là ngơi nghỉ main hoặc hàm nhưng main điện thoại tư vấn tới, hoặc cách thức của đối tượng tạo ra bởi vì main.

Xem thêm: Tìm Hiểu Về Osd Là Gì? ? Tìm Hiểu Về Osd, Khi Nào Cần Dùng Tới Osd

Cuối cùng, đó là một giải mã không bất tỉnh (not Immobile). Draw
All
Shapes có thể tái thực hiện ở bất kể ứng dụng như thế nào mà không cần thiết phải mang theo Square tuyệt Circle. Bởi vậy, lời giải này không tồn tại dấu hiệu của bất kể đặc tính nào của xây dựng tồi.

Lời giải này thỏa mãn nhu cầu OCP. Nó rất có thể thay đổi bằng phương pháp thêm code mới, chứ chưa hẳn sửa code gồm sẵn. vị vậy, nó không khiến ra các thay đổi ở đầy đủ chương trình liên quan. Sự thay đổi duy duy nhất là việc thêm mô-đun và biến đổi liên quan mang đến main cho phép thực thể bắt đầu được chế tác ra.

** OK, tôi sẽ nói dối **

Ví dụ trên là một ví dụ hoàn toàn có trơ trẽn tự. Hãy chăm chú điều gì xảy ra với Draw
All
Shapes nếu họ quyết định tất cả các hình trụ cần được vẽ trước hình vuông.Hàm Draw
All
Shapes tất yêu đóng với những đổi khác như vậy. Để thực hiện biến hóa đó, bạn phải vào trong hàm Draw
All
Shapes, kiểm tra toàn bộ hình tròn, rồi bắt đầu đến hình vuông.

** dự đoán và phong cách thiết kế "tự nhiên" **

Liệu chúng ta đã dự kiến được kiểu biến đổi này và chỉ dẫn một lớp trừu tượng bảo vệ chúng ta ngoài nó. Biện pháp trừu tượng hóa chuyển ra ở phần code trên chỉ làm cho chương ngại ngùng cho bọn họ với loại đổi khác này, hơn là 1 trong những sự góp đỡ.Bạn hoàn toàn có thể bất ngờ. Mà lại cuối cùng, điều gì rất có thể tự nhiên rộng một lớp Shape làm cửa hàng để Square cùng Circle sinh ra? vì sao mô hình thoải mái và tự nhiên này lại không hẳn mô hình giỏi nhất?
Đáp án ví dụ là quy mô sẽ KHÔNG thoải mái và tự nhiên trong khối hệ thống mà thứ tự đặc trưng hơn kiểu hình dạng.

Nó đưa bọn họ đến một tóm lại phiền phức. Một biện pháp tổng quá, không cần biết mô-đun của doanh nghiệp "đóng" như thế nào, sẽ luôn có một loại chuyển đổi biến nó thành không đóng. Không có mô hình nào tự nhiên trong hầu hết hoàn cảnh!

Bởi tính đóng không thể hoàn thành xong được, nó cần phải xử lý một biện pháp chiến lược. Gồm nghĩa là, người xây đắp cần tuyển lựa loại chuyển đổi so cùng với cái rất có thể đóng xây cất của họ.Anh ta phải dự đoàn hầu như các đổi khác có thể xảy ra, và tiếp nối xây dựng phong cách xây dựng trừu tượng để đảm bảo an toàn mình khỏi đổi khác đó.

Điều này đề nghị nhiều kinh nghiệm của fan thiết kế. Người thiết kế có ghê nghiệm mong muốn anh ta biết được người dùng và môi trường sale đủ để hoàn toàn có thể dự đoán các loại biến hóa đến hệ thống. Sau đó, anh ta thực hiện OCP để đáp ứng đổi khác có gia tốc cao nhất.

Đây chưa phải là điều solo giản. Lúc lập trình viên đoán đúng, họ thắng. Khi họ đoán sai, bọn họ thua. Với họ thường đoán sai phần lớn các trường hợp.

Thêm vào đó, thỏa mãn nhu cầu được OCP siêu tốn kém. Nó tiêu tốn không ít thời gian phát triển và cố gắng nỗ lực để tạo thành một phong cách thiết kế hợp lý. Tính trừu tượng cũng làm tăng thêm độ phức tạp của ứng dụng. Gồm một lượng số lượng giới hạn sự trừu tượng mà lập trình viên hoàn toàn có thể đáp ứng được.Rõ ràng, chúng ta cần giới hạn OCP cho 1 những đổi khác hay xẩy ra nhất.

Làm cách nào chúng ta biết được đổi khác nào dễ xảy ra? bọn họ cần nghiên cứu và phân tích hợp lý, hỏi thắc mắc hợp lý, và dùng kinh nghiệm của bản thân mình cũng giống như các kiến thức chung. Cùng cuối cùng, chúng ta đợi cho khi chuyển đổi diễn ra!

** mang lại "lưỡi câu" vào vào **

Làm bí quyết nào bọn chúng ta bảo đảm mình trước đa số thay đổi? Ở cầm cố kỷ trước, công ty chúng tôi có một câu nói. Chúng ta nên "cho lười câu vào trong" cho biến đổi mà chúng ta nghĩ là nó có thể xảy ra. Công ty chúng tôi nghĩ rằng điều đó hoàn toàn có thể giúp ứng dụng trở yêu cầu mềm dẻo.

Tuy nhiên, lưỡi câu cửa hàng chúng tôi cho vào hay sai lầm. Sai lầm hơn nữa, nó lại có tín hiệu của sự phức tạp không cần thiết (Needless Complexity) cần phải hộ trợ vào bảo trì, kể cả khi chúng không được dùng đến. Đó ko phải là 1 trong điều tốt. Chúng ta không mong sử dụng một thiết kế có rất nhiều lớp trừu tượng.Thay vào đó, chúng ta thường đợi cho tới khi chúng ta thực sự yêu cầu trừu tượng hóa, rồi mới cải tiến và phát triển nó.

** lừa gạt tôi một lần... **

Có một lời nói từ xa xưa: "Lừa tôi một lần, bạn xấu hổ. Lừa gạt tôi nhì lần, tôi xấu hổ." Đây là 1 thái độ khỏe mạnh trong kiến thiết phần mềm.Để vận dụng của họ thoát khỏi sự tinh vi không quan trọng (Needless Complexity), bạn có thể cho phép bản thân lừa bản thân một lần. Gồm nghĩa là bọn họ viết code và hy vọng sẽ không có thay đổi.Khi biến đổi xảy ra, bọn họ xây dựng lớp trừu tượng để bảo đảm mình khỏi những đổi khác trong sau này có dạng đó. Nói ngắn gọn, bọn họ tóm viên đạn đầu tiên, và chắc chắn là rằng mình sẽ được đảm bảo từ bất cứ viên đạn nào phun ra từ cùng khẩu súng đó.

** mô phỏng thay đổi **

Nếu bọn họ quyết định cầm viên đạn đầu tiên, bọn chúng ta có lợi thế hiểu rằng hướng cất cánh của viên đạn mau chóng hơn. Bọn họ biết được loại chuyển đổi có thể diễn ra trước khi họ đi thừa xa trong suốt thời gian phát triển.Chúng ta càng chờ lâu giúp thấy được thay đổi đó, bọn họ càng cạnh tranh để tạo ra một lớp trừu tượng đúng theo lý.

Do vậy, bọn họ cần mô phỏng thay đổi. Chúng ta làm điều đó thông qua một loạt cuộc thỏa luận chỉ dẫn ở chương 2.

Chúng ta viết kịch phiên bản kiểm demo trước. Kiểm thử là một loại hình sử dụng hệ thống. Bằng cách viết kiểm thử trước, họ buộc khối hệ thống trở nên có thể kiểm test được (testable).Do vậy, chuyển đổi trong một hệ thống hoàn toàn có thể kiểm thử sẽ không làm họ quá bất ngờ sau đó. Chúng ta sẽ đề nghị xây dựng lớp trừu tượng hoàn toàn có thể kiểm test được. Chúng ta sẽ thấy rằng không hề ít trong số các lớp trừu tượng kia giúp ích họ khi các chuyển đổi sau này diễn ra.Chúng ta cải tiến và phát triển trên càng vòng đời ngắn. Vài ba ngày thay vị vài tuần.Chúng ta cải cách và phát triển các công dụng trước đại lý hạ tầng, và thường xuyên cho các bên liên quan thấy các tính năng đã có tác dụng được.Chúng ta phát triển các chức năng quan trọng duy nhất trước.Chúng ta phân phối ứng dụng nhanh cùng thường xuyên. Chúng ta đưa nó mang đến với người sử dụng và người dùng gấp rút và liên tục nhất bao gồm thể.

** áp dụng sự trừu tượng để giành được tính đóng góp một biện pháp minh bạch **

OK, vậy họ đã tóm được viên đạn đầu tiên. Người tiêu dùng muốn vẽ hình tròn trụ trước hình vuông. Giờ bọn họ phải bảo vệ bản thân ngoài những biến hóa có dạng này vào tương lai.

Làm giải pháp nào để chúng ta đóng được hàm Draw
All
Shapes trước các đổi khác về vật dụng tự vẽ? hãy nhờ rằng tính đóng nhờ vào vào sự trừu tượng. Vì vậy, để đóng được hàm Draw
All
Shapes trước sự việc thay đổi,chúng ta nên sự trừu tượng về lắp thêm tự. Nhiều loại trừu tượng này cung ứng một lớp rất có thể mô tả được trang bị tự vẽ.

Mỗi quy tắc sắp xếp sẽ bao gồm hai đối tượng, để hoàn toàn có thể xác định đối tượng người tiêu dùng nào được vẽ trước. Chúng ta cũng có thể định nghĩa cách thức trừu tượng cho Shape thương hiệu là Precedes.Hàm này thừa nhận một hình khác làm cho tham số và trả về quý hiếm luận lý (boolean). Kết quả là đúng (true) nếu đối tượng người dùng Shape nhận được thông tin cần được vẽ trước khi đối tượng người dùng Shape được truyền vào bên dưới dạng tham số.

Trong C++, phương thức có dạng này được biểu hiện dưới dạng operator. Đoạn code dưới đây mô tả class Shape sẽ ra sao khi gồm thêm phương thức sắp xếp.

// Shape with ordering methodclass Shape{ public:virtual void Draw() const = 0;virtual bool Precedes(const Shape&) const = 0;bool operator
Đến đây, bạn cũng có thể xác định quan tiền hệ sắp xếp giữa hai đối tượng người dùng Shape. Chúng ta có thể sắp xếp bọn chúng rồi mới vẽ. Đoạn code sau viết bằng C++ sẽ thực hiện công việc đó.

// Draw
All
Shapes with Orderingtemplate class Lessp // utility for sorting container or pointers{ public: bool operator()(const p p, const phường q) return (*p) và list) vector ordered
List = list; sort(ordered
List.begin(), ordered
List.end(), Lessp*()); vector::const_iterator i; for (i=ordered
List.begin(); i Draw();Bây giờ chúng ta cũng có thể vẽ hình cùng vẽ theo sản phẩm tự định sẵn. Mặc dù có vẻ họ chưa có giải pháp cho việc vẽ theo sản phẩm công nghệ tự sút dần mà bài toán yêu cầu. Bởi vì vậy, bọn họ cần sửa hàm Precedes của class Shape trong các lớp nhỏ để chỉ định và hướng dẫn thứ tự chuẩn bị xếp. Làm bí quyết nào nhằm thự hiện nay điều đó?
Dòng code nào phải ghi ngơi nghỉ Circle::Precedes để bảo đảm hình tròn sẽ tiến hành vẽ trước hình vuông? chú ý đoạn code sau.

// Ordering a Circlebool Circle::Precedes(const Shape& s) const if (dynamic_cast(s)) return true; else return false;Rõ ràng ở thủ tục trên, cũng như những người anh em của nó cùng hiện ra từ Shape, không vừa lòng OCP. Không có cách nào nhằm đóng chúng trước đều lớp con mới của Shape.Mỗi khi bao gồm một lớp nhỏ được sinh ra, toàn bộ các hàm Precedes yêu cầu thay đổi.

Tất nhiên sẽ chẳng có vấn đề gì nếu không có thêm lớp con nào sinh ra từ Shape. Ngược lại, nếu bọn chúng được tạo ra thường xuyên, xây cất sẽ phải biến đổi rất nhiều. Vậy, một lần nữa, chúng ta lại bắt được viên đạn.

** sử dụng cách tiếp cận kim chỉ nan từ dữ liệu để dành được tính đóng góp **

Nếu chúng ta muốn đóng các con của Shape để bọn chúng không nên biết các con khác, bạn cũng có thể tiếp cận từ dữ liệu. Dưới đấy là một giải pháp.

// Cơ chế thống trị sắp xếp áp dụng bảng#include #include #include using namespace std;class Shape public: virtual void Draw() const = 0;bool Precedes(const Shape&) const;bool operator= 0) && (this
Ord >= 0)) done = true;else // table entry == 0 done = true; return this
Ord bằng cách tiếp cận này, bọn họ đã thành công trong việc đóng hàm Draw
All
Shapes trước những đổi khác về vật dụng tự các hình, trong số ấy có việc thêm hình new hoặc thay đổi thứ trường đoản cú sẵn gồm (ví dụ vẽ hình vuông trước hình tròn).

Có duy nhất một nhân tố không đóng góp trước những đổi khác về vật dụng tự là bảng của Shape. Bảng này hoàn toàn có thể được đặt ở một mô-đun riêng rẽ của Shape, tách bóc biệt với những mô-đun còn lại cho nên thay đổi ở đó không ảnh hưởng đến mô-đun khác.Thực tế, cùng với C++, bạn cũng có thể lựa chọn bảng như thế nào sẽ sử dụng trong khi tùy chỉnh liên kết.

Kết luận

Theo các cách, OCP là trái tim của thiết kế hướng đối tượng. Thỏa mãn nhu cầu nguyên tắc này là vấn đề tạo nên lợi ích lớn nhất từ kỹ thuật lập trình hướng đối tượng (tính mượt dẻo, tính tái sử dụng được, tính bảo trì,...). Mặc dù nhiên, vừa lòng được nguyên lý này không đạt được một cách dễ dàng bởi sử dụng ngôn từ lập trình hướng đối tượng.Cũng như không nên áp dụng hàng tá lớp trừu tượng cho toàn bộ các yếu tắc của ứng dụng. Thế vào đó, nó yêu mong lập trình viên thực hiện tính trừu tượng cho hồ hết phần mà liên tiếp có đổi khác một cách rõ ràng.Chống lại sự trừu tượng ở dạng non trẻ cũng quan trọng đặc biệt như phiên bản thân sự trừu tượng.

Bạn đọc có thể tham khảo slide sau của tôi để có được cái nhìn bao quát về 5 nguyên tắc thiết kế linh hoạt:http://www.slideshare.net/dinhhoanglong91/object-oriented-design-principle

Bạn sẽ tìm kiếm chân thành và ý nghĩa của OCP? trên hình ảnh sau đây, chúng ta cũng có thể thấy các định nghĩa chính của OCP. Nếu như khách hàng muốn, bạn có thể tải xuống tệp hình ảnh để in hoặc chúng ta có thể chia sẻ nó với anh em của bản thân qua Facebook, Twitter, Pinterest, Google, v.v. Để xem tất cả chân thành và ý nghĩa của OCP, vui vẻ cuộn xuống. Danh sách vừa đủ các định nghĩa được hiển thị vào bảng dưới đây theo sản phẩm công nghệ tự bảng chữ cái.

Ý nghĩa bao gồm của OCP

Hình ảnh sau đây trình bày ý nghĩa sâu sắc được sử dụng thông dụng nhất của OCP. Chúng ta có thể gửi tệp hình ảnh ở định hình PNG để áp dụng ngoại tuyến hoặc gởi cho bằng hữu qua email.Nếu bạn là quản trị website của website phi yêu mến mại, phấn kích xuất phiên bản hình ảnh của định nghĩa OCP trên trang web của bạn.

*


Tất cả những định nghĩa của OCP

Như đã đề cập sinh hoạt trên, bạn sẽ thấy toàn bộ các chân thành và ý nghĩa của OCP vào bảng sau. Xin biết rằng tất cả các khái niệm được liệt kê theo sản phẩm tự bảng chữ cái.Bạn rất có thể nhấp vào links ở bên phải để xem thông tin cụ thể của từng định nghĩa, bao hàm các định nghĩa bởi tiếng Anh và ngữ điệu địa phương của bạn.
từ viết tắtĐịnh nghĩa
OCPBan đầu Chris phần
OCPBáo chí công giáo Oregon
OCPBãi đậu xe xung quanh đất
OCPBên ngoài toàn cảnh vấn đề
OCPBảo vệ người sử dụng khác
OCPBộ xử lý tin tức liên lạc OSIS
OCPBộ cách xử trí đơn đặt hàng mã
OCPBộ tinh chỉnh và điều khiển quang học tập gói
OCPBột yến mạch bánh Pie
OCPCapellan Central de Proyectos
OCPChính sách một con
OCPChương trình bảo tồn của Owston Cầy
OCPChương trình hoạt động máy tính
OCPChương trình tín dụng Off-Campus
OCPChương trình điều khiển onchocerciasis
OCPChủ cài đặt và những nhà thầu chính sách trách nhiệm bảo vệ
OCPChủ tịch câu lạc cỗ xuất sắc
OCPCác tủ đồ mở chương trình
OCPCác cộng đồng chính thống trên Penn
OCPCông ty đơn vị hát Philadelphia
OCPCúp phối kết hợp giao thức
OCPCấu hình vận động chế biến
OCPCựu nhân loại hội nghị sống âm vị học
OCPDự án thương mại dịch vụ quỹ đạo
OCPGiao thức mở cửa hàng
OCPGiao thức mở lõi
OCPHoạt hễ chỉ huy
OCPHành tinh của cửa hàng chúng tôi thay đổi
OCPKhuôn viên ngôi trường trực tuyến Passau
OCPKý sinh trùng trứng u nang
OCPKế hoạch đồng ý của cùng đồng
OCPKế hoạch chấp thuận của thành phố
OCPKế hoạch vận động truyền thông
OCPKế hoạch tổ chức triển khai khái niệm
OCPMáy bay tinh chỉnh quang học
OCPMáy bơm dầu giữ hành
OCPMáy nhắn tin Centennial Olympic
OCPMắt Cicatricial Pemphigoid
OCPMột cái xe Pile-Up
OCPMột cộng đồng quan hệ đối tác
OCPMột một trong những thành phần Plasma
OCPNguyên tắc đóng cửa mở
OCPNguyên tắc đường viền bắt buộc
OCPNgười đùa thuộc địa cũ
OCPNền tảng mở điều khiển
OCPOPSEC Certified Professional
OCPOasis máy vi tính sản phẩm
OCPOfcom chi tiêu và sử dụng bảng
OCPOld thành phố Park
OCPOld tp Publishing, Inc
OCPOleoducto de Crudos Pesados
OCPOmaha xã hội Playhouse
OCPOntario nhà phân phối ngô
OCPOracle Certified Professional
OCPOracle Certified đối tác
OCPOracle chứng nhận chương trình
OCPOregon trẻ nhỏ kế hoạch
OCPOrlando Christian Prep
OCPOver-tốc độ cỗ xử lý
OCPOverland thịnh hành điểm
OCPOxford Concordance chương trình
OCPOxford hóa học mồi
OCPPa-nen tinh chỉnh hoạt động
OCPPhốt phát Octacalcium
OCPQua bảo đảm hiện tại
OCPQuan hệ đối tác cộng đồng Oxfordshire
OCPQuan sát kiểm soát và điều hành trừng phạt
OCPQuan sát quy trình quan trọng
OCPQuang thông tin sản phẩm, Inc
OCPRa ngoài Ủy ban phần
OCPSản phẩm cầm tay Ohio
OCPSản phẩm hữu cơ hỗn loạn
OCPSản phẩm tiêu dùng Omni
OCPSản phẩm chi tiêu và sử dụng Omni
OCPThuốc trừ sâu organochlorine
OCPThực vật phía bên ngoài cáp
OCPTiềm năng mở mạch
OCPTrong tạo ra hoảng loạn
OCPTrên chip tham số
OCPTrên khuôn viên trường công tác khuyến mại, Inc
OCPTrường cao đẳng Ontario dược sĩ
OCPTùy chọn call kế hoạch
OCPTấn phong giáo sĩ người
OCPTổ chức tư tưởng học tư vấn
OCPTổ chức hỗ trợ tư vấn hợp tác LLP
OCPViên thuốc kị thai
OCPVăn chống bang de la dân
OCPVăn phòng cho những chương trình vốn
OCPVăn phòng công tác thương mại
OCPVăn chống của công tác phòng chống tội phạm
OCPVăn phòng của hợp đồng và cài đặt sắm
OCPVăn phòng kế hoạch vốn
OCPVăn phòng lắp thêm Photocopy chương trình
OCPVăn phòng nhân sự dân sự
OCPVấn đề tinh chỉnh và điều khiển tối ưu
OCPVề phương diện quang học tập Channelled Potentiator
OCPÁm hình ảnh cưỡng chế Poseur
OCPÉp xung so sánh trang
OCPĐại dương màu sắc tố
OCPĐại dương với khí hậu vật lý

Leave a Reply

Your email address will not be published. Required fields are marked *