Design Bí kíp – Hồi 1

Coding is the lowest level

Hồi 1

Code thiếu design, tương lai đầy bug

Không học thiết kế, mãi phận cuder

Nhớ ngày mới ra trường, đầu quân cho một tập đoàn lớn của Nhật, lòng đầy nhiệt huyết, ý chí sục sôi muốn noi gương Bill Gates, Steve Jobs lập chí làm việc lớn lao, đổi thay thế giới. Tại hạ chẳng ngại khó khăn, sáng luyện Java, đêm cày .NET, nghiên cứu công nghệ Big Data, IoT, Cloud, mong muốn tu luyện thành tài để đóng góp cho tổ chức, làm rạng danh tổ tông.

Thời gian như bóng câu ngoài cửa sổ, thấm thoát cũng đã 10 năm, giờ đây Java, .NET đã thuộc lòng, từ cấu trúc dữ liệu như Stack, Queue, Linked List, cây nhị phân đến thuật toán Sorting, Tracking, đệ quy cái gì cũng thạo. Những tưởng hiểu biết đến thế thì sẽ được sếp ưu ái tăng lương, nâng level, ngờ đâu mấy năm trôi qua, làm bao dự án mà vẫn mãi thân phận chú coder, lương lậu cũng chỉ đủ tiền mua sữa cho con.

Trong lòng cảm thấy bế tắc, tới bữa quên ăn, nửa đêm vỗ gối. Nhiều đêm OT gục đầu bên bàn phím, nhìn bug report mà đầu choáng mắt hoa, xem code review mà người run lẩy bẩy.

Trong cơn mê sảng, bỗng thấy trời đất tối đen, trong đám khói sương mờ ảo, một người mình mặc áo pull, tay cầm iPad, lưng đeo MacBook hiện ra mỉm cười, thì ra là Steve Jobs tiên sinh hiển thánh:

“Ta thấy ngươi cũng có căn cơ của người làm kĩ thuật, chẳng quản khó khăn mà học hành rèn luyện, nhưng đường lối sai lầm, tối ngày chỉ biết chăm lo học code. Có biết rằng trong phát triển phần mềm, coding chỉ là level thấp nhất, trước code còn có Phân tích requirement, Thiết kế kiến trúc, nghiên cứu giải pháp.  Đấy mới là đỉnh cao của công nghệ.”

Nay ta truyền cho người cuốn “Design Bí lục”, hãy chuyên tâm rèn luyện, tất sẽ thành tài. Sau đó hãy tìm đến FSOFT gặp sư đệ của ta là Hoàng Lão Tà, ngươi nhất định sẽ được trọng dụng, lập nên chiến công hiển hách, lưu danh thanh sử.

Còn nếu không tu chí rèn luyện, thì suốt đời làm phận cuder, code bug cả rổ, bị PM mắng nhiếc, khách hàng chửi rủa, lúc đấy thì chớ trách ta không báo trước.

Nói xong, người cười lớn rồi thăng thiên, tại hạ giật mình tỉnh dậy, hóa ra là một giấc mơ, nhưng thấy bên lap top là một chiếc iPhone 7 mới cứng, trên màn hình vẫn còn sáng dòng chữ “Design Bí lục”.

Những lời của Steve Jobs khiến tại hạ như vén mấy mù thấy trời xanh, liền dành 7,7 49 ngày bế quan nghiền ngẫm bí kíp. Quả thật đúng là lời vàng, ý ngọc, như ánh dương chiếu sáng đêm đen.

Cuốn bí kíp này thật sự rất dài, không bút nào tả xiết, nên bài viết này chỉ share được mấy tầng cơ bản của bí kíp:

• Tầng ngọc thanh là UML diễn nghĩa chủ yếu là diễn tả kiến thức cơ bản về UML, người nào học được tầng này thì có thể đọc thiết kế, hiểu diagram như lòng bàn tay

• Tầng thượng thanh là Design Pattern, mô tả các mẫu hình thiết kế chuẩn xác đã được anh hùng trong thiên hạ trải qua bao đổ máu mà tích lũy thành, người nào nắm được tầng này đã có thể đột phát lên level kĩ sư phần mềm

• Tầng thái thanh là System Design, trình bày về phương pháp thiết kế hệ thống lớn, module, interface data, học thuyết phát triển product. Người nào học hết tầng này có thể trở thành kiến trúc sư trưởng phần mềm, kiến thức phần mềm đã đạt tới võ lâm chí tôn, hiệu lệnh anh hùng coding trong thiên hạ.

UML diễn nghĩa

Có rất nhiều trường phái lập trình, từ lập trình theo block như C, Pascal cho tới hướng đối tượng, hướng sự kiện. Rồi gần nhất là Kiến trúc Hướng-Dịch vụ (Service-Oriented Architecture – SOA) cho phép các lập trình viên không chuyên tạo ra và tái sử dụng các tài sản công nghệ thông tin mà không cần thông thạo các kỹ năng CNTT. Tuy nhiên hướng đối tượng là trường phái lập trình phổ biến nhất, được sử dụng nhiều nhất trong các sản phầm. Ngay cả Steve Jobs là người chọn trường phái này để phát triển những sản phẩm của mình.

UML là công cụ tốt nhất được sử dụng trong thiết kế phần mềm hướng đối tượng, là công cụ không thể thiếu của 1 kĩ sư phần mềm, chẳng khác gì pháp bảo Phệ Hồn của Trương Tiểu Phàm trong tru tiên truyện.

Nhờ UML, kĩ sư mới có thể tạo ra được những bản thiết kế kiến trúc phần mềm chuẩn xác.

UML (Unified Modeling Language) là ngôn ngữ dành cho việc đặc tả, hình dung, xây dựng và làm tài liệu của các hệ thống phần mềm, tât cả các đối tượng đều được mô hình hóa bằng UML.

Design bí kíp cũng có một vài mô hình UML đơn giản, nhưng tại hạ mới đầu khi đọc thì chẳng khác gì đàn gảy tai trâu, vịt xiêm nghe sấm, hoàn toàn không hiểu những đồ hình trong sơ đồ (Phải chăng là bí kíp võ công nào đó??).

1. Kế thừa (Generalization)

Tính kế thừa cho phép chúng ta định nghĩa một lớp trong điều kiện một lớp khác, mà làm cho nó dễ dàng hơn để tạo và duy trì một ứng dụng. Điều này cũng cung cấp một cơ hội để tái sử dụng tính năng code và thời gian thực thi nhanh hơn (Dùng mũi tên nét liền).

Chẳng hạn Circle, Square, Rectangle đều là hình dạng, nên chúng kế thừa một lớp base là Shape, nhưng vậy có thể tái sử dụng những thuộc tính, phương thức của lớp Shape mà không cần phải khai báo lại.

Mô hình trên nếu code thì sẽ code như sau:

import Shape;

public class Circle extends Shape { // . . . }

public class Square extends Square {//..}

Thông thường lớp Shape sẽ được khai báo dạng abstract

public abstract class Shape {//…}

Trên phần mềm thiết kế astash set thuộc tính abstract là true.

Class Shape trên hình sẽ được chuyển thành chữ nghiêng và sẽ hiểu class đó là abstract.

2. Hiện thực hóa (REALIZATION)

Được áp dụng cho interface, như ví dụ dưới:

Trong 1 số sơ đồ interface được kí hiệu bằng dấu tròn cũng có ý nghĩa tương tự:

Quan hệ này được biểu thị bằng mũi tên nét đứt.

Đối tượng Woman, Car, Dog đều có thực hiện 1 phương thức chạy, nhưng mỗi đối tượng lại chạy theo cách khác nhau. Woman kiểu như Lý Mạc Sầu chạy theo kiểu khinh công bay lượn như chim, Car thì chạy bằng bốn bánh, Chó chạy bằng bốn chân.

Mô hình trên nếu code thì sẽ code như sau:

public class Woman implements Run { // . . . }

public class Car implements Run {//..}

Loại interface trên có thể võ lâm đồng đạo nhiều người đã biết, tuy nhiên trong bí kíp này còn có loại interface khá kì bí gọi là provided interface, và required interface.

Đồ hình này tương đối khó hiểu, hư hư thực thực, nhưng có thể hiểu ngắn gọn như sau:

Ứng dụng Mobile Application yêu cầu sử dụng những API của bộ thư viện Android (Required interface).

Java SDK chuẩn cung cấp những API để phát triển bộ thư viện Android (Provided interface).

Android không đơn giản là 1 interface đơn lẻ, nó là tập hợp nhiều interface, class tập hợp lại.

Loại interface kiểu này thường được sử dụng trong component diagram chứ không phải class diagram như thông thường.

Nếu đảo nhãn lướt qua thì thấy abstract và interface giống nhau. vậy khi nào dùng abstract class khi nào dùng interface??

Câu hỏi này cũng đủ làm cho coder đầu óc rối loạn, kinh mạch đảo lộn vì khó hiểu.

Nếu nhìn vào ví dụ trên thì thấy Circle, Square, Rectangle đều cùng một bản chất (là hình dạng) nên trường hợp này sẽ dùng kế thừa.

Nhưng Woman, Car, Dog hoàn toàn khác bản chất (Woman là người, Car là vật thể, Dog là động vật) nhưng lại di chuyển được theo cách khác nhau à dùng interface.

Phần trên chỉ là một phần nhỏ trong Design Bí kíp mà Steve Job để lại, những đồ hình tiếp theo lại càng thêm kì quái.

Muốn biết các đồ hình trên ý nghĩa thế nào, coding ra sau xem hồi sau sẽ rõ.