Object-Oriented Modeling vs Object-Oriented Programming Interview

Nếu code là việc xây nhà, thì OOM chính là bản vẽ kiến trúc. Không ai muốn xây nhà mà không có bản vẽ, đúng không?

Chào các bạn dev,

Hôm nay tôi muốn chia sẻ một câu chuyện vui mà cũng khá "🤦" từ buổi phỏng vấn gần đây của mình.
Đúng vậy, tôi vẫn đi phỏng vấn !!!

"Nhớ đời"

Tuần trước, tôi có buổi phỏng vấn cho vị trí Senior SA tại một công ty khá lớn. Mọi thứ diễn ra suôn sẻ cho đến khi interviewer hỏi "bạn familiar với các concept của Object-Oriented chứ?".

Nghe đến "Object-Oriented", não tôi lập tức nhảy đến các nguyên lý SOLID, inheritance, polymorphism… và tôi chém một hồi về OOP. Vài phút trôi qua, interviewer nhẹ nhàng ngắt lời: "Bạn đang nói về phần code, nhưng về tư duy thiết kế thì sao?"

Awkward silence.

Lúc đó trong đầu tôi chỉ nghĩ:

"Chết mẹ! mình code nhiều quá rồi!" 😅

"À vậy là chúng ta đang nói về OBJECT-ORIENTED MODELING à ?"

Và đó chính là lý do tôi muốn viết bài này - để các bạn không "fail" như tôi, và để phân biệt rõ hai khái niệm thường bị nhầm lẫn này.

Object-Oriented Modeling (OOM) là gì?

OOM không phải là việc viết code, mà là giai đoạn "vẽ bản đồ" trước khi xuống tay code. Đây là khi bạn ngồi với những tờ giấy (hoặc công cụ thiết kế) để vẽ ra cấu trúc hệ thống bằng các đối tượng và mối quan hệ giữa chúng.

Nếu code là việc xây nhà, thì OOM chính là bản vẽ kiến trúc. Không ai muốn xây nhà mà không có bản vẽ, đúng không?

Đặc điểm "nhận dạng" OOM:

OOM thuộc giai đoạn phân tích & thiết kế - trước khi có một dòng code nào
Sản phẩm của OOM là những biểu đồ, mô hình giúp team hiểu rõ hệ thống
OOM thường sử dụng UML (dù nhiều người coi đó là "công cụ tra tấn" 😄)
OOM hoạt động ở mức độ trừu tượng cao - bạn nghĩ về "cái gì" chứ không phải "làm thế nào"

Các biểu đồ "must-know" trong OOM:

1. Biểu đồ lớp (Class Diagrams)

A UML class diagram illustrating the relationship between Customer and Order classes. The Customer class contains attributes for id, name, and email, along with methods for registering and logging in. The Order class includes attributes for orderId, date, and status, with methods for placing and canceling orders. A one-to-many relationship is indicated, showing that one Customer can place multiple Orders.

Biểu đồ này giúp bạn thấy được các entities trong hệ thống và cách chúng liên kết với nhau. Nó là blueprint để sau này code.

2. Biểu đồ use case (Use Case Diagrams)

A use case diagram for an E-Commerce System featuring a Customer actor. The diagram includes use cases for Register, Login, and Checkout, with Checkout including Login as a prerequisite.

Biểu đồ này giúp bạn hiểu người dùng sẽ tương tác với hệ thống như thế nào.

3. Biểu đồ trình tự (Sequence Diagrams)

A sequence diagram illustrating the process of placing an order. It shows a Customer interacting with a Web Interface (UI), which communicates with an Order System (OS) to create an order and save it to a Database (DB). The OS then sends an order confirmation back to the UI, which displays the confirmation to the Customer.

Đây là bản đồ "thời gian" cho thấy các đối tượng tương tác với nhau theo trình tự nào.

Object-Oriented Programming (OOP) là gì?

Đây mới là phần mà hầu hết dev chúng ta quen thuộc. OOP là phương pháp lập trình sử dụng các đối tượng để tổ chức code, mỗi đối tượng chứa data và các hàm để thao tác với data đó.

Đặc điểm của OOP:

OOP thuộc giai đoạn triển khai - khi bạn đã sẵn sàng viết code
Tập trung vào việc code các class để thực hiện các chức năng hệ thống
Chi tiết đến mức triển khai thực tế - làm thế nào để các đối tượng hoạt động
Sử dụng các ngôn ngữ OOP như Java, C++, Python…

4 Trụ cột của OOP (mà chắc bạn đã thuộc nằm lòng):

1. Tính đóng gói (Encapsulation)

Class diagram of a BankAccount showing its attributes and methods. The BankAccount class has private attributes for accountNumber and balance, and public methods for deposit, withdraw, and getBalance.

Đóng gói giống như việc bạn không cho người khác sờ vào tiền trong ví của mình - họ phải thông qua các "phương thức" như "cho tôi mượn tiền" hoặc "trả tôi tiền" 😄

2. Tính kế thừa (Inheritance)

A UML class diagram showing the hierarchy between classes. The 'Vehicle' class, with public methods 'start()' and 'stop()', is a superclass. The 'Car' class extends 'Vehicle' and adds an additional public method 'openTrunk()'.

Kế thừa là khi bạn có một chiếc xe ô tô mà không cần phải phát minh lại bánh xe.

3. Tính đa hình (Polymorphism)

UML diagram displaying an interface named 'Shape' with a method 'calculateArea'. It shows two classes, 'Circle' and 'Rectangle', both implementing the 'Shape' interface and providing their own 'calculateArea' method.

Đa hình là khi bạn nói "tính diện tích" và mỗi hình sẽ tự biết cách tính diện tích của riêng mình.

4. Tính trừu tượng (Abstraction)

A UML diagram depicting an abstract class named 'Database' with two public methods: 'connect' which returns void, and 'executeQuery' that takes a String as an argument and returns a Result.

Trừu tượng là khi bạn lái xe mà không cần biết động cơ hoạt động như thế nào.

Mối quan hệ giữa OOM và OOP

Sau thảm họa phỏng vấn đó, tôi quyết định đào sâu hơn vào mối quan hệ giữa OOM và OOP. Hóa ra, chúng giống như cặp sinh đôi công nghệ vậy:

OOM là "bản thiết kế", còn OOP là "công trình xây dựng". Nhìn vào quy trình làm phần mềm, OOM thường diễn ra trước OOP. Bạn phải vẽ bản đồ trước khi lên đường, đúng không?

Cái thú vị là ngay trong quá trình code OOP, dev cũng buộc phải làm OOM (dù có thể chỉ trong đầu). Bạn có bao giờ "thao tác" vài phút trước khi bắt đầu code không? Đó chính là OOM đấy! Bạn đang hình dung class nào sẽ có property gì, tương tác thế nào với class khác… mà không nhận ra mình đang làm công việc của một system analyst.

Một lần nọ, lead của tôi đến gần và hỏi: "Em đang làm gì mà ngồi nghĩ lâu vậy?" - tôi trả lời: "Em đang thiết kế class diagram trong đầu ạ" - và anh ấy nói "Vậy thì vẽ ra đi, đừng chỉ giữ nó trong đầu". Đó là một trong những lời khuyên tốt nhất mà tôi từng nhận được.

Những điểm tương đồng giữa OOM và OOP (mà ít ai để ý)

Nếu OOM và OOP có họ hàng với nhau thì chắc chắn chúng là anh em:

Chung một DNA hướng đối tượng

Cả hai đều dựa trên tư duy "hướng đối tượng". Các khái niệm class, object, property, method đều xuất hiện trong cả OOM và OOP. Ví dụ trong OOM tôi vẽ một class User có thuộc tính email và phương thức login(), thì trong OOP tôi cũng có một class với cấu trúc tương tự.

Đôi khi tôi tự hỏi: UML và Java có phải là hai ngôn ngữ khác nhau để diễn tả cùng một thứ?

Mục tiêu chung: mô phỏng thế giới thực

Có một lần tôi phỏng vấn một ứng viên và hỏi: "Object-Oriented là gì?". Câu trả lời hay nhất mà tôi từng nghe là: "Nó là cách làm phần mềm gần giống với thế giới thực".

Đúng vậy, cả OOM và OOP đều cố gắng thu hẹp khoảng cách giữa phần mềm và thế giới thật. Trong thế giới thực có học sinh, trường học, môn học - thì trong phần mềm cũng có các class tương ứng.

Tính mô-đun và khả năng bảo trì

Thiết kế OOM tốt sẽ dẫn đến code OOP tốt - cả hai đều hướng đến việc chia nhỏ hệ thống thành các thành phần dễ quản lý.

Một dev từng nói với tôi: "Anh viết code thế nào mà không bao giờ có bug?" (quá khen). Câu trả lời của tôi là: "Vì tôi dành gấp đôi thời gian cho thiết kế so với coding".

OOM vs OOP: Phân biệt nhanh gọn

Tiêu chí	OOM	OOP
Là gì	"Bản vẽ" của hệ thống	"Việc xây dựng" hệ thống
Khi nào	Trước khi code	Trong quá trình code
Sản phẩm	Biểu đồ, mô hình, tài liệu	Code, chương trình chạy được
Ai làm	Architect, System Analyst	Developer
Công cụ	Visual Paradigm, StarUML, Lucidchart...	IDE, ngôn ngữ lập trình...

Những khác biệt sâu sắc hơn mà tôi đã "học được" sau buổi phỏng vấn

Sau khi trở về từ buổi phỏng vấn đó, tôi đã ngồi research kỹ hơn và nhận ra rằng sự khác biệt giữa OOM và OOP còn sâu sắc hơn tôi nghĩ:

Mức độ trừu tượng vs Cụ thể

OOM là tư duy ở tầng trừu tượng - bạn đang vẽ ra bức tranh tổng thể, không lo về implementation details. Giống như kiến trúc sư vẽ bản thiết kế ngôi nhà mà không cần quan tâm đến việc mua gạch loại nào, xi măng hiệu gì.

OOP ngược lại, là tư duy cụ thể - bạn phải quyết định dùng ArrayList hay LinkedList, dùng Factory Pattern hay Builder Pattern. Đây là lúc bạn phải "get your hands dirty" với những chi tiết mà OOM không đề cập đến.

Ngôn ngữ biểu đạt khác nhau hoàn toàn

Sau buổi phỏng vấn, tôi đã thử làm một thử nghiệm: đưa cho một bạn dev và một bạn BA cùng một bản thiết kế UML, rồi hỏi họ hiểu gì. Kết quả là BA hiểu tổng quan hệ thống nhưng không biết implement thế nào, còn dev biết implement nhưng lại bỏ sót nhiều ý đồ thiết kế!

Mục đích khác biệt

Điểm này mới chính là "aha moment" của tôi sau buổi phỏng vấn: OOM là để giao tiếp, còn OOP là để thực thi.

OOM giúp bạn nói chuyện với stakeholders, team members và cả chính bản thân bạn để hiểu hệ thống đang được xây dựng. Còn OOP là để nói chuyện với máy tính, bảo nó thực hiện những gì bạn muốn.

Tôi nhớ có lần làm việc với một khách hàng non-tech, chỉ cần vẽ một use case diagram đơn giản, họ đã hiểu và approve feature. Nhưng thử đưa họ xem code Java thì… "thôi bỏ đi" 🙂

Tại sao phải quan tâm đến cả hai?

Đây là điểm mà tôi đã miss trong buổi phỏng vấn. Một Senior SA cần hiểu rõ cả hai thứ này vì:

Cầu nối giao tiếp: OOM giúp các stakeholders không biết code vẫn hiểu được hệ thống
Tiết kiệm chi phí: Sửa lỗi ở giai đoạn thiết kế rẻ hơn 10-100 lần so với giai đoạn code
Code chất lượng hơn: OOP dựa trên OOM tốt tạo ra code cấu trúc rõ ràng, dễ bảo trì

Think about it - bạn sẽ tin tưởng một dev nào hơn: người cầm bản vẽ chi tiết rồi code, hay người nhào vào code luôn vì "trong đầu đã có hết rồi"?

Quy trình: Từ ý tưởng đến sản phẩm

A diagram illustrating the software development process from idea to product, featuring the following steps: 1. Requirements Gathering, 2. Modeling (OOM), 3. Analysis (OOA), 4. Design (OOD), 5. Coding (OOP), and 6. Testing & Deployment, with arrows connecting each step.

Các dự án thành công thường đi theo quy trình này, mặc dù mức độ formal của từng bước có thể khác nhau tùy vào dự án.

Công cụ tôi hay dùng

Sau buổi phỏng vấn đó, tôi đã "cày" lại các công cụ để cập nhật kiến thức:

PlantUML: Cực kỳ tiện vì có thể version control cùng code
Draw.io: Miễn phí và dễ dùng, ai cũng biết dùng.
LucidChart: UX tốt nhưng hơi tốn kém
D2Lang: Công cụ mới, đơn giản, đẹp - customize dễ hơn nhưng mất tiền
Mermaid: Đẹp, đơn giản, dùng trực tiếp trong markdown.

Bài học rút ra

Qua hôm nay, tôi rút ra một điều: dù bạn là dev hay SA, hiểu được cả OOM và OOP là điều bắt buộc nếu muốn làm việc hiệu quả trong các dự án lớn.

Và với các bạn sinh viên đang đọc bài này: hãy coi trọng những môn học về phân tích thiết kế hệ thống. Ban đầu có thể thấy khô khan, nhưng tin tôi đi, khi đi làm bạn sẽ thấy nó quan trọng không kém gì việc "gõ code" đâu!

Chúc các bạn hướng đối tượng vui vẻ.