Blog Yoyo 1001

Đặt vấn đề Trong bất cứ hệ thống enterprise nào, việc lấy dữ liệu từ các external resource (file, …) là rất quan trọng. Ví dụ: một hệ thống quản lý với giao diện cây sẽ cần lấy các icon để thể hiện cho các node trên cây. Một chương trình giao diện GUI luôn cần hiển thị các thông báo lỗi cho user. Các nguồn dữ liệu này thường lưu trong file (phổ biến là xml). Do đó, các hệ thống sẽ có các module thực hiện việc lookup các nguồn dữ liệu này. Thông thường các module này nằm rải rác, nếu quy trình thiết kế không tốt, sẽ rất khó quản lý. Do đó, bài viết này hướng dẫn cách xây dựng 1 framework nhỏ, giúp quản lý các module lookup. Framework cho phép developer tạo ra module lookup theo yêu cầu nghiệp vụ và plug vào framework. Sau đó sử dụng framework để invoke các chức năng của module lookup. IoC (Inversion of Control) là một khái niệm nghe có vẻ mới lạ nhưng thực ra nó đã có từ lâu dưới cái tên DIP (Dependency Inversion Principle). Ngoài ra, IoC còn có ...

Mình thì không có khả năng viết rồi, nhưng trình độ copy cũng thượng thừa, nên tập hợp các sơ đồ trên mạng cho bạn hiểu thêm Đề bài: Mình đang làm 1 chương trình quản lý đặt tiệc tại nhà hàng. minh post lên yêu cầu và mô hình use case, các bạn xem có ji góp ý nha. --------------- yêu cầu: Yêu cầu chức năng hệ thống. • Lưu trữ thông tin khách hàng ( khách hàng đến tham khảo, đã đặt tiệc hoặc đang đặt tiệc: họ tên, địa chỉ, ngày nhập, ghi chú ....). • Quản lý thông tin các sảnh của nhà hàng - là nơi đặt tiệc (số chổ ngồi, cách bài trí, sân khấu, vật dụng......). • Quản lý danh mục món ăn (tên món ăn, đơn giá, đơn vị tính, thành phần nguyên liệu – tỉ lệ.). • Quản lý nguyên liệu. • Quản lý các dịch vụ: thuê màn chiếu, thuê TV,... ( tên dịch vụ, đơn giá... ). • Quản lý hợp đồng đặt tiệc ( người đặt tiệc, thời gian tổ chức, time kết thúc, số người tham dự, nơi đặt tiệc, số bàn ăn, số món ăn trên mỗi bàn, thức uống, dịch vụ thêm, số tiền cọc,..)- có cảnh báo đặt trùng giờ, t...

Theo đặc tả UML thì một biểu đồ use case (UC) là “biểu đồ mô tả mối quan hệ giữa các tác nhân (actor) và các use case trong một hệ thống”. Biểu đồ use case thường được sử dụng để: Cung cấp cách nhìn tổng quan về toàn bộ hoặc một phần các yêu cầu chức năng của một hệ thống hoặc một tổ chức dưới dạng một mô hình cô đọng (Constantine and Lockwood 1999; Ambler 2001) hay một mô hình tác nghiệp (Rational Corporation 2002) Trao đổi về phạm vi của một dự án phát triển (cái này theo tôi thấy rất quan trọng, thường người lập trình hay phải làm nhiều hơn những gì đã trao đổi với khách hàng) Mô hình hóa kết quả phân tích các yêu cầu chức năng dưới dạng một mô hình use case hệ thống (Cockburn 2001; Ambler 2001) Một mô hình use case là tổ hợp của một hay nhiều biểu đồ UC và tất cả các tài liệu hỗ trợ như các đặc tả UC và các định nghĩa các tác nhân. Trong hầu hết các mô hình UC thì các đặc tả UC thường là nhân tố cơ bản nhất đóng vai trò hỗ trợ cho tính liên kết giữa các y...

Xem thêm Sự kế thừa và các vấn đề liên quan- Phần 2 Những thành phần nào được thừa kế: Về nguyên tắc, lớp dẫn xuất kế thừa tất cả các member của lớp cơ sở ngoại trừ: Constructor và destructor operator=() Friend functions, friend classes. Cái này mình chưa rõ lắm. Mặc dù hàm tạo (constructor) và hàm hủy(destructor) không được kế thừa nhưng hàm tạo và hàm hủy mặc định luôn được gọi khi tạo hoặc hủy 1 đối tượng lớp dẫn xuất. Nếu lớp cở sở không có hàm tạo mặc định hoặc bạn muốn gọi hàm tạo khi tạo 1 đối tượng ở lớp dẫn xuất, bạn có thể định nghĩa nó ở hàm tạo của lớp dẫn xuất theo cú pháp:

Xem thêm bài Sự kế thừa và các vấn đề liên quan- Phần 1 Trích: • When a base class is inherited by use of public, its public members become public members of the derived class, and its protected members become protected members of the derived class. • When a base class is inherited by use of protected, its public and protected members become protected members of the derived class. • When a base class is inherited by use of private, its public and protected members become private members of the derived class. • In all cases, private members of a base class remain private to the base class, and are not inherited. Ở đây mình xin nêu những điểm ở bên ngoài thôi nhé: (chỉ nói về public và private, protected thì tương tự)

Bạn có thể tham khảo thêm bài Giới thiệu về lập trình hướng đối tượng Ở bài viết này, mình tổng hợp và bổ sung những gì các cuốn sách còn thiếu. Đầu tiên mình sẽ nói 2 khái niệm cực kì quan trọng là kế thừa và hợp thành . Sau đó mình sẽ nói tiếp về phạm vi của sự kế thừa. Sự kế thừa và thiết kế chương trình Ngoài việc làm cho việc thay đổi các chương trình có sẵn dễ dàng hơn, sự kế thừa còn có 1 lợi ích khác. Nó cung cấp một cách để liên kết một thành phần chương trình này với một thành phần chương trình khác. Mối quan hệ mới này làm cho việc thiết kế chương trình linh động hơn và cấu trúc chương trình phản ánh mối quan hệ thế giới thực chính xác hơn. Sự kế hơn đôi khi còn gọi là quan hệ "loại". Để thấy được ý nghĩa này, đầu tiên chúng ta cùng xét một loại quan hệ khác là quan hệ hợp thành.