Giaosucan’s blog Chia sẻ kiến thức kĩ thuật theo phong cách bá đạo
Mang danh thợ code lòng sao xứng
Tên gọi Design dạ chẳng yên
Lại nói hồi trước, tại hạ vốn là một anh coder nhờ cơ duyên mà kì ngộ Steve Job tiên sinh, được người truyền cho cuốn “Design Bí lục”. Tại hạ vô cùng mừng rỡ, ngày đêm rèn luyện nghiền ngẫm bí kíp, với mong muốn trở thành 1 software designer, kĩ sư phần mềm thực thụ.
Nào ngờ, tại hạ áp dụng cách học sai lầm của thời sinh viên, có học mà chẳng có hành, chỉ biết tập trung học lý thuyết thuộc làu mà không có thực tế hành tẩu giang hồ. Dẫn tới mấy tháng trôi qua, bí kíp đã đọc làu thông, mà không biết cách áp dụng. Lại thêm làm outsource lâu năm, chủ yếu là coding với UT, khiến kiến thức design có học mà chẳng có đất dụng võ. Kết quả là
Xưa hồi sinh viên cài win dạo
Nay lúc ra trường lại code thuê
Rồi một thời gian trôi qua, hết project này đến project khác, hết OT rồi lại ON, làm việc hùng hục nhưng trình độ ngày càng xuống, con đường nghề nghiệp tương lai tối thui như đêm 30
Hôm đó, dự án deliver nên tại hạ phải ở lại cty ON, đêm đã về khuya, bụng đói mà chỉ có gói mỳ Hảo Hảo cầm hơi, bưng bát mỳ tôm mà chan đầy nước mắt, tại hạ chỉ biết ngửa mặt lên trời kêu lớn
“Xin lỗi em, anh chỉ là thằng…thợ code”
Đúng lúc đó, trên bầu trời phía đông phương, một vì sao sáng rực chiếu sáng đêm đen, bất ngờ sa xuống xứ Nhật Bổn, đất Osaka.
Tại hạ chợ nghĩ “ Nay Nhật Bản môn công nghệ thông tin ngày càng phát triển, là vùng đất ngọa hổ tàng long, sao không lên đường tầm sư học đạo để tìm lối thoát cho bản thân?
Đã thích là phải nhích, tại hạ xin sếp lên đường sang Nhật onsite, rồi sang Mỹ làm việc, học được triết lý Kaizen của Nhật Bản môn, luyện thành phương pháp Sigma của Hoa Kì phái. Kết hợp công pháp của 2 phái, cuối cùng, cũng đã ngộ được những huyền cơ trong design bí kíp, công lực tăng tiến vượt bậc
(Kaizen là một thuật ngữ kinh tế của người Nhật, được ghép bởi từ 改 (“kai”) có nghĩa là thay đổi và từ 善 (“zen”) có nghĩa là tốt hơn, tức là “thay đổi để tốt hơn” hoặc “cải tiến liên tục”. Đây là triết lý cốt lõi của người Nhật để cái tiến quy trình làm việc, nâng cao năng suất
6 Sigma là hệ thống bao gồm các công cụ và chiến lược nhằm nâng cao quá trình hoạt động do hãng Motorola phát triển đầu tiên vào năm 1985. 6 Sigma trở nên phổ biến sau khi Jack Welch áp dụng triệt để nó trong chiến lược kinh doanh của ông tại General Electric năm 1995 và ngày nay phương pháp này được sử dụng rộng rãi trong nhiều lĩnh vực công nghiệp khác nhau) Đây là triết lý được các tập đoàn Mỹ áp dụng )
Cuốn bí kíp đồng thời giải thích về truyền thuyết UML, một ngôn ngữ mô hình gồm các ký hiệu đồ họa mà các phương pháp hướng đối tượng sử dụng để thiết kế các hệ thống thông tin. Do 3 nhà khoa học máy tính phát triển là James Rumbaugh, Grady Booch và Ivar Jacobson. Sau đó được tổ chức ISO chấp nhận và công bố rộng rãi.
15 năm trước, 4 vị nhất đại tông sư của giới công nghệ là Steve Job của Apple, BillGate từ Microsoft, LarryPage thuộc Google và Konosuke Matsushita của Panasonic đã hội ngộ tại Silicon Valley, cùng đem hết tuyệt học của bản thân mà viết lên cuốn bí lục này, mô tả chi tiết về các đồ hình UML, design pattern,… với mong muốn lưu lại cho hậu thế
Tại hạ vốn là fan của Apple nên được Steve Job truyền lại cho cuốn bí lục này, ngộ ra được những đồ hình kì bí mà các vị tổ sư để lại, nay share lại cho võ lâm đồng đạo
Aggregation
Aggregation là mối quan hệ has-a khá phổ biến trong hướng đối tượng, trong đồ hình trên, đối tượng Phệ Huyết Châu và Nhiếp Hồn Bổng là bảo vật của Trương Tiểu Phàm. Tuy nhiên, nếu Trương Tiểu Phàm chết, thì Phệ Huyết Châu và Nhiếp Hồn Bổng vẫn tồn tại
Công pháp đã thuộc, nhưng thi triển ra sao, đối với loại đồ hình này sẽ code như sau
class PheHuyetChau {
void hutMau();
}
final class TruongTieuPham {
private PheHuyetChau chau;
void setHuyetChau(PheHuyetChau chau) {
this. chau = chau;
}
void doCongPhap() {
if (chau!= null)
chau.hutMau();
}
}
Compostion
Đây là 1 dạng quan hệ Aggregation nhưng ở dạng strong type. Ví dụ đồ hình trên, đối tượng Lục Tuyết Kỳ có Chân và Ngực, đó là bộ phận cơ thể của Lục Tuyết Kỳ, nếu Lục Tuyết Kỳ chết, thì Chân, Ngực cũng tự khắc teo tóp mà thành xương khô
Công pháp này được thi triển như sau
final class LucTuyetKy {
private final Chan chan;
LucTuyetKy (Chan specs) {
chan = new Chan (specs);
}
void khinhCong() {
chan.move();
}
}
Nhìn vào code trên, sẽ thấy khi đối tượng Lục Tuyết Kỳ được tạo thì đối tượng Chân mới được khởi tạo. Nó tồn tại life-time với đối tượng parent là Lục Tuyết Kỳ
Association
Association cũng thể hiện quan hệ giữa hai đối tượng, nhưng mỗi đối tượng đểu có life cycle riêng và không có mối quan hệ kiểu owner
Tuy nhiên association là mối quan hệ ẩn chứa rất nhiều huyền cơ, e rằng võ lâm đồng đạo không phải ai cũng hiểu sâu hết được
Trước hết bắt đầu bằng đồ hình đơn giản nhất
Đối tượng TruongTieuPham và TruTienKiem là 2 đối tượng độc lập, và không phải owner. TruTienKiem là của Thanh Vân môn không phải của Trương Tiểu Phàm. Nhưng đối tượng TruongTieuPham đã Thi Triển TruTienKiem, đối tượng này biết có sự tồn tại của TruTienKiem
class TruTienKiem {
};
class TruongTieuPham {
private TruTienKiem kiem;
}
Đối tượng TruTienKiem là một instance member của đối tượng TruongTieuPham. Kí hiệu 1…1 tức là 1 đối tượng TruongTieuPham chỉ có thể thi triển 1 đối tượng TruTienKiem, ngược lại nếu là 1…N tức là có thể thi triển nhiều đối tượng tru tiên kiếm
Khi đó công pháp phải thay đổi cách thi triển như sau
class TruongTieuPham {
private List<TruTienKiem> kiem;
}
Tuy nhiên trong đồ hình này còn có 1 bí pháp gọi là Navigable, đây là 1 công pháp đã thất truyền nên võ lâm ít người nghe đến
Navigable được thể hiện bằng dấu mũi tên
Non navigable được thể hiện bằng dấu x
Unspecifed navigable được thể hiện bằng nét thẳng
Đồ hình ở trên có nghĩa là đối tượng Person làm việc cho đối tượng Company, nhưng không phải Company làm việc cho Person. Đây là quan hệ một chiều, đối tượng Person biết về sự tồn tại của Company (navigable), nhưng Company không biết đối tượng Person (non navigable).
Khi runtime, thông qua instance của đối tượng Person, có thể truy cập được đối instance của Company (Biết được Person đấy làm việc cho Company nào), Nhưng ngược lại thì không thể
Công pháp thi triển
class Person {
private Company company;
}
class Company {
}
Class Person có reference tới company nhưng Company không hề reference tới person
Tương tự , nếu đồ hình với 2 mũi tên như ở dưới
Có thể luận ra công pháp thi triển là
class Person {
private Company company;
}
class Company {
private Person person;
}
Đến phần này, có thể võ lâm đồng đạo sẽ bị tẩu hỏa nhập ma vì mỗi quan hệ phức tạp giữa các đối tượng, chúng khác nhau như thế nào. Rất may, cuốn bí kíp cũng đã giải thích rất rõ ràng
Vậy 3 quan hệ trên khác nhau ở điểm nào ??
Associate giữa hai đối tượng được khởi tạo qua reference properties (class attributes)
Class A có quan hệ Associate với class B tức là 1 class A có member có kiểu class B
class A {
private B b;
};
Class A có quan hệ Aggregation với class B khi class A có method dùng B như parameter
class A {
void doXXX(B b) {};
};
Class A có quan hệ Compostion với class B khi constructor của class A dùng B như parameter
class A {
A (B b){
new B();
}
};
Khi Instance A được khởi tạo thì instance B cũng được khởi tạo, chúng tồn tại và bị hủy đồng thời
Trên đây chỉ là 1 chương mở đầu của bí kíp, ở tầng thấp nhất, thực tế cuốn bí kíp còn lưu rất nhiều công pháp bí truyền trong thiên hạ như Sequence thuật, Design Pattern thần công… Thật sự không bút nào tả xiết
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?