+12

Nguyên Lý SOLID: Bí Quyết Viết Code Hiệu Quả Trong React và React Native

Khám phá nguyên lý SOLID - quy tắc thiết kế phần mềm giúp cải thiện khả năng bảo trì và mở rộng ứng dụng của bạn. Học cách áp dụng SOLID trong React và React Native để tạo ra code sạch, dễ hiểu và linh hoạt. Bài viết này cung cấp cái nhìn sâu sắc về cách thực hiện nguyên lý SOLID thông qua ví dụ thực tế, giúp bạn chuẩn bị tốt nhất cho các cuộc phỏng vấn lập trình sắp tới.

1. Nguyên Lý SOLID: Bí Quyết Viết Code Hiệu Quả Trong React và React Native

Khi bắt tay vào việc phát triển ứng dụng, bất kỳ ai trong chúng ta cũng mong muốn tạo ra sản phẩm không chỉ mạnh mẽ về mặt chức năng mà còn dễ dàng bảo trì và mở rộng. Đó chính là lý do vì sao nguyên lý SOLID lại trở thành kim chỉ nam cho các developer, nhất là trong lĩnh vực phát triển ứng dụng với React và React Native.

Giới Thiệu Nguyên Lý SOLID

Nguyên lý SOLID, bộ quy tắc thiết kế phần mềm, gồm 5 nguyên tắc cơ bản giúp code của bạn trở nên linh hoạt, dễ hiểu và dễ bảo trì. Đối với các developer sử dụng React hoặc React Native, việc áp dụng SOLID không chỉ giúp tối ưu hóa quá trình phát triển mà còn là chìa khóa để vượt qua những bài test phỏng vấn khó nhằn. 🚀

2. Nguyên Lý Trách Nhiệm Đơn Nhất (SRP)

Định Nghĩa và Mục Đích

Nguyên lý Trách Nhiệm Đơn Nhất (SRP) đề cập đến việc mỗi class hay component chỉ nên giữ một trách nhiệm duy nhất. Nói cách khác, mỗi phần của code bạn viết ra nên tập trung giải quyết một vấn đề cụ thể, giúp việc quản lý và bảo trì trở nên dễ dàng hơn.

Áp Dụng SRP Trong React/React Native

Để minh họa cho SRP, ta có thể xem xét ví dụ sau đây với một component trong React Native:

import React, { useState, useEffect } from 'react';
import { View, Text, Image } from 'react-native';
import axios from 'axios';

const FetchAndDisplayList = () => {
  const [items, setItems] = useState([]);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    axios.get('https://example.com/api/items')
      .then(response => {
        setItems(response.data);
      })
      .catch(error => console.error(error))
      .finally(() => setIsLoading(false));
  }, []);

  if (isLoading) return <Text>Đang tải...</Text>;

  return (
    <View>
      {items.map(item => (
        <View key={item.id}>
          <Image source={{ uri: item.image }} style={{ width: 100, height: 100 }} />
          <Text>{item.name}</Text>
        </View>
      ))}
    </View>
  );
};

export default FetchAndDisplayList;

Trong ví dụ trên, component FetchAndDisplayList vừa đảm nhận việc lấy dữ liệu từ API vừa hiển thị chúng. Theo nguyên lý SRP, chúng ta nên tách phần lấy dữ liệu ra một hook riêng:

import React, { useState, useEffect } from 'react';
import axios from 'axios';

const useFetchItems = () => {
  const [items, setItems] = useState([]);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    axios.get('https://example.com/api/items')
      .then(response => setItems(response.data))
      .catch(error => console.error(error))
      .finally(() => setIsLoading(false));
  }, []);

  return { items, isLoading };
};

Sau đó, component FetchAndDisplayList chỉ cần sử dụng hook useFetchItems để lấy dữ liệu, qua đó giảm bớt trách nhiệm của mình:

import React from 'react';
import { View, Text, Image } from 'react-native';
import { useFetchItems } from './useFetchItems';

const DisplayList = () => {
  const { items, isLoading } = useFetchItems();

  if (isLoading) return <Text>Đang tải...</Text>;

  return (
    <View>
      {items.map(item => (
        <View key={item.id}>
          <Image source={{ uri: item.image }} style={{ width: 100, height: 100 }} />
          <Text>{item.name}</Text>
        </View>
      ))}
    </View>
  );
};

export default DisplayList;

Như vậy, ta đã áp dụng nguyên lý SRP bằng cách phân chia trách nhiệm giữa việc lấy dữ liệu và hiển thị dữ liệu, giúp code trở nên rõ ràng và dễ quản lý hơn.

3. Nguyên Lý Đóng/Mở (OCP)

Nguyên lý Đóng/Mở, hay OCP, là một trong những nguyên tắc cốt lõi trong thiết kế phần mềm, đặc biệt quan trọng đối với những ai đang làm việc với React và React Native. Nguyên lý này nói rằng: "Các đối tượng (class, module, function, v.v.) nên mở cho việc mở rộng nhưng đóng cho việc sửa đổi." Nói một cách đơn giản, bạn nên thiết kế ứng dụng của mình sao cho dễ dàng thêm mới tính năng mà không cần phải sửa đổi code hiện có.

Ví dụ Minh Họa OCP trong React

Xét ví dụ sau đây, chúng ta có một component Button trong React được thiết kế để hiển thị một nút bấm với các chức năng khác nhau dựa trên trạng thái đăng nhập của người dùng:

import React from 'react';

const Button = ({ isAuth, onClick }) => {
  return (
    <button onClick={onClick}>
      {isAuth ? 'Thêm vào giỏ' : 'Hiển thị Modal'}
    </button>
  );
};

Component này dù hoạt động tốt nhưng lại vi phạm nguyên lý OCP vì mỗi khi bạn muốn thêm một hành động mới cho nút bấm dựa trên một điều kiện khác, bạn cần phải sửa đổi component Button này.

Để tuân thủ nguyên lý OCP, chúng ta có thể tái cấu trúc component trên bằng cách sử dụng children prop để truyền vào nội dung mà chúng ta muốn hiển thị:

import React from 'react';

const Button = ({ onClick, children }) => {
  return (
    <button onClick={onClick}>
      {children}
    </button>
  );
};

Bây giờ, bạn có thể dễ dàng mở rộng chức năng của nút bấm mà không cần sửa đổi component Button:

<Button onClick={handleAddToCart}>Thêm vào giỏ</Button>
<Button onClick={showModal}>Hiển thị Modal</Button>

Như vậy, component Button giờ đây tuân thủ nguyên lý OCP, cho phép chúng ta mở rộng chức năng mà không cần sửa đổi code hiện tại.

4. Nguyên Lý Thay Thế Liskov (LSP)

Nguyên lý Thay Thế Liskov, hay LSP, khuyến khích việc các đối tượng trong chương trình có thể được thay thế bằng các instance của subclass của chúng mà không làm thay đổi đúng đắn của chương trình. Điều này nghĩa là một subclass nên hoàn toàn tương thích với superclass của nó.

Ví dụ Minh Họa LSP trong React

Giả sử bạn có một component Button trong React như sau:

const Button = ({ onClick, ...props }) => (
  <button onClick={onClick} {...props}>Click Me</button>
);

Và bạn muốn tạo một PrimaryButton kế thừa từ Button nhưng với style khác biệt:

const PrimaryButton = ({ onClick }) => (
  <Button onClick={onClick} style={{ backgroundColor: 'blue', color: 'white' }}>
    Click Me
  </Button>
);

Trong trường hợp này, PrimaryButton có thể thay thế hoàn toàn Button mà không làm thay đổi logic của ứng dụng. Điều này đảm bảo rằng PrimaryButton tuân thủ nguyên lý LSP, giúp code của bạn trở nên linh hoạt và dễ bảo trì hơn.

Tóm lại, việc áp dụng nguyên lý Thay Thế Liskov trong React giúp đảm bảo rằng các component của bạn có thể được mở rộng và thay thế một cách linh hoạt, tăng cường tính modular và tái sử dụng của code.

5. Nguyên Lý Phân Tách Interface (ISP)

Nguyên lý Phân Tách Interface (ISP) trong thiết kế phần mềm khuyến khích việc tạo các interface chuyên biệt để các component không phải phụ thuộc vào các interface họ không sử dụng. Trong bối cảnh React, điều này có thể được hiểu là việc tạo ra các props chuyên biệt cho mỗi component, sao cho chúng chỉ nhận những props thực sự cần thiết cho mình.

Ví dụ áp dụng ISP trong React

Xét một component UserProfile hiển thị thông tin người dùng:

const UserProfile = ({ user }) => {
  return (
    <div>
      <img src={user.avatar} alt="avatar" />
      <h2>{user.name}</h2>
      <p>{user.bio}</p>
    </div>
  );
};

Component này chỉ cần thông tin về avatar, name, và bio của người dùng. Tuy nhiên, nếu user object chứa nhiều thông tin khác không cần thiết cho component, việc truyền toàn bộ user object làm props sẽ vi phạm nguyên lý ISP.

Cách tốt hơn để tuân thủ ISP là chỉ truyền những thông tin cần thiết:

const UserProfile = ({ avatar, name, bio }) => {
  return (
    <div>
      <img src={avatar} alt="avatar" />
      <h2>{name}</h2>
      <p>{bio}</p>
    </div>
  );
};

Như vậy, component UserProfile giờ đây chỉ phụ thuộc vào những props thực sự cần thiết, giúp giảm sự phức tạp và tăng cường tính độc lập của component.

6. Nguyên Lý Đảo Ngược Phụ Thuộc (DIP)

Nguyên lý Đảo Ngược Phụ Thuộc (DIP) nhấn mạnh rằng các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào abstraction. Trong React, điều này có thể được hiểu là việc sử dụng các interface hoặc các hàm callback để giảm sự phụ thuộc trực tiếp giữa các component.

Ví dụ áp dụng DIP trong React

Giả sử bạn có một form component để tạo mới và chỉnh sửa thông tin người dùng:

const UserForm = ({ onSubmit, initialValues }) => {
  // Logic xử lý form ở đây
  return (
    <form onSubmit={onSubmit}>
      {/* Các input field ở đây */}
    </form>
  );
};

Component này không cần biết logic xử lý form là gì, nó chỉ cần một hàm onSubmit để gọi khi form được submit. Điều này giúp UserForm không phụ thuộc trực tiếp vào logic xử lý cụ thể, mà chỉ phụ thuộc vào một abstraction (onSubmit prop), tuân thủ nguyên lý DIP.

Sử dụng UserForm cho cả thêm mới và chỉnh sửa người dùng:

// Thêm mới người dùng
<UserForm onSubmit={handleCreateUser} initialValues={newUserInitialValues} />

// Chỉnh sửa người dùng
<UserForm onSubmit={handleUpdateUser} initialValues={existingUserValues} />

Mỗi hành động (thêm mới hoặc chỉnh sửa) sẽ cung cấp cho UserForm một hàm onSubmit khác nhau, giúp component này linh hoạt và tái sử dụng được mà không cần quan tâm đến logic cụ thể bên trong các hàm onSubmit.

Như vậy, việc áp dụng DIP trong React giúp tạo ra các component linh hoạt, dễ bảo trì và tái sử dụng, đồng thời giảm sự phụ thuộc chặt chẽ giữa các phần của ứng dụng.


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí