### 1. Decorator là gì và nó hoạt động ra sao?

Decorator là một pattern trong đó một hàm (class) sẽ nhận input là một hàm (class) và trả ra output là một hàm (class). Hàm được trả ra sẽ có hành vi khác so với hàm input, có thể được extends,...

OK, mình sẽ lấy ví dụ trực quan hơn

Giả sử mình có hàm tính tổng như sau:
```python
def add(*args):
	return sum(args)
```

Bây giờ, mình có thêm yêu cầu là log thời gian thực thi hàm đó chẳng hạn, cách dễ nhất là thêm code vào chính hàm đó như sau:

```python
def add(*args):
	start_at = time.time()
	s = sum(*args)
	print("Take", time.time()-s, "second")
	return s
```

Bây giờ, mình có thêm mấy hàm và cũng được yêu cầu log thời gian thực thi. Sau 2 tháng, các sếp yêu cầu mình ngoài log thời gian thực thi, cần log thêm tên hàm và input chẳng hạn, mình sẽ phải sử code ở toàn bộ các hàm đó, thật tệ :sad:

Đây là lúc chúng ta cần đến decorator

```python
def log(func):
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print("Take", time.time()-start_at, "second")
		return ret
	return func_with_log
```

Sử dụng nó nào

```python
def add(*args):
	return sum(args)

add_with_log = log(add)
```

Hàm `log` đơn giản nhận vào một hàm, thực thi hàm đó (pass nguyên bộ tham số) và in thời gian thực thi (extend hàm gốc). Bạn có thể sử dụng hàm `log` này ở đâu bạn muốn và có thể dễ dàng thêm các yêu cầu mà không tốn công :smile:

Ngoài cách gọi rõ ràng như thế kia, Python còn hỗ trợ syntax cho decorator như này

```python
@log
def add(*args):
	return sum(args)
```

Amazing!

### 2. Nested decorator

Chúng ta sẽ thắc mắc, một hàm có thể có nhiều decorator hay không, câu trả lời là có

Chúng được gọi là `decorator stack` (các bạn tự tìm hiểu thêm nhé :smile:)

Hay cũng xét ví dụ sau

```python
def decorator1(func):
	def new_func(*args, **kwargs):
		print('Decorator 1')
		return func(*args, **kwargs)
	return new_func

def decorator2(func):
	def new_func(*args, **kwargs):
		print('Decorator 2')
		return func(*args, **kwargs)
	return new_func

@decorator1
@decorator2
def func(msg):
	print('Original func:', msg)

func("Hello world")
```

Output sẽ là:
```
Decorator 1
Decorator 2
Original func: Hello world
```

Oh, vậy chúng có thứ tự thực hiện như thế nào?

Các decorator lồng nhau theo thứ tự decorator1 -> decorator2.

Còn thứ tự thực thi sẽ tuỳ vào việc bạn gọi `func` trong các decorator ra sao.

Đây chính xác là những gì syntax `@` là với các decorator
```python
def func(msg):
	print("Original func:", msg)

func_with_deco2 = decorator2(func)
func_with_deco1 = decorator1(func)
```

### 3. Decorator có tham số

Vẫn là ví dụ về log ở phần 1, chúng ta giờ muốn thêm log tên hàm và input của hàm đó. Nhưng log input của hàm là một tuỳ chọn có thể log hoặc không log

Giải pháp 1: viết 2 decorator

```python
def log_with_input(func):
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print(func.__name__, "takes", time.time()-start_at, "second")
		print("Input:", args, kwargs)
		return ret
	return func_with_log
```

```python
def log_without_input(func):
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print(func.__name__, "takes", time.time()-start_at, "second")
		return ret
	return func_with_log
```

Giờ đâu cần log input thì dùng `log_with_input`, nếu không thì xài `log_without_input`.
Nếu bạn có n biến là tuỳ chọn thì bạn tiêu rồi, bạn cần viết 2 ^ n cái decorator

OK, mình có giải pháp cho bạn đây: decorator của decorator.

```python
def log(show_input=False):
	def config(func):
		def func_with_log(*args, **kwargs):
			start_at = time.time()
			ret = func(*args, **kwargs)
			print(func.__name__, "takes", time.time()-start_at, "second")
			if show_input:
				print("Input:", args, kwargs)
			return ret
		return func_with_log
	return config
```

và đơn giản chỉ cần sử dụng như
```python
@log(show_input=True)
def need_log_input():
	...

@log(show_input=False)
def dont_need_log_input():
	...
```

OK, mình sẽ giải thích thằng Python nó làm ngầm chuyện này như thế nào nhé :smile:

```python
log_deco = log(show_input=True)		# cái này trả về hàm decorator đã được config: show_input=True
need_log_input = log_deco(need_log_input)
```

Bạn có thể thấy, hàm `config` nhận hàm ban đầu và trả ra một hàm mới là `func_with_log` có chứa đoạn code log thông tin, và thực thi hàm gốc.

Và hàm `func_with_log` dựa vào biến `show_input` để quyết định xem có nên log ra input của hàm gốc hay không?

Đây là một lợi ích đến từ `nested function`. Việc define các hàm lồng nhau sẽ cho chúng ta lợi ích `variable scope`. Tức là sau khi hàm `config` trả về `func_with_log`, biến `show_input` vẫn tồn tại trong hàm `func_with_config` mà không bị giải phóng :smile:, lí do tại sao mình sẽ giải thích trong bài viết sau nhé.

OK, các bạn có thể hiểu rõ cơ chế làm việc của decorator rồi, nhưng Python có hẳn syntax cho pattern này

Nhanh gọn phải không nào :smile:

Các bạn có thể thấy pattern này được sử dụng trong rất nhiều các framework như Flask chẳng hạn

```python
app = Flask(__name__)

@app.route("/")
def homepage():
	return "Hello world"
```

Nếu các bạn để ý, sẽ gặp trường hợp này:

```python
from functools import lru_cache

@lru_cache
def f1():
	...

@lru_cache(max_size=1024)
def f2():
	...
```

Tại sao chỗ thì cần `(max_size=1024)` chỗ lại không? Vậy hãy đến phần nâng cao hơn nhé :smile:

### 4. Tham số tuỳ chọn trong decorator

Quay lại ví dụ ở phần trước, `show_input` là một tuỳ chọn, giả sử nếu không truyền vào ta có thể hiểu nó là `False`, và mình cũng muốn sử dụng nó như `lru_cache` ở trên :smile:

```python
def log(func=None, show_input=None):
	if func is None:	# lúc gọi @log(show_input=True)
		return lambda origin_func: log(origin_func, show_input=show_input)

	show_input = False 	# giá trị mặc định
	def func_with_log(*args, **kwargs):
		start_at = time.time()
		ret = func(*args, **kwargs)
		print(func.__name__, "takes", time.time()-start_at, "second")
		if show_input:
			print("Input:", args, kwargs)
		return ret
	return func_with_log
```

Cùng phân tích nhé

Với trường hợp bạn gọi `@log`, sẽ tương đương như sau:
```python
new_func = log(old_func)
```
nó sẽ lấy giá trị mặc định là false

Với trường hợp gọi `@log(show_input=True)`, sẽ tương đương:
```python
deco = log(show_input=True).   # deco đã được config
new_func = deco(old_func)
```

Vậy là vấn đề đã được giả quyết :smile:

Tóm lại, bằng việc sử dụng decorator, code của bạn sẽ:
- tái sử dụng code
- dễ bảo trì
- linh hoạt

Đến đây mình đã chia sẻ khái niệm decorator nói chung và trong Python nói riêng, hi vọng bài viết này hữu dụng với các bạn, bye bye. 


Ta có 5 nguyên lí thiết kế bắt buộc phải tuân theo khi chúng ta thiết kế ứng dụng theo hướng đối tượng, mình sẽ chia sẻ các nguyên lí trong bài viết này.
Chúng ta có 5 nguyên lí, gọi tắt là __SOLID__

* Single responsibility principle
* Open/Close principle
* Liskov principle
* Interface segregation principle
* Dependencies Inversion principle


### Ta nói về nguyên lí đầu tiên, S — Single responsibility

Hiểu nôm na nguyên lí này hướng người thiết kế đến mục tiêu là mỗi một class viết ra sẽ chỉ dùng cho 1 mục đích hay 1 nhiệm vụ cụ thể.

Giả sử bạn cần viết một class ConnectDatabase, bạn chỉ nên cài đặt các phương thức phục vụ mục đích tạo kết nối tới database mà không nên cài đặt các phương thức khác như query hay đóng kết nối.

Nguyên lí này giúp lập trình viên kiểm soát tốt thiết kế và luồng hoạt động của ứng dụng, dễ dàng bảo trì, sửa lỗi cho ứng dụng.

<Image
	src="https://miro.medium.com/max/700/0*DWendOmHviffM4Au"
	title="Photo by Andreas Wagner on Unsplash"
/>

### Nguyên lí thứ 2 là O — Open/Close principle

Nguyên lí này nhắc nhở lập trình viên rằng hãy viết class có thể mở rộng mà không được phép sửa đổi các class khác.

Hãy lấy ví dụ sau:
Giả sử chúng ta có một class là ProductLogs, class này có chức năng quản lí việc log thông tin sản phẩm trên một hệ thống thương mại điện tử. Trong class ProductLogs này bạn có phương thức cài đặt thuật toán bubble sort để sắp xếp các log. Sau một thời gian, bubble sort làm chậm quá trình sắp xếp và bạn muốn thay bubble sort bằng quick sort. Thay vì sửa code trong lớp ProductLogs, bạn tạo ra 1 class mới tên QuickProductLogs kế thừa class ProductLogs với việc Override phương thức sort.

Bằng cách áp dụng nguyên lí này, các lập trình viên dễ dang tái sử dụng code cũng như đem laị sự ổn định cho code, kiểm soát code tốt hơn.

<Image
	src="https://miro.medium.com/max/700/0*Ict0nXXku3iJPjAU"
	title="Photo by Philipp Berndt on Unsplash"
/>

### Nguyên lí thứ 3 mình sẽ nhắc tới đó là L — Liskov principle

Nguyên lí Liskov nói rằng

```
Nếu class T kế thừa class P thì ta có thể thay thế các class P bằng class T sao cho logic chương trình không bị thay đổi.
```

Nguyên lí này đã sử dụng triệt để nguyên lí kế thừa của lập trình hướng đối tượng. Các bạn khi tạo ra một class kế thừa một class khác, các bạn chỉ nên mở rộng mà không nên thay đổi behavior của class cha.

Ta lấy một ví dụ, bạn tạo ra một class là SimpleSort có phương thức sort và sau đó boss của bạn hiệu năng của việc sắp xếp cao hơn và bạn quyết định cài đặt thuật toán quick sort. Bạn kế thừa SimpleSort và override lại phương thức sort, good job! Vậy là bạn có thuật toán mới mà không làm thay đổi behavior của class cha đó là sắp xếp.

<Image
	src="https://miro.medium.com/max/700/0*J9q6aGky0ap_si3A"
	title="Photo by Huy Phan on Unsplash"
/>

### Nguyên lí tiếp theo sẽ là I — Interface segregation principle

Nguyên lí này muốn chúng ta chia một task thành các task nhỏ hơn, tránh việc một class phải cài đặt thừa chức năng mà nó đảm nhiệm

Ta cùng lấy ví dụ về nguyên lí này. Giả sử một cửa hàng có cả nhân viên bán hàng và máy bán hàng tự động. Người nhân viên thì có các hành vi như ăn, ngủ, thể dục, kiểm hàng, tính tiền và thu tiền. Bên cạnh đó, máy bán hàng thì chỉ có các hành vi kiểm hàng, tính tiền và thu tiền. Right?. Như vậy nếu bạn tạo ra 1 interface là IEmployee bao gồm các phương thức ăn, ngủ, thể dục, kiểm hàng, tính tiền và thu tiền thì máy bán hàng phải implement các phương thức không cần thiết như ăn, ngủ, thể dục.

Thay vào đó, ta sẽ có thiết kế tốt hơn bằng việc chia IEmployee thành IHuman gồm các phương thức ăn, ngủ, thể dục và IEmployee gồm kiểm hàng, tính tiền và thu tiền.
Người bán hàng — HumanEmployee sẽ implement cả 2 interface này còn máy bán hàng — MachineEmployee sẽ chỉ implement interface thứ 2.

Việc áp dụng nguyên lí này không đúng cách sẽ là hệ thống trở nên phức tạp và rối rắm nên khi áp dụng nguyên lí này, các bạn nên cân nhắc xem có nên chia hay không nhé :smile:

<Image
	src="https://miro.medium.com/max/700/0*A0t9PwrBbs4fdJUG"
	title="Photo by John Doyle on Unsplash"
/>

### Nguyên lí cuối cùng mình sẽ giới thiệu đó là D — Dependencie Inversion principle

Nguyên lí này nói rằng, các cài đặt chỉ phụ thuộc vào các bên trừu tượng (high level) hơn nó và không phụ thuộc vào các cài đặt cụ thể.

Nôm na là khi kế thừa, các class cụ thể sẽ chỉ kế thừa từ abstract class hoặc implement interface mà không kế thừa từ class được cài đặt cụ thể.

Hãy cùng lấy ví dụ: giả sử bạn có 1 class cài đặt thuật toán ShellSort và bạn muốn tăng hiệu năng ứng dụng bằng thuật toán QuickSort. Bạn không nên kế thừa từ ShellSort mà hay tạo ra một interface ISort và cả ShellSort và QuickSort implement ISort, như vậy thiết kế của bạn trông rất clear và code sẽ dễ hiểu cũng như mở rộng, hãy thử và cảm nhận :)).


<Image
	src="https://miro.medium.com/max/700/0*2yWMW5cN1bJandNg"
	title="Photo by Henry & Co. on Unsplash"
/>

Việc áp dụng các nguyên lí không chỉ giúp code tái sử dụng, dễ sửa chữa và bảo trì, nó còn là ngôn ngữ chung giúp các thành viên trong team dễ dàng trao đổi vào hiểu code của nhau.


Mình sẽ kết thúc bài viết ở đây. Hi vọng bài viết sẽ giúp mọi người có cái nhìn cơ bản về SOLID.

Tag: design_pattern

Decorator trong Python

SOLID Principles