BÁO cáo đồ án môn lập TRÌNH HưỚNG đối TưỢNG

BÁO CÁO ĐỒ ÁN MÔN LẬP TRÌNH HƯỚNG ĐỐI
TƯỢNG
ĐỀ TÀI : XÂY DỰNG TEMPLATE CHO STACK
LÝ THUYẾT:TÌM HIỂU COMPOSITE
A- TÌM HIỂU COMPOSITE
1 MỤC ĐÍCH
- Soạn các đối tượng vào cơ cấu cây để đại diện cho một phần – toàn bộ hệ
thống. Compsite cho phép khách hàng xử lý đối tượng cá nhân và tác phẩm
của các đối tượng thống nhất.
Tóm lại Composite là một tập hợp các đối tượng ,bất kỳ đối tượng nào trong tập
này đều có thể đóng vai trò đa hợp (Composite –chứa các đối tượng cùng loại),
hoặc chỉ là các đối tượng cơ bản (primitive object- không thể chứa đối tượng
cùng loại khác.Một đối tượng composite được tạo thành từ một hay nhiều đối
tượng tương tự nhau (hoặc có một số chức năng tương tự nhau). Ý tưởng ở đây
là có thể thao tác trên một nhóm đối tượng theo cách như thao tác trên một đối
tượng duy nhất. Các đối tượng của nhóm phải có các thao tác chung, hay còn
gọi là mẫu số chung nhỏ nhất.
2 ĐỘNG LỰC
Các ứng dụng đồ họa như biên tập bản vẽ và hệ thống chụp giản đồ cho
phép người dùng xây dựng sơ đồ phức tạp của các thành phần đơn giản.
Người sử dụng có thể nhóm các thành phần để tạo thành phần lớn hơn, do
đó có thể được nhóm lại để hình thành nên các thành phần lớn hơn. Một
hành động đơn giản có thể định nghĩa cho lớp đồ họa cơ bản chẳng hạn như
Text và Line cộng với các lớp khác mà hoạt động như bao hàm cho các cơ
bản đó. Nhưng có một vấn đề với cách tiếp cận này: Mã số sử dụng các lớp
này phải xử lý đối tượng cơ bản và bao hàm khác nhau, ngay cả khi hầu hết
thời gian người sử dụng xử lý chúng giống nhau. Phải phân biệt các đối
tượng này làm cho các ứng dụng phức tạp hơn. Mô hình Composite mô tả
cách sử dụng thành phần đệ quy để khách hàng không cần phải làm cho sự
khác biệt này
Chìa khóa để mô hình Composite là một lớp trừu tượng đại diện cho cả cơ bản và

sự bao hàm của chúng. Đối với hệ thống đồ họa, lớp này là Graphic. Graphic thiết
lập hoạt động như Draw được cụ thể cho các đối tượng đồ họa.
Nó cũng thiết lập hoạt động mà tất cả đối tượng Composite chia sẻ, giống như hoạt
động truy cập và quản lý con của nó. Các con Line, Rectangle , và Text (xem trước
sơ đồ lớp ) xác định đối tượng đồ họa cơ bản. Các lớp thực hiện: Draw để vẽ
đường ,hình chữ nhật, và văn bản , tương ứng. Từ đồ họa cơ bản không có con đồ
họa, không có những lớp con thực thi các hoạt động liên quan đến con .
Lớp Picture định nghĩa một tập hợp của các đối tượng Graphic . Picture thực thi
Draw gọi Draw trên con của nó, và nó thực hiện các hoạt động liên quan đến lớp
con cho phù hợp. Bởi vì giao diện Picture phù hợp với giao diện Graphic ,Đối
tượng Picture có thể sinh ra Picture đệ quy khác.Sơ đồ dưới đây cho thấy một cấu
trúc đối tượng Composite điển hình của đệ quy đối tượng Graphic :
3-KHẢ NĂNG ỨNG DỤNG
-Sử dụng mô hình Composite khi :
+ Bạn muốn đại diện cho bộ phận- toàn thể đối tượng .
+Bạn muốn khách hàng có thể bỏ qua sự khác biệt giữa các đối tượng
tổng quát và các đối tượng cá nhân. Khách hàng sẽ xử lý tất cả các đối tượng
trong cấu trúc tổng hợp thống nhất.
4-CẤU TRÚC
Một cấu trúc đối tượng tổng hợp điển hình có thể như sau:
5-NGƯỜI THAM DỰ
-Thành phần
Component (Graphic)
+Thiết lập giao diện cho các đối tượng trong thành phần.
+ Thực hiện cách xử lý mặc định cho giao diện chung cho tất cả
các lớp cho phù hợp.
+Thiết lập một giao diện để truy cập và quản lý các thành phần
con của nó.
+(tùy chọn) xác lập một giao diện để truy cập đến bố mẹ của
một thành phần trong cấu trúc đệ quy, và thực hiện nó nếu đó là phù

hợp.
Leaf (Rectangle, Line, Text, vv)
+Đại diện cho đối tượng lá trong thành phần. Một lá không có
con.
+Xác định cách xử lý cho các đối tượng cơ bản trong thành
phần.
Composite (Picture)
+ Xác định hành vi cho các thành phần có con.
+Lưu trữ thành phần con.
+Thực hiện các hoạt động liên quan đến thành phần con trong
giao diện phần.
Client
+ Điều khiển các đối tượng trong các thành phần thông qua
giao diện phần.
6-SỰ CỘNG TÁC
-Khách hàng sử dụng giao diện lớp Component để tương tác
với các đối tượng trong cơ cấu Composite. Nếu người nhận là một
Leaf, sau đó yêu cầu được xử lý trực tiếp. Nếu người nhận là một
Composite, sau đó nó thường chuyển tiếp yêu cầu các thành phần con
của nó, có thể thực hiện các hoạt động bổ sung trước khi và / hoặc sau
khi chuyển tiếp.
7-HỆ QUẢ
Mô hình Composite
+Xác định phân cấp lớp bao gồm các đối tượng cơ bản và các đối tượng
composite . Đối tượng cơ bản có thể được gộp lại tạo thành nhiều đối tượng phức
tạp, lần lượt có thể được gộp lại, và như vậy đệ quy. Bất cứ nơi nào mã số khách
hàng mong đợi một đối tượng cơ bản, nó cũng có thể có một đối tượng Composite.
+ Làm các khách hàng đơn giản. Khách hàng có thể xử lý và cấu trúc lại
Composite thống nhất đối tượng cá nhân. Khách hàng thường không biết (và
không nên quan tâm) cho dù họ đang đối phó với một Leaf hoặc một thành phần

Composite. Điều này đơn giản hoá mã khách hàng, bởi vì nó tránh phải viết chức
năng tag-and-case-statement-style qua các lớp mà xác định thành phần.
+ Làm cho nó dễ dàng hơn để thêm các loại mới của các thành phần. Vừa được
định nghĩa Composite hoặc lớp con Leaf làm việc tự động với cấu trúc hiện tại và
mã khách hàng. Khách hàng không cần phải thay đổi cho các lớp Component mới.
+ Có thể làm cho thiết kế của bạn quá chung chung. Những bất lợi làm cho nó dễ
dàng để thêm các thành phần mới điều đó làm cho nó khó khăn hơn để hạn chế các
thành phần của một Composite. Đôi khi bạn muốn có một Composite chỉ có một số
các thành phần. Với Composite, bạn không thể dựa vào loại hệ thống để thực thi
những khó khăn cho bạn. Bạn sẽ phải sử dụng kiểm tra thời gian chạy thay vì điều
đó.
8-THỰC HIỆN
Có nhiều vấn đề cần xem xét khi thực hiện mẫu Composite:
1-Tài liệu tham khảo rõ ràng:
Duy trì tài liệu tham khảo từ các thành phần con đến thành phần cha mẹ của chúng
có thể đơn giản hóa sự giao nhau và quản lý của một cấu trúc Composite. Tài liệu
tham khảo cha mẹ đơn giản hoá việc di chuyển lên cấu trúc và xóa một phần. Tài
liệu tham khảo cha mẹ cũng giúp hỗ trợ là mô hình Chain of Responsibility (251).
Vị trí thông thường để xác định tài liệu tham khảo cha mẹ là trong lớp Component.
Leaf và Composite những lớp có thể kế thừa tài liệu tham khảo và các hoạt động
mà quản lý nó. Với tài liệu tham khảo cha mẹ, nó là điều cần thiết để duy trì bất
biến mà tất cả Các con của một hỗn hợp có giống như cha mẹ của chúng hỗn hợp
lần lượt có chúng như trẻ em. Cách dễ nhất để đảm bảo điều này là để thay đổi một
thành phần mẹ của chỉ khi nó được thêm vào hoặc gỡ bỏ từ một hỗn hợp. Nếu điều
này có thể được thực hiện một lần trong Add và Remove hoạt động của Tổng hợp
lớp, sau đó nó có thể được thừa hưởng tất cả các lớp con, và bất biến sẽ được duy
trì tự động.
2. Chia sẻ các thành phần.
Nó thường hữu ích để chia sẻ các thành phần, ví dụ, để giảm các yêu cầu lưu trữ.
Nhưng khi một thành phần có thể có không quá một bố mẹ, các thành phần chia sẻ

trở nên khó khăn. Một giải pháp có thể là cho con lưu trữ nhiều cha mẹ. Nhưng
điều đó có thể dẫn đến sự mơ hồ như một yêu cầu truyền lên cấu trúc. Các mô hình
Flyweight (218) cho thấy cách làm lại một thiết kế để tránh các bậc cha mẹ lưu trữ
hoàn toàn. Nó hoạt động trong trường hợp con có thể tránh việc gửi yêu cầu bố mẹ
của một số bên ngoài hoặc tất cả các vị trí của họ.
3 . Tối đa hóa giao diện phần .
Một trong những mục tiêu của mô hình Composite là để làm cho người dùng
không biết về đặc thù các lớp Leaf hay Composite họ đang sử dụng . Để đạt được
mục tiêu này , lớp Component cần xác định nhiều hoạt động phổ biến cho
Composite và Leaf lớp càng tốt. Các Lớp Component thường cung cấp những cài
mặc định cho các hoạt động , và lớp Leaf và Composite lớp con sẽ ghi đè lên
chúng .Tuy nhiên , mục tiêu này sẽ đôi khi mâu thuẫn với các nguyên tắc của lớp
thiết kế hệ thống cấp bậc mà nói một lớp chỉ cần xác định các hoạt động có có ý
nghĩa cho lớp con của nó. Có rất nhiều hoạt động mà phần hỗ trợ mà dường như
không có ý nghĩa cho các lớp lá . Làm thế nào có thể phần cung cấp một thực hiện
mặc định cho chúng?Đôi khi một chút sáng tạo cho thấy một hoạt động mà sẽ xuất
hiện để có ý nghĩa chỉ cho Composites có thể được thực hiện cho tất cả các thành
phần của di chuyển nó vào lớp Component . Ví dụ, giao diện để truy cập lớp con là
một phần cơ bản của một lớp hỗn hợp nhưng không nhất thiết phải Lớp Leaf .
Nhưng nếu chúng ta xem một Leaf là một thành phần mà không bao giờ có con
,sau đó chúng ta có thể xác định một hoạt động mặc định để truy cập con trong
phần lớp mà không bao giờ trả về bất kỳ lớp con. Các Lớp Leaf có thể sử dụng
mặc định thực hiện, nhưng các lớp Composite sẽ thực thi lại nó để trở về lớp con
của chúng.Các hoạt động quản lý lớp con có nhiều phiền hà và được thảo luận
trong mục tiếp theo .
4 .Thiết lập các hoạt động quản lý lớp con.
Mặc dù lớp Composite thực hiện các hoạt động Add và Remove để quản lý lớp
con, quan trọng vấn đề trong mô hình hỗn hợp là có các lớp học tuyên bố các hoạt
động này trong hệ thống phân cấp lớp Composite. Chúng ta nên khai báo các hoạt
động trong Hợp phần và làm cho họ có ý nghĩa cho các lớp lá , hoặc chúng ta nên

khai báo và xác định họ chỉ trong Composite và lớp con của nó ? Quyết định liên
quan đến một thoả hiệp giữa an toàn và minh bạch :
Xác định giao diện quản lý lớp con ở thư mục gốc của lớp hệ thống phân cấp cho
bạn tính minh bạch , bởi vì bạn có thể xử lý tất cả thành phần thống nhất . Nó chi
phí bạn an toàn , tuy nhiên , bởi vì khách hàng có thể cố gắng làm những việc vô
nghĩa như thêm và loại bỏ các đối tượng từ Leaf .
Xác định quản lý lớp con trong lớp Composite mang lại cho bạn an toàn , bởi vì
bất kỳ nỗ lực để thêm hoặc loại bỏ các đối tượng từ lá sẽ bị bắt tại thời gian biên
dịch bằng một ngôn ngữ kiểu tĩnh như C + + . nhưng bạn bị mất tính minh bạch ,
bởi vì Leaf và Composite có khác nhau giao diện.
Chúng tôi đã nhấn mạnh tính minh bạch về an toàn trong mô hình này. Nếu bạn lựa
chọn cho an toàn , sau đó vào những thời điểm bạn có thể mất các loại thông tin và
phải chuyển đổi một thành phần thành một hỗn hợp . Làm thế nào bạn có thể làm
điều này mà không cần đến một nhập - không an toàn diễn viên ? Một cách tiếp
cận là để khai báo một hoạt động Composite * GetComposite () trong Lớp thành
phần . Thành phần cung cấp một hoạt động mặc định trả về một null con trỏ . Lớp
Somposite định nghĩa lại hoạt động này để trở về bản thân thông qua con trỏ này:
class Composite;
class Component {
public:
//
virtual Composite* GetComposite() { return 0; }
};
class Composite : public Component {
public:
void Add(Component*);
//
virtual Composite* GetComposite() { return this; }
};
class Leaf : public Component {

//
};
GetComposite lets you query a component to see if it's
a composite. You
can perform Add and Remove safely on the composite it
returns.
Composite* aComposite = new Composite;
Leaf* aLeaf = new Leaf;
Component* aComponent;
Composite* test;
aComponent = aComposite;
if (test = aComponent->GetComposite()) {
test->Add(new Leaf);
}
aComponent = aLeaf;
if (test = aComponent->GetComposite()) {
test->Add(new Leaf); // will not add leaf
}
Kiểm tra tương tự cho một Composite có thể được thực hiện bằng cách sử dụng
cấu trúc C + + dynamic_cast . Tất nhiên, vấn đề ở đây là chúng ta không xử lý với
tất cả các thành phần thống nhất. Chúng ta phải trở lại thử nghiệm với nhiều loại
khác nhau trước khi lấy hành động thích hợp. Cách duy nhất để cung cấp chính xác
là xác định mặc định Add và Remove hoạt động trong Component. Điều đó tạo ra
một vấn đề mới: Không có cách nào để thực hiện Component:: Add mà không cần
giới thiệu các khả năng của nó. Bạn có thể làm cho nó không làm gì cả, nhưng mà
bỏ qua một yếu tố quan trọng; có nghĩa là, một nỗ lực để thêm một cái gì đó để
một Leaf có thể chỉ ra một lỗi. Trong trường hợp đó, Add hoạt động sản xuất dữ
liệu hỏng. Bạn có thể làm cho nó xóa đối số của nó, nhưng đó không thể là những
gì Client mong đợi. Thường nó tốt hơn để làm cho Add và Remove không theo
mặc định (có thể bằng nâng cao một ngoại lệ) nếu các thành phần không được

phép có con hoặc nếu đối số của Remove không phải là con của các thành phần
tương ứng. Một lựa chọn khác là thay đổi ý nghĩa của "loại bỏ" một chút. nếu
thành phần duy trì một tài liệu tham khảo cha mẹ, sau đó chúng ta có thể xác định
lại Component :: Remove bỏ để loại bỏ chính nó từ cha của nó. Tuy nhiên, vẫn
còn không phải là một giải thích ý nghĩa cho một Add tương ứng.
5. có nên thực thi Component một danh sách các Component?
Bạn có thể bị cám dỗ để xác định các thiết lập của con như một biến trong lớp
Component nơi hoạt động truy cập và quản lý lớp con được khai báo. Nhưng đặt
con trỏ con trong lớp cơ sở phải gánh chịu một điều khoản không gian cho mỗi
Leaf, mặc dù một Leaf không có con. Điều này là đáng giá nếu có rất ít con trong
cấu trúc.
6. Sắp thứ tự con .
Nhiều thiết kế chỉ định một trật tự trên các con
Composite. Trong ví dụ Graphic trước đó, việc sắp thứ tự có thể phản ánh
trước đến sau việc sắp xếp thứ tự. Nếu Composites đại diện cho cây phân tích cú
pháp, sau đó câu lệnh phức có thể là phiên bản của một Composite cái mà con
phải được lệnh để phản ánh chương trình.
Khi việc sắp xếp là một vấn đề, bạn phải thiết kế truy cập và quản lý giao
diện con một cách cẩn thận để quản lý các trình tự của con. Mô hình Iterator (289)
có thể hướng dẫn bạn trong việc này.
7- Bộ nhớ đệm để cải thiện hiệu suất.
Nếu bạn cần phải truy cập hoặc tìm kiếm composition(sự hợp thành) thường
xuyên, lớp composite có thể truy cập bộ nhớ tạm hoặc tìm kiếm thông tin về con
của nó. Composite có thể lưu lại kết quả thực tế hoặc chỉ thông tin cho phép nó rút
ngắn quá trình truy cập hoặc tìm kiếm.
Ví dụ:
Lớp Picture từ ví dụ Motivation có thể lưu trữ tạm hộp con ranh giới của nó. Trong
bản vẽ hoặc lựa chọn, lưu trữ này cho phép các hình vẽ tránh hoặc tìm kiếm khi
con của nó không hiển thị trong cửa sổ hiện hành.
Thay đổi cho một Component sẽ yêu cầu hủy bỏ hiệu lực các cache của cha mẹ nó.

Điều này làm việc tốt nhất khi các thành phần biết cha mẹ của nó. Vì vậy, nếu bạn
đang sử dụng bộ nhớ đệm, bạn cần phải xác định một giao diện cho Composite cái
mà cache bị vô hiệu.
8. Ai nên xóa các component?
Trong ngôn ngữ mà không thu gom rác thải, đó là thường là tốt nhất để thực hiện
một nhiệm vụ Composite cho việc xóa con của nó khi nó bị tiêu diệt. Một ngoại lệ
cho quy tắc này là khi đối tượng lá Leaf bất biến và do đó có thể đã được chia sẻ.
9. Cấu trúc dữ liệu tốt nhất để lưu trữ các thành phần là gì?
Composite có thể sử dụng một loạt các cấu trúc dữ liệu để lưu trữ con của chúng,
bao gồm danh sách liên kết, cây, mảng, và các bảng. việc lựa chọn cấu trúc dữ liệu
phụ thuộc (như luôn luôn) tính hiệu quả. Trong thực tế, nó không cần thiết để sử
dụng một mục đích chung cấu trúc dữ liệu ở tất cả. Đôi khi Composite có một biến
cho mỗi con, mặc dù điều này đòi hỏi mỗi lớp con của Composite hực hiện giao
diện quản lý của riêng mình. Xem Interpreter (274) cho một ví dụ về điều này .
SAMPLE CODE
Thiết bị như máy tính và các thành phần âm thanh stereo thường được tổ chức như
part-whole (bộ phận- toàn thể) hoặc ngăn chặn hệ thống phân cấp. Ví dụ, một
khung xe có thể chứa ổ đĩa và bảng phẳng, một chiếc xe buýt có thể chứa thẻ, và
một nội các có thể chứa khung gầm, xe buýt, và vv. Cấu trúc như vậy có thể được
mô hình tự nhiên với Composite mô hình.
Lớp Equipment định nghĩa một giao diện cho tất cả các thiết bị trong hệ thống
phân cấp part-whole
class Equipment {
public:
virtual ~Equipment();
const char* Name() { return _name; }
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment*);

virtual void Remove(Equipment*);
virtual Iterator* CreateIterator();
protected:
Equipment(const char*);
private:
const char* _name;
};
Equipment xác lập hoạt động trả lại các thuộc tính của một phần của thiết bị, như
tiêu thụ điện năng và chi phí. Phần tử Lớp con thực hiện các hoạt động cho các
loại cụ thể của Equipment . Equipment cũng xác lập một hoạt động CreateIterator
trả về một Iterator (xem Phụ lục C) để truy cập vào các bộ phận của nó. mặc định
thực hiện hoạt động này trả về một NullIterator, mà lặp lại trên tập rỗng.
Lớp con của Equipment có thể bao gồm các lớp lá đại diện cho ổ đĩa, mạch tích
hợp, và chuyển mạch:
class FloppyDisk : public Equipment {
public:
FloppyDisk(const char*);
virtual ~FloppyDisk();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
};
CompositeEquipment is the base class for equipment that contains other
equipment.
It's also a subclass of Equipment.
class CompositeEquipment : public Equipment {
public:
virtual ~CompositeEquipment();
virtual Watt Power();
virtual Currency NetPrice();

virtual Currency DiscountPrice();
virtual void Add(Equipment*);
virtual void Remove(Equipment*);
virtual Iterator* CreateIterator();
protected:
CompositeEquipment(const char*);
private:
List _equipment;
};
Composite Equipment xác định các hoạt động để truy cập và quản lý
subequipment. Các hoạt động Add và Remove bỏ chèn và xóa thiết bị từ danh
sách các thiết bị lưu trữ trong các thành viên _equipment. Các hoạt động
CreateIterator trả về một Iterator (cụ thể, một thể hiện của ListIterator) sẽ đi qua
danh sách này.
Một thực hiện mặc định của NetPrice có thể sử dụng CreateIterator tổng giá net
của subequipment2:
Currency CompositeEquipment::NetPrice () {
Iterator* i = CreateIterator();
Currency total = 0;
for (i->First(); !i->IsDone(); i->Next()) {
total += i->CurrentItem()->NetPrice();
}
delete i;
return total;
}
Bây giờ chúng ta có thể đại diện cho một khung máy tính như một lớp con của
CompositeEquipment đã được gọi khung. Khung kế thừa các hoạt động liên quan
đến con từ CompositeEquipment
Class Chassis : public CompositeEquipment {
public:

Chassis(const char*);
virtual ~Chassis();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
};
Chúng ta có thể xác định container thiết bị khác như nội các và xe buýt trong một
tương tự cách. Cung cấp cho chúng tôi tất cả mọi thứ chúng ta cần để lắp ráp thiết
bị vào một (khá đơn giản) máy tính cá nhân:
Cabinet* cabinet = new Cabinet("PC Cabinet");
Chassis* chassis = new Chassis("PC Chassis");
cabinet->Add(chassis);
Bus* bus = new Bus("MCA Bus");
bus->Add(new Card("16Mbs Token Ring"));
chassis->Add(bus);
chassis->Add(new FloppyDisk("3.5in Floppy"));
cout << "The net price is " << chassis->NetPrice() << endl;
Known Uses
Ví dụ về mô hình Composite có thể được tìm thấy ở hầu hết các định hướng đối
tượng hệ thống . Nguồn gốc lớp View của Smalltalk Model / View / Controller
[ KP88 ] là một Composite, và gần như tất cả bộ công cụ giao diện người dùng
hoặc khuôn khổ đã theo trong các bước của nó , bao gồm cả ET + + ( với VObjects
của nó [ WGM88 ] ) và InterViews ( Styles[ LCI +92 ] , Graphic [ VL88 ] , và
Glyphs [ CL90 ] ). Thật thú vị để lưu ý nguồn gốc View của Model / View /
Controler đã có một bộ subviews , nói cách khác View là cả lớp Component và lớp
Composite. Phát hành 4.0 của Smalltalk -80 sửa đổi Model / View / Controller với
một lớp VisualComponent lớp này có lớp con View và CompositeView .
RTL Smalltalk [ JML92 ] bộ biên dịch Framework sử dụng mô hình Composite
rộng rãi . RTL Expression là một lớp Component cho phân tích cây. Nó có lớp con
,như BinaryExpression , lớp này có chứa đối tượng con RTLExpression. Các lớp

xác định một cấu trúc Composite cho cây phân tích cú pháp . RegisterTransfer là
lớp Component cho Single Static Assignment (SSA) hình thức của chương trình.
Leaf lớp con của RegisterTransfer xác định các phép gán tĩnh khác nhau như :
-Các phép gán cơ bản mà thực hiện một hoạt động trên hai thanh ghi và gán
kết quả đến một thanh ghi thứ ba ;
-Một phép gán với một thanh ghi nguồn nhưng không có thanh ghi đích,
điều này chỉ ra rằng thanh ghi đã được sử dụng sau khi trả về một đoạn chương
trình và
-Một phép gán với một thanh ghi đích nhưng không có nguồn , điều này chỉ
ra rằng thanh ghi đã được gàn trước khi bắt đầu đoạn chương trình.
Một lớp con khác , RegisterTransferSet , là một lớp Composite đại diện cho phép
gán mà thay đổi một số thanh ghi cùng một lúc.
Một ví dụ khác của mô hình này xảy ra trong lĩnh vực tài chính , nơi một danh mục
đầu tư tập hợp tài sản cá nhân. Bạn có thể hỗ trợ các kết hợp phức tạp của các tài
sản của thực hiện một danh mục đầu tư như là một Composite mà phù hợp với giao
diện của một tài sản cá nhân [ BE93 ] .
Mô hình Command (263) mô tả cách đối tượng Command có thể được sáng tác
và trình tự với một lớp MacroCommand Composite.
CÁC MÔ HÌNH LIÊN QUAN
Thường liên kết thành phần cha mẹ được sử dụng cho một Chain of Responsibility
(251). Decorator (196) thường được sử dụng với Composite. Khi Decorator và
Composite được sử dụng cùng nhau, họ thường sẽ có một lớp cha chung. Vì vậy,
Decorator sẽ phải hỗ trợ giao diện Component với các hoạt động như Add,
Remove, và GetChild. Flyweight (218) cho phép bạn chia sẻ các Component,
nhưng họ có thể không còn tham khảo cha mẹ của họ.
Interater (289) có thể được sử dụng để đi qua Composite.
Visitor (366) chỉ tới 1 hoạt động và hành vi mà nếu không sẽ phân phối trên
Composite và lớp Leaf.
Thật dễ dàng để quên để xóa các Iterator khi bạn đang thực hiện với nó. Iterator
mô hình cho thấy cách bảo vệ chống lại lỗi như vậy trên trang 299.

B- XÂY DỰNG TEMPLATE CHO STACK
1 -TÌM HIỂU VỀ STACK
Stack làm việc theo cơ chế last in firt out , phần tử vào đầu tiên sẽ được sắp xếp
xuống đáy của stack , phần tử vào cuối cùng thì gọi là đỉnh của stack .
Các phương thức làm việc với stack :
-phương thức push đẩy phần tử vào trong stack
-phương thức pop lấy ra một phần tử , khi lấy ra thì phần tử đỉnh sẽ được lấy
ra đầu tiên.
-TÁC VỤ KHỞI TẠO MỘT STACK VỚI MAXSIZE PHẦN Tử
-KIỂM TRA STACK TRỐNG
-KIỂM TRA STACK ĐẦY
-thêm một phần tử vào stack
Lấy phần tử ra (lấy ra từ đỉnh stack)
-CÀI ĐẶT MÔ HÌNH CẤU TRÚC VÀ TÁC VỤ TRÊN
STACK
-
-
2 TÌM HIỂU VỀ TEMPLATE
-Ta chỉ cần viết định nghĩa khuôn hình lớp một lần rồi dùng chung cho tất cả các
kiểu dữ liệu khác nhau để được các lớp thể hiện khác nhau
-Khai báo một khuôn hình lớp
template <class T> class Stack {…}
3- BÀI LÀM THựC TẾ
-xây dựng template cho stack
FILE STACK.H
#ifndef STACK_H_INCLUDED
#define STACK_H_INCLUDED
#include<iostream.h>
using namespace std;
template <class T> class Stack

{
private:

int size;
int top;
T *s_ptr;
public :

Stack(int);

void push(T val);
T pop();
bool IsFull();
bool IsEmty();

};
template <class T>
Stack<T>:: Stack(int maxsize){
size=maxsize;
top=-1;
s_ptr=new T(size);
}
template<class T>
void Stack<T>:: push(T val){
if(!IsFull()){
s_ptr[++top]=val;
}
else
{
cout<<"stack dang day ";

}

}
template<class T>
T Stack<T>:: pop(){
if(!IsEmty()){
return s_ptr[top ];
}
else
{
cout<<"stack rong";
}

}

template <class T>
bool Stack<T>::IsFull(){

return top==size-1;
}
template <class T>
bool Stack<T>::IsEmty() {

return top==-1;
}
#endif
-các biến sử dụng
Size : xác định kích thước của stack
Top :đỉnh của stack
Các hàm :

Push : đẩy một phần tử vào stack
Pop: lấy phần tử ra
Isfull: in ra khi stack đầy
IsEmty :in ra khi stack trống
-FILE MAIN.CPP
#include<iostream.h>
#include<conio.h>
#include"Stack.h"
using namespace std;
int main (){
Stack<int> s(5);
s.push(1);
s.push(2);
s.push(3);
s.push(4);
s.push(5);

for(int i=0 ; i<5; i++){

cout<< s.pop()<< endl;

} return 0;
getche();


KẾT QUẢ CHưƠNG TRÌNH
Khi thay đổi giá trị của biến i
for(int i=0 ; i<6; i++){

cout<< s.pop()<< endl;

} return 0;
Sau khi in ra hết số phần tử trong stack thì sẽ có câu lệnh stack rỗng và không trả
về giá trị nữa
-khi số phần tử đã được nạp đầy vào stack mà ta cố tình nạp thêm thì hàm isfull sẽ
chạy và ra thông báo stack đầy