DEV Community: Perajit

Go กับ Concurrency ตอนที่ 2: Channel

Perajit — Fri, 01 May 2026 01:31:00 +0000

ตอนที่ 2 ของบทความ "Concurrency ใน Go" เราจะมาพูดถึงวิธีการที่แนะนำให้ใช้สื่อสารกันระหว่างหลายๆ goroutine ซึ่งก็คือ Channel

Channel

แนวทางการสื่อสารสำหรับ concurrency ตาม best practice ก็คือ

"Do not communicate by sharing memory; instead, share memory by communicating."

ดังนั้น ในการสื่อสารระหว่างหลาย routine ปกติเราจะไม่แก้ค่าในตัวแปรกลาง แต่จะใช้การรับส่งค่าผ่าน channel แทน

โดย channel จะเป็นตัวแปรแบบ typed ต้องกำหนดตั้งแต่เริ่มว่าตัวแปรที่จะส่งค่าเป็นประเภทไหน

การส่งค่าเข้าไปยัง channel เขียนแบบนี้ c <- v
การรับค่าจาก channel เขียนแบบนี้ <- c

โดยที่ c คือ channel, v คือค่าตัวแปร

ตัวอย่าง

func multiply(v1 int, v2 int, c chan int) {
  c <- v1 * v2
}
func main() {
  c := make(chan int)
  go multiply(1, 2, c)
  go multiply(3, 4, c)
  a := <- c
  b := <- c
  fmt.Println(a * b)
}

จะเห็นว่าไม่มีการใช้ WaitGroup แต่ก็ main ก็ไม่ได้จบไปก่อน นั่นก็เพราะว่า channel มีกลไก blocking อยู่แล้ว มันจะหยุดรออัตโนมัติเมื่อพยายามรับหรือส่งข้อมูล

บล็อกการส่งค่าเข้าใน channel จนกว่าค่าที่ค้างอยู่จะถูกรับออกไป
บล็อกการรับค่าจาก channel รอจนกว่าจะมีค่าส่งเข้ามา

หมายความว่า เราสามารถใช้ channel เพื่อการรอในลักษณะคล้ายๆ กับ WaitGroup ก็ได้ เช่น ใช้ channel bool เพื่อรอสัญญาณว่างานจบแล้ว

ready := make(chan bool)
go foo(ready)
<-ready

มันจะรอจนกว่า foo() จะส่งค่า true เข้ามาใน ready (ซึ่งจริงๆ จะส่ง false ก็ทำงานได้ แต่ตามหลักควรส่ง true)

สังเกตว่าเราไม่ได้รับค่าออกไปใช้เลย เราแค่รอให้มีการส่งค่าเข้ามาใน channel เฉยๆ

ในการใช้งาน channel ในการรับค่าเป็น stream ปกติแล้วเรามักจะวนรับค่าโดยใช้ for range

func producer(c chan int) {
  for i := 1; i <= 5; i++ {
    fmt.Println("Sending", i)
    c <- i
    time.Sleep(500 * time.Millisecond)
  }
  close(c)
}
func main() {
  c := make(chan int)
  go producer(c)

  for i := range c {
    fmt.Print("Receiving", i)
  }

  fmt.Println("Done")
}

close(c) คือการสั่งปิด channel เพื่อไม่ให้ลูปของเราค้างรอค่าไปเรื่อยๆ เนื่องจากในฝั่งผู้รับเราใช้ for range ซึ่งจะไม่จบลูปจนกว่า channel จะปิด (กรณีที่ลูปเป็น 1:n ก็ไม่จำเป็นต้องสั่ง close() เพราะมีจำนวนลูปที่แน่นอนอยู่แล้ว)

หมายเหตุ: ให้สั่งปิด channel ที่ฝั่งผู้ส่งเมื่อฝั่งผู้รับจำเป็นต้องรู้ว่าข้อมูลหมดแล้ว การสั่งที่ฝั่งผู้รับจะเสี่ยงเกิด Panic ถ้าฝั่งผู้ส่งยังพยายามส่งข้อมูล

Buffered Channel

โดย default channel จะไม่มีความจุ (capacity = 0) หมายความว่ารับส่งค่าได้ทีละค่า และมันจะบล็อกการทำงานอย่างที่บอกไป แต่เราสามารถกำหนดค่า capacity หรือ buffer ให้กับ channel ได้ เพื่อให้มันทำงานต่อโดยไม่บล็อกจนกว่า buffer จะเต็ม เราจะเรียก channel แบบนี้ว่า buffered channel

c := make(chan int, 3)

เลข 3 ที่เรากำหนดคือ capacity (buffer) ของ channel

ในกรณีนี้

เราจะส่งค่าให้ channel ได้ 3 ค่าโดยไม่มีการบล็อกแม้จะไม่มีการดึงค่าออกจาก channel เลย แต่จะบล็อกหลังจากการส่งค่าครั้งที่ 4
ไม่บล็อกการรับค่าจาก channel จนกว่าไม่มีค่าค้่างอยู่ใน buffer

สำหรับ unbuffered channel ก็เหมือนการับส่งของกันด้วยมือ ส่วน buffered channel จะเหมือนการมีช่องรับของเพิ่มมาให้ฝากของไว้ได้ มีประโยชน์ในเคสที่ผู้รับกับผู้ส่งทำงานด้วยความเร็วต่างกันชั่วคราว เช่น มี producer กับ consumer ที่มีโอกาสที่บางช่วงจะทำงานช้ากว่าหรือเร็วกว่ากัน ถ้าไม่มี buffer เลยก็จะต้องรอกันไปมา การใช้ buffer จะช่วยให้รันได้ต่อเนื่องลื่นไหลขึ้น

Channel Direction

ตอนที่ส่ง channel เข้าไปเป็น parameter ในฟังก์ชั่น เราสามารถกำกับทิศทางของ channel ได้ด้วย

ส่งได้อย่างเดียว: func producer(c chan<- int)
รับได้อย่างเดียว: func consumer(c <-chan int)

Select Statement

การใช้ select จะคล้ายๆ กับ switch คือควบคุมการทำงานโดยเช็คค่าเงื่อนไข แต่สำหรับ select จะใช้จัดการกับ channel

โดยที่ select จะบล็อกการทำงานไว้จนกว่าจะมี case ใดเคสหนึ่งเป็นจริง

สามารถใช้ในกรณีอย่างเช่น มี 2 channel ที่เราไม่รู้ว่าค่าจะมาลงที่ channel ไหน แต่เราสนใจแค่ channel ที่ได้รับค่าก่อน

func main() {
  c1 := make(chan string)
  c2 := make(chan string)

  go func() {
    time.Sleep(1 * time.Second)
    c1 <- "A"
  }()

  go func() {
    time.Sleep(2 * time.Second)
    c2 <- "B"
  }()

  select {
  case res := <-c1:
    fmt.Println("Received from c1", res)
  case res := <-c2:
    fmt.Println("Received from c2", res)
  }
}

select จะรอจนกว่าจะมีข้อมูลจาก c1 หรือ c2 (ซึ่งจากโค้ดก็คือ c1) และจะจบการทำงาน เพราะฉะนั้นเราจะเห็นข้อความแค่ "Received from c1"

หรือเราอาจจะใช้เลือกเคสที่มีการรับหรือส่งค่าก่อน เช่น

select {
case a := <- inChan:
  fmt.Println("Received a", a)
case outChan <- b:
  fmt.Println("Sent b", b)
}

นอกจากนั้นก็ยังมีเทคนิคที่ใช้กันบ่อย เช่น

1) การทำ timeout
สำหรับกรณีที่ไม่มีข้อมูลส่งมาในเวลาที่กำหนด เราจะใช้รูปแบบนี้

select {
case res := <-c1:
  fmt.Println("Received from c1", res)
case <- time.After(5 * time.Second)
  fmt.Println("Timeout")
}

2) การใช้ default
สำหรับกรณีที่จะไม่หยุดรอเลย เช่นในกรณีที่ channel ถูกบล็อกอยู่ เพื่อป้องกันไม่ให้โปรแกรมค้าง

select {
case res := <-c1:
  fmt.Println("Received from c1", res)
default:
  fmt.Println("No message")
}

3) ใช้เพื่อหยุดการทำงาน

select {
case res := <-c1:
  fmt.Println("Received from c1", res)
case <-abortChan
  fmt.Println("Abort")
  return
}

Go กับ Concurrency ตอนที่ 1: Basic & Synchronization

Perajit — Fri, 01 May 2026 01:25:55 +0000

ตอนแรกของบทความ "Concurrency ใน Go" เราจะว่ากันด้วยพื้นฐานเกี่ยวกับ concurrency และ synchronization

Concurrency vs Parallelism

ก่อนอื่นมาทำความเข้าใจสองคำนี้กันก่อน

Concurrency

นิยามคือ ความสามารถในการจัดการงานหลายอย่างในช่วงเวลาเดียวกัน
การทำงานแต่ละงานไม่จำเป็นต้องเกิดขึ้นพร้อมกัน แค่สลับงานไปมาก็ถือว่า concurrency
ลักษณะสำคัญคือ ช่วงเวลาเริ่มต้นของแต่ละงานมีการ overlap

Parallelism

นิยามคือ ความสามารถในการประมวลผลงานหลายอย่างพร้อมกัน
ต้องอาศัย hardware

ภาพประกอบโดย Gemini

หมายเหตุ: concurrency สามารถเป็น parallelism หรือไม่ก็ได้ ขึ้นอยู่กับ hardware mapping

ต่อให้ไม่ได้รัน parallel แต่การรัน concurrent ก็สามารถทำให้ทำงานได้เร็วขึ้นได้ เพราะปกติในงานทั่วไปมักจะต้องรออะไรบางอย่างเสมอ เช่น รอดึงค่าจาก memory หรือเก็บค่าลง memory ในระหว่างที่รอนี้ถ้าเราสามารถสลับไปรันอย่างอื่นได้ก็จะทำให้ทำงานโดยรวมได้มีประสิทธิภาพมากขึ้น

Concurreny และ Parallelism ใน Go

Go เป็นภาษาที่มี concurreny แบบ built-in คือไม่จำเป็นต้องใช้ library ช่วย
และสามารถทำงานเป็น parallelism ได้ด้วย โดยการกำหนดค่า GOMAXPROCS > 1

ตัวอย่างการกำหนดค่าจากในโค้ด

runtime.GOMAXPROCS(4)

หรือจะตั้งค่าผ่าน environment variable ก็ได้

export GOMAXPROCS=4

GOMAXPROCS คือการกำหนดจำนวน OS threads ที่สามารถประมวลผล Go code ได้พร้อมกันในช่วงเวลาหนึ่ง

ใน Go เวอร์ชั่น 1.5 เป็นต้นไป ค่าเริ่มต้นของ GOMAXPROCS เท่ากับจำนวน Logical CPUs ของเครื่องที่ใช้งาน ซึ่งเป็นค่าที่ดึงประสิทธิภาพของ hardware ออกมาได้สูงสุดอยู่แล้ว ไม่จำเป็นต้องแก้ไข ถ้าตั้งค่าสูงเกินไปจะทำให้เกิด context switching สูงขึ้น ทำให้ทำงานช้าลง

Goroutines

ปกติแล้ว concurrency ในภาษาอื่นจะใช้ Thread แต่สำหรับใน Go เราจะใช้สิ่งที่เรียกว่า Goroutine ซึ่งอาจจะเรียกว่าเป็น Lightweight Thread

แล้วมันต่างกันยังไง?

อย่างที่บอกว่า concurrency อาศัยการสลับงานไปมา หรือเรียกว่าการจัดตารางงาน (scheduling) และสำหรับ thread ตัวที่ทำหน้าที่จัดตารางงานก็คือ OS

แต่ใน Go เนี่ย goroutine จะรันอยู่ภายใน thread อีกที (สามารถมีได้ถึงหลายพันหรือหลายหมื่นภายใน thread เดียว และใช้ memory น้อยกว่า thread มาก) และจะอาศัย Go Runtime Scheduler ทำหน้าที่จัดตารางงาน

เมื่อเราสั่งรัน main() Go จะสร้าง goroutine ตัวแรกสุดที่เรียกว่า main routine ขึ้นมารัน ถ้าเราต้องการให้โปรแกรมทำงานแบบ concurrency เราก็สามารถรันงานที่ต้องการในอีก routine ได้ง่ายๆ แค่เขียน keyword go ข้างหน้าตอนเรียกฟังก์ชั่นเท่านั้นเอง

มาลองกันดูหน่อย

func main() {
  go fmt.Println("New Routine")
  fmt.Println("Main Routine")
}

ผลลัพธ์ก็คือ เราจะเห็นแค่ข้อความเดียว...

Main Routine

อ้าว?!

เรื่องของเรื่องก็คือ main() จบการทำงานไปก่อนที่ goroutine ใหม่จะทำงาน ดังนั้นเราต้องสั่งให้ Go รอ goroutine ใหม่ของเราก่อน

ซึ่งเราอาจจะสามารถสั่งให้ sleep รอก็ได้ เช่นรอไปเลย 100 ms แบบนี้

func main() {
  go fmt.Println("New Routine")
  time.Sleep(100 * time.Millisecond)
  fmt.Println("Main Routine")
}

แต่อย่างที่รู้กันว่าไม่ควร เพราะจริงๆ เราบอกไม่ได้ว่าต้อง sleep นานแค่ไหน วิธีรออย่างถูกต้องก็คือรอจนกว่ามันจะเสร็จนั่นแหละ แต่ทำยังไงเดี๋ยวเราจะพูดถึงกันหลังจากนี้

Synchronization และ Sync Package

synchronization คือกลไกที่ใช้ควบคุมลำดับและการเข้าถึงทรัพยากรที่ใช้ร่วมกัน เพื่อป้องกันปัญหาที่เกิดจากการทำหลายงานชนกัน โดยเฉพาะปัญหา race condition

สำหรับใน Go เราจะใช้แพ็กเกจ sync สำหรับทำ synchronization ซึ่งมีตัวช่วยหลายอย่าง แต่เราจะหยิบมาพูดถึง 3 ตัว คือ sync.WaitGroup, sync.Once และ sync.Mutex

sync.WaitGroup

หนึ่งในวิธีที่จะบังคับให้ Go รอจนกว่างานใน routine ย่อยจะเสร็จได้ก็คือการใช้ sync.WaitGroup

หลักการการทำงานคือ

WaitGroup จะเก็บตัวนับ ซึ่งก็คือตัวเลขจำนวนงานที่ต้องรอ
ใช้ method Add() เพื่อเพิ่มตัวนับขึ้น (ใส่ตัวเลขจำนวนงานเท่าไหร่ก็ได้ ไม่จำเป็นต้องเพิ่มทีละ 1)
ใช้ method Done() บอกมันเมื่อเสร็จแต่ละงาน เพื่อให้เลขลดลง
ใช้ method Wait() เพื่อสั่งให้รอจนตัวนับเป็น 0 ซึ่งหมายความว่าไม่มีอะไรให้รอแล้ว

ตัวอย่างการใช้งาน

func foo(wg *sync.WaitGroup) {
  fmt.Println("New Routine")
  wg.Done() // บอกว่ารันจบแล้วงานนึง
}

func main() {
  var wg sync.WaitGroup
  wg.Add(2) // บอกว่ามีเพิ่ม 2 งาน
  go foo(&wg)
  go foo(&wg)
  wg.Wait() // บอกให้รอจนกว่างานทั้งหมดจะเสร็จ
  fmt.Println("Main Routine")
}

หมายเหตุ: ต้องส่งค่า wg เป็น pointer เพื่อให้ทุกตัวลดตัวนับที่ตัวเดียวกัน ถ้าส่งแบบ value จะทำให้โปรแกรมค้างเพราะได้ wg เป็นค่า copy คนละตัวกัน

เราจะเห็นผลลัพธ์เป็น

New Routine
New Routine
Main Routine

นั่นก็คือตอนนี้โปรแกรมของเราสามารถรัน goroutine ย่อยๆ ได้โดยไม่จบการทำงานไปก่อน

sync.Once

เป็นเครื่องมือที่ทำให้ฟังก์ชั่นที่ระบุถูกรันแค่ครั้งเดียวเท่านั้น ไม่ว่าจะมี goroutine เรียกใช้งานกี่ครั้งก็ตาม ใช้สำหรับการทำ initialization ที่ต้องทำแค่เพียงครั้งเดียว เช่น DB connection, setup state หรือทำ singleton pattern

func setup() {
  fmt.Println("Setup")
}

func main() {
  var once sync.Once
  var wg sync.WaitGroup

  for i := 0; i < 5; i++ {
    wg.Add(1)
    go func() {
      defer wg.Done()
      once.Do(setup)
    }()
  }

  wg.Wait()
}

จากตัวอย่าง ถึงจะมีการเรียก once.Do(setup) จากหลาย goroutine (5 ตัว) แต่ setup() จะถูกเรียกทำงานแค่ครั้งเดียว

sync.Mutex

Mutex มาจาก Mutual Exclusion เป็นกลไกที่ใช้ป้องกันไม่ให้ goroutine หลายตัวเข้าถึง critical section ได้ในช่วงเวลาเดียวกัน

หลักการทำงานคือ

ใช้ Lock() เพื่อล็อกไม่ให้ goroutine อื่นเข้ามาใช้งาน
ใช้ Unlock() เพื่อปลดล็อกให้ goroutine อื่นเข้ามาใช้งานต่อได้

func main() {
  var mu sync.Mutex
  counter := 0
  var wg sync.WaitGroup

  for i := 0; i < 1000; i++ {
    wg.Add(1)
    go func() {
      defer wg.Done()

      mu.Lock()
      counter++
      mu.Unlock()
    }()
  }

  wg.Wait()
  fmt.Println(counter)
}

critical section ซึ่งในที่นี้ก็คือ counter++ จะถูกล็อกเอาไว้ให้รันได้ทีละ goroutine ทำให้อัพเดทค่าได้อย่างถูกต้อง ถ้าไม่มีการล็อกไว้ผลลัพธ์ของ counter อาจไม่ใช่ 1000 (ถ้าใช้เยอะจะทำให้ performance แย่ลงเพราะต้องรอ)

หมายเหตุ: ปกติแล้วใน concurrency เราไม่นิยมแชร์ตัวแปรกลางและแก้ไขค่าร่วมกัน แต่มักจะใช้การส่งค่าผ่าน channel ซึ่งจะกล่าวถึงในบทความถัดไป

AWS vs GCP ตอนที่ 3: Organization & User Management

Perajit — Thu, 23 Apr 2026 23:23:51 +0000

ออกตัวเหมือนบทความก่อนๆ คือเราไม่ได้เชี่ยวชาญเรื่องนี้ เลยจะเขียนสรุปคร่าวๆ แบบไม่ลงรายละเอียดมาก

Organization

สำหรับ AWS

ใน AWS เราสามารถจัดการ "โครงสร้างองค์กร" ได้โดยอาศัยบริการ AWS Organizations โดยจะทำให้พนักงานในองค์กรแยกใช้งานหลาย account ภายใต้องค์กรได้ (Multi-Account)

เมื่อเราสร้าง Organization ขึ้นมา บัญชีที่ใช้งานอยู่จะกลายเป็น "Management Account" (ขอเรียกว่าบัญชีหลัก) ในทันที ซึ่งในบัญชีหลักนี้เราจะสามารถจัดการสิ่งต่างๆ ในองค์กรได้ เช่น

Organization Units (OUs): สร้างและจัดการ OUs
Account:
- สร้างบัญชีลูกในองค์กร โดยไม่ต้องกรอกข้อมูลบัตรเครดิต เพราะระบบจะไปตัดเงินรวมที่บัญชีหลัก (Consolidated Billing)
- ย้าย OU ของบัญชีลูก
Service Control Policies (SCPs): สร้างและจัดการ SCPs

สำหรับ Organization Units (OUs) คือกลุ่มย่อยที่ใช้สำหรับจัดกลุ่มบัญชีในองค์กร สามารถซ่อนกันเป็นลำดับชั้นได้ และมีการสืบทอด SCPs ลงด้านล่าง

ส่วน Service Control Policies (SCPs) คือนโยบายที่ใช้กำหนดขอบเขตสูงสุดของสิทธิ์ สามารถสั่ง Explicit Deny ซึ่งมีผลเหนือกว่าทุกอย่างแม้กระทั่ง Root User ก็ไม่สามารถฝ่าฝืนได้ โดยเราสามารถผูก SCPs ได้ 3 ระดับ

ระดับ Root: มีผลกับทุกบัญชีในองค์กร
ระดับ OU: มีผลกับทุกบัญชีใน OU
ระดับ Account: มีผลแค่บัญชีนั้นๆ

หมายเหตุ: เพื่อความปลอดภัย ไม่ควรใช้ Management Account ในการทำงานทั่วไป ควรเก็บไว้สำหรับงาน admin และ billing เท่านั้น

สำหรับ GCP

ตามที่เขียนถึงไปในบทความก่อนหน้า Organization ใน GCP เป็น root ของลำดับชั้นทรัพยากร ดังนั้น

มี Organization เสมอ ไม่ต้องใช้ service ไหนมาสร้างหรือจัดการ
Organization ใน GCP ใช้ Folder เพื่อจัดกลุ่มจัดการทรัพยากร ในขณะที่ Organization ใน AWS ใช้ OUs เพื่อจัดกลุ่มบัญชี
ใช้ Organization Policies ในการควบคุมกฎขององค์กร (เทียบได้กับ SCPs ใน AWS)

User Management

สำหรับ AWS

การจัดการ User เราจะใช้ Service ที่ชื่อว่า Identity Center (ชื่อเดิมคือ AWS SSO)

Identity Center ถูกออกแบบมาให้เป็นระบบภายในองค์กร จะถูกเปิดใช้งานที่บัญชีหลักขององค์กร (หมายความว่าจำเป็นต้องสร้าง Organization ก่อนเสมอ) และมันจะมองเห็นเฉพาะบัญชีที่อยู่ภายใต้ององค์กรนั้นเท่านั้น

สิ่งที่เราสามารถจัดการได้จาก Identity Center หลักๆ มีตามนี้

1) Multi-Account Access

Single Sign-On: โดยปกติถ้าเราสร้างบัญชีในองค์กร ถ้าไม่ใช้ Identity Center เราจะเข้าไปบัญชีนั้นโดยการ Switch Role จากบัญชีหลัก แต่เมื่อใช้ Identity Center จะมีลิงค์ที่เรียกว่า AWS Access Portal ซึ่งเป็น unique URL ของแต่ละองค์กร (พนักงานจำแค่ URL เดียว) รวบรวมรายการสิทธิ์ในการเข้าถึงบัญชีต่างๆ (Account + Role) ให้สามารถคลิกเข้าล็อกอินได้เลย

2) Identity Management

สามารถสร้างและจัดการ User และ Group ในทุกบัญชีขององค์กร
สามารถเชื่อมต่อกับระบบ Identity Provider ข้างนอก (Federation)
- ถ้าบริษัทมีระบบเดิมอยู่แล้ว เช่น Azure AD, Okta, Google Workspace ก็สามารถเข้า AWS ด้วยการล็อกอินระบบเดิมได้เลย (เข้าผ่าน Access Portal ที่จะ redirect ไปยัง IdP ที่เชื่อมต่อ)
- ไม่จำเป็นต้องสร้าง User ใหม่
- เบื้องหลังคือ ล็อกอินด้วย Identity แล้ว AWS จะทำการ Assume Role ให้เข้าไปใช้งาน (ไม่มี IAM User อยู่ในบัญชี)

3) Permission Sets

สามารถสร้าง Permission Sets เพื่อจัดการสิทธิ์ของแต่ละบัญชี
Permission Sets คือชุดของสิทธิ์ในองค์กร แทนที่เราจะเขียน Policy ในบัญชีลูกทีละบัญชี ก็สร้าง Permission Sets แล้วผูกเข้ากับบัญชีในองค์กรแทน

4) Cloud Applications

สามารถใช้ Identity Center เป็นตัวกลางล็อกอินเข้าแอปพลิเคชั่นอื่นที่บริษัทใช้ได้ด้วย
พนักงานล็อกอินที่เดียวแล้วสามารถใช้งานได้ทั้ง AWS และแอปพลิเคชั่นอื่น

Identity Center กับ Organization ทำงานเชื่อมโยงกัน เมื่อมีการสร้าง User จาก Identity Center เราก็จะมองเห็น User จากหน้าคอนโซลของ Organizations (เพราะเป็น Account ขององค์กรนั้น) และในทางกลับกัน ถ้าสร้าง Account จากใน Organizations เราก็จะมองเห็น Account นั้นในหน้าของ Identity Center ด้วย

หมายเหตุ: แต่ Permission Sets ต้องจัดการใน Identity Center เท่านั้น เช่นเดียวกับ SCPs ที่ต้องจัดการใน Organizations เท่านั้นเช่นกัน (แยกกฎของคนออกจากกฎของกลุ่ม)

สำหรับ GCP

GCP ไม่ได้มีระบบสร้าง User Account ในตัวเองเหมือน AWS IAM User แต่อาศัยการดึงข้อตัวตน (Identity) จากภายนอก:

Google Account
Cloud Identity หรือ Google Workspace

ถ้าต้องการใช้ตัวตนจากระบบอื่น เช่น Azure AD, Okta ต้องทำ Workforce Identity Federation (คล้ายกับใน AWS Identity Center) เพื่อให้ GCP ยอมรับและให้ถือเป็นคนใน Organization

สรุปข้อเปรียบเทียบ

Organization ใน AWS ใช้จัดการบัญชี ส่วน Organization ใน GCP เป็น root ในการจัดการการเข้าถึงทรัพยากร
ใน AWS ใช้ SCPs ควบคุมกฎขององค์กร ส่วนทางฝั่ง GCP ใช้ Organization Policies

AWS vs GCP ตอนที่ 2: IAM

Perajit — Wed, 22 Apr 2026 20:11:03 +0000

ออกตัวก่อนว่าเหมือนบทความที่แล้ว เราอาจจะเขียนคล้ายๆ ประมาณโน้ตส่วนตัว สรุปคร่าวๆ แบบไม่ลงรายละเอียด เพราะไม่ได้เชี่ยวชาญ

ตอนที่ 1 ว่าด้วย Network & Security ไปแล้ว ตอนนี้มาพูดถึงอีกหัวข้อที่ต่างกันมากกว่านั้นอีก ซึ่งก็คือ IAM (Network ยังมีความคล้าย แต่ IAM นี่โครงสร้างไปคนละแนวทางกันเลย)

IAM หรือ Identity and Access Management เป็นระบบที่ควบคุมว่า "ใคร" (who) สามารถ "ทำอะไร" (what) กับ "ทรัพยากรไหน" (which) บนระบบ

AWS

Account vs User

AWS แยกคำว่า Account ออกจาก User

Account หมายถึง AWS Account (หรือเรียกว่า Root Account) เป็นเจ้าของทรัพยากรทั้งหมด และเป็นตัวตนที่ใช้ในการจ่ายเงิน

ในเคสปกติ ล็อกอินโดยใช้อีเมลที่สมัคร (ยกเว้นกรณี multi-account)
ในเคสปกติ มีสิทธิ์สูงสุด ทำได้ทุกอย่าง (ยกเว้นถูกบล็อกด้วย Service Control Policy ซึ่งเป็นนโยบายที่ใช้ควบคุมสิทธิ์ของบัญชี)
ใช้สร้าง admin คนแรก (หลังจากนั้นปล่อยให้ admin จัดการสร้าง user คนถัดๆ ไปเอง) และจัดการเรื่อง billing เท่านั้น ไม่แนะนำให้ใช้ในงานทั่วไป เพราะมีสิทธิ์สูงเกินไป

ส่วน User หมายถึง IAM User คือตัวตนที่ถูกสร้างขึ้นมาภายใต้บัญชี เพื่อใช้ทำงานในระบบ

ล็อกอินโดยใช้ credentials ที่ admin สร้างให้
มีสิทธิ์แค่ตามที่ admin กำหนดให้เท่านั้น
ใช้ทำงานต่างๆ นอกเหนือจากการสร้าง user

AWS IAM Entities

IAM User ที่กล่าวถึงไป ก็คือหนึ่งใน IAM Entities (สิ่งที่ถูกสร้างและจัดการในระบบ IAM) ซึ่งเป็นประเภทหนึ่งของ Principal (ใครหรืออะไรที่พยายามเข้าถึงทรัพยากร) ที่เป็นตัวแทนคำว่า "ใคร" ใน IAM นั่นเอง

IAM Entities จะมี 3 แบบหลักๆ ตามนี้

IAM User: เป็นตัวตนที่ใช้แทนคน มีข้อมูลยืนยันตัวตนแบบถาวร (permanent credentials) เช่น username/password หรือ access keys
IAM Group: กลุ่มของ User ใช้สำหรับจัดชุดสิทธิ์ (Policy) ให้หลายคนพร้อมกัน (อันนี้ไม่สามารถล็อกอินได้)
IAM Role: เป็นตัวตนแบบชั่วคราว ไม่มีรหัสผ่านถาวร เหมือนการขอใบรับรองชั่วคราวเพื่อใช้ทำงาน ให้สิทธิ์เข้าถึงทรัพยาการ โดยอาศัยกระบวนการ Assume Role

มาถึงตรงนี้ก็อาจจะยังไม่เห็นภาพว่า IAM Role (ต่อไปนี้จะเรียกแค่ Role) มีไว้ทำไม แต่เจ้า Role เนี่ยแหละที่ใช้เยอะมาก ตัวอย่างเช่น

1) ใช้สำหรับบริการ AWS (Service Role)

อันนี้เป็นกรณีที่ใช้กันบ่อยสุด คือการให้สิทธิ์กับบริการของ AWS เพื่อไปทำงานบางอย่าง

เนื่องจากว่าแต่ละบริการของ AWS ไม่ได้เรียกกันเองได้โดยอัตโนมัติ เช่น มีเครื่อง EC2 อยากจะอ่านไฟล์ใน S3 ถ้าเราไม่ทำอะไรเลยมันจะไม่มีสิทธิ์คุยกัน เราต้องสร้าง Role ที่ให้สิทธิ์อ่านไฟล์จาก S3 แล้วเอาไปผูกไว้กับ EC2 เพื่อมันสามารถทำงานของมันได้

2) ใช้สำหรับข้าม Account (Cross-Account Access)

กรณีที่มีหลายบัญชี (multi-account) เราสามารถทำให้ user จาก Account A เข้าไปทำอะไรใน Account B ได้ โดยการสร้าง Role ใน Account B โดยกำหนดให้อนุญาตให้คนจาก Account A เข้ามาได้

3) ใช้สำหรับล็อกอินจากระบบภายนอก

เช่น การล็อกอินด้วย Google, Microsoft 365 หรือบริการอื่น เพื่อเข้ามาทำงานใน AWS
ระบบจะไม่มีได้สร้าง User ให้ใน AWS แต่จะใช้การผูก Role ให้หลังจากการยืนยันตัวตนจากข้างนอก

4) ใช้สำหรับเชื่อมต่อกับระบบภายนอก

สำหรับการเชื่อมต่อการใช้บริการจากระบบภายนอก จำเป็นต้องสร้าง Role ให้กับบริการนั้นๆ

AWS IAM Policies

พูดถึง "ใคร" ในระบบ IAM ไปแล้ว มาถึง "ทำอะไร" กับ "ทรัพยากรไหน" กันบ้าง สิ่งที่กำหนดทั้ง 2 อย่างนี้ก็คือ Policy นั่นเอง

Policy เป็นเอกสารรูปแบบ JSON ที่ระบุว่า อนุญาต (Allow) หรือ ปฏิเสธ (Deny) การเข้าถึงส่วนไหนในระบบ หน้าตาอะไรประมาณนี้

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-bucket"
    }
  ]
}

อธิบาย JSON

Version: เวอร์ชั่นของภาษา Policy ซึ่งปัจจุบัน AWS บังคับใช้ค่าเดียวคือ 2012-10-17
Effect: Allow หรือ Deny
Action: ทำอะไร
Resource: ทรัพยากรไหน

หมายเหตุ: สังเกตว่าใน 1 Policy กำหนดได้หลายสิทธิ์ (Statement เป็น list)

GCP

ทางฝั่ง GCP ก่อนจะพูดถึง IAM จะต้องว่าด้วย "ลำดับชั้นของทรัพยากร" (Resource Hierarchy) กันก่อน

GCP Resource Hierarchy

ลำดับชั้นนี้จะมีการสืบทอดนโยบาย (Policy) จากชั้นบนสู่ชั้นล่าง โดยแบ่งลำดับชั้นตามนี้

1) Organization

เป็นจุดสูงสุดของโครงสร้าง
เชื่อมต่อกับโดเมนของบริษัท เช่น Google Workspace หรือ Cloud Identity
ช่วยให้มองเห้นและควบคุมทรัพยากรทั้งหมดในบริษัทได้จากที่เดียว

2) Folder

เป็นตัวเลือกเสริม จะมีหรือไม่มีก็ได้
สามารถมี folders ย่อยซ้อนกันกี่ชั้นก็ได้
ใช้สำหรับแบ่งกลุ่ม เช่น แบ่งตามแผนก (ฝ่ายไอที, ฝ่ายการตลาด) หรือแบ่งตามสภาพแวดล้อม (development, production)

3) Project

เป็นหัวใจสำคัญ ทรัพยากรทุกอย่างจะต้องอยู่ภายใต้ Project เสมอ
เป็นระดับที่ใช้ในการจัดการเรื่อง billing และการเปิดใช้ API ต่างๆ
Project ID จะต้องไม่ซ้ำกันเลยใน GCP

4) Resource

บริการของ GCP ที่เราใช้งานกัน

ข้อดีของลำดับชั้นคือ สามารถใช้ประโยชน์จากการสืบทอดสิทธิ์ ทำให้สามารถจัดการทรัพยากรจำนวนมากได้เป็นระบบระเบียบขึ้น และยังช่วยให้สามารถจัดกลุ่มทรัพยากรเพื่อให้สรุปค่าใช้จ่ายได้ง่ายขึ้และมีประสิทธิภาพ

GCP IAM Principals

กลับมาที่ IAM กันต่อ ส่วนแรกของ IAM ก็คือ "ใคร" สำหรับ GCP จะเรียกว่า Principals หรือ Members

ประกอบด้วย

Google Account: อีเมลส่วนตัว (@gmail.com)
Service Account: บัญชีสำหรับ "แอปพลิเคชั่น" หรือ "เครื่อง" (Machine) เพื่อคุยกันเอง ไม่ต้องมีรหัสผ่าน ใช้กุญแจเข้ารหัส (Cryptographic Keys) ในการยืนยันตัวตน
Google Group: กลุ่มของ User
Google Workspace / Cloud Identity: บัญชีขององค์กร

หมายเหตุ: Account ใน GCP มีอีเมลเสมอ รวมถึง Service Account ด้วย

GCP IAM Roles

ส่วนนี้คือตัวแทนของ "ทำอะไร" ใน IAM

เป็นชุดของสิทธิ์ในการเข้าถึงทรัพยาการ (อย่าสับสนกับ Roles ของ AWS) ซึ่งใน GCP ไม่ได้แยกเป็น permission แต่ละเรื่องย่อยๆ แต่จะมัดรวมกันอยู่ใน Role

โดยจะแบ่งออกเป็น 3 ประเภท

1) Basic Roles

เป็นพวก Role พื้นฐานของ GCP ที่ให้สิทธิ์กว้างๆ มี 3 อย่างคือ Owner, Editor, Viewer

2) Predefined Roles

เป็นพวก Role ที่ Google เตรียมไว้ให้ตามหน้าที่งาน เจาะจงไปที่แต่ละบริการ เช่น Storage Admin หรือ Compute Viewer

3) Custom Roles

เป็น Role ที่ user สร้างขึ้นเอง ใช้เมื่อต้องการสิทธิ์การใช้งานที่เฉพาะเจาะจง

GCP IAM Policy

เป็นตัวเชื่อม Principal กับ Role เข้าด้วยกัน โดยจะเป็น resource-based คือเราจะเอาไปผูกไว้กับทรัพยากร (ในขณะที่ใน AWS เราจะเอา Policy ไปผูกไว้ที่ User)

หน้าตาของ Policy ใน GCP จะเป็นประมาณนี้

{
  "bindings": [
    {
      "role": "roles/storage.admin",
      "members": [
        "user:storage-admin@example.com",
        "serviceAccount:my-app@project.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/viewer",
      "members": ["group:dev-group@example.com"]
    }
  ],
  "etag": "xxxx",
  "version": 1
}

หมายเหตุ: โดยปกติ GCP IAM Policy คือการ Allow เท่านั้น ถ้าต้องการ Deny จะใช้ Deny Policy เข้ามาช่วย

สรุปข้อเปรียบเทียบ

โครงสร้าง IAM ของ AWS โดยพื้นฐานเป็นแบบ flat (แต่สามารถสร้างโครงสร้างองค์กรได้จากบริการ AWS Organizations) ในขณะที่ GCP เป็นลำดับชั้นลงมา
AWS Role คือ "ตัวตน" (Identity) ส่วน GCP Role คือ "ชุดของสิทธิ์" (Permissions)
การทำงานกับ resource ในระบบ AWS จะใช้ Role ส่วนใน GCP ใช้ Service Account
AWS IAM Policy ใช้กำหนดส่วน "ทำอะไร" กับ "ทรัพยากรไหน" แล้วใช้ผูกกับ Entities (Identity-based) ส่วน GCP IAM Policy ใช้เชื่อม "ใคร" เข้ากับสิทธิ์อนุญาติให้ "ทำอะไร" แล้วนำไปผูกกับทรัพยากร (Resource-based)
AWS IAM Policy สามารถกำหนดได้ทั้ง Allow หรือ Deny ส่วน GCP IAM Policy โดยพื้นฐานจะเป็น allow-only

AWS vs GCP ตอนที่ 1: Network & Security

Perajit — Tue, 21 Apr 2026 14:31:30 +0000

บทความนี้เขียนเพื่อพยายามสรุปเปรียบเทียบ AWS และ GCP จะเขียนออกแนวโน้ตส่วนตัว แบบสรุปคร่าวๆ ไม่ลงรายละเอียดเยอะ (เพราะก็ไม่ได้เชี่ยวชาญ 555)

ที่คิดไว้ก็อยากเขียนหลายเรื่อง แต่ขอเริ่มจากเรื่อง Network ก่อนแล้วกัน

Network Architecture

ก่อนอื่นต้องพูดถึงคำศัพท์กันก่อน

ในแง่ภูมิศาสตร์: Global, Region, Zone (สำหรับ AWS เรียก Availability Zone หรือ AZ)
- ในระบบ cloud แต่ละเจ้าจะแบ่งโครงสร้างพื้นฐานในเชิงภูมิศาสตร์ตามบริเวณที่มี data center
- Global คือทั้งโลก ประกอบด้วยหลายๆ Region ซึ่งเป็นที่ตั้งที่อยู่ห่างกันมาก
- แต่ละ Region จะประกอบด้วยหลาย Zone (สำหรับ AWS เรียก availability zone หรือ AZ) อีกที
ในแง่เครือข่าย: VPC, Subnet
- VPC ที่เป็นวงเครือข่ายที่ resource ภายในสามารถมองเห็นกันได้แต่ภายนอกไม่สามารถมองเห็นเข้ามาได้ถ้าไม่ได้รับอนุญาต
- Subnet ส่วนย่อยของ VPC

ความแตกต่างที่ชัดเจนคือ

สำหรับ AWS:

VPC span เป็น Regional ไม่สามารถ span ข้าม Region ได้
Subnet อยู่เฉพาะใน AZ เดียวเท่านั้น ไม่สามารถ span ข้าม AZ ได้

ในขณะที่ GCP:

VPC span เป็น Global ครอบคลุมทั่วโลก
Subnet เป็น Regional คือ span ครอบคลุมได้หลาย Zone (เวลาวาง VM ยังต้องเลือก Zone แต่ IP Address มาจาก pool เดียวกันทั้ง Region)

ความแตกต่างนี้ทำให้ GCP สามารถคุยข้าม Region ได้เลยโดยไม่ต้องทำอะไรเพิ่ม ขณะที่ AWS ต้องมีขั้นตอนเพิ่มเติม (เช่น ทำ Peering) เพื่อให้คุยข้าม Region ได้

Network Routing

การคุม traffic ใน Network จะใช้ Route Table (AWS) หรือ Routes (GCP)โดยมีความแตกต่างกันตามนี้

AWS Route Table

อยู่ในเลเวล Subnet คือแต่ละ VPC จะมีได้หลาย Route Table และควบคุม traffic ของแต่ละ Subnet แยกกันด้วยการสร้าง Route Table ที่ต่างกันไปผูกไว้
ถ้าไม่มีการผูก Route Table ที่สร้างแยกไว้ Subnet จะใช้ Main Route Table ซึ่งเป็นตารางกลางสำหรับทุก Subnet ซึ่งกำหนดให้ component ทุกตัวคุยกันผ่าน internal IP ได้ภายใน VPC

GCP Routes

มี Routes ตารางเดียวเป็นระดับ Global แชร์กันทั้งโลก
สามารถสร้าง Route ให้มีผลเฉพาะสำหรับ VM บางตัวได้โดยการใส่ Network Tags
เมื่อมีการสร้าง Subnet ใหม่ ระบบจะสร้าง Route สำหรับการติดต่อภายใน (local) ให้แบบ Global โดยอัตโนมัติ หมายความว่า component จากคนละ Region จะคุยกันผ่าน internal IP ได้เลย

Network Security

Network Security in AWS

AWS แบ่งตัวควบคุม security เป็น 2 เลเยอร์ คือ ในระดับ Subnet และระดับ Instance

Security Group:

ควบคุมระดับ Instance
เป็นการควบคุมแบบ Stateful หมายความว่า มีการจำเส้นทางเข้าออกของ traffic ถ้าขาเข้าผ่านได้ ขาออกก็จะผ่านได้โดยอัตโนมัติ
ควบคุมแค่ Allow เท่านั้น (white-list)
ค่า default คือ Deny ขาเข้าทั้งหมด แต่ Allow ขาออกทั้งหมด ทำให้ instance สามารถเรียกออกไปข้างนอกได้เพื่อ install package ต่างๆ ได้

Network ACL (NACL):

ควบคุมระดับ Subnet
เป็นการควบคุมแบบ Stateless หมายความว่า ไม่มีการจำการเส้นทางเข้าออกของ traffic ต่อให้ขาเข้าผ่านเข้ามาได้แล้วมันก็ไม่ได้ยอมให้ขาออกผ่านได้เอง ต้องกำหนดกฎของ "ขาเข้า" (ingress) และ "ขาออก" (egress) แยกกัน
ควบคุมได้ทั้ง Allow และ Deny (สามารถทำ black-list ได้)
โดย default จะ allow ทั้งหมด ทั้งขาเข้าและขาออก

ใน AWS มักจะใช้ Security Group เป็นหลัก และใช้ NACL แค่เป็นด่านเสริมเพื่อ black-list IP ไม่พึงประสงค์

Network Security in GCP

มีตัวควบคุม security หลักๆ คือ Firewall Rules เป็นการควบคุมแบบ Stateful โดยมีค่า default เหมือนกับ Security Group (stateful เหมือนกัน) คืออนุญาตให้ทุกอย่างวิ่งออกได้ทั้งหมด แต่บล็อกทุกอย่างที่วิ่งเข้า

ควบคุมได้ทั้ง Allow และ Deny ทำให้เราสามารถใช้ทำ black-list กับ white-list ได้โดยอาศัยการตั้งค่า Deny/Allow, Priority

ทำ Deny (black-list):
- สร้างกฎโดยใช้ Action: Deny, Priority: 100 (ตัวเลขน้อยกว่ากฎ Allow หมายถึงสำคัญมากกว่า)
- ระบุ Source IP ที่ต้องการบล็อก
ทำ Allow (white-list):
- สร้างกฎโดยใช้ Action: Allow, Priority: 1000 (ตัวเลขมากกว่ากฎ Deny หมายถึงสำคัญน้อยกว่า)
- ระบุ Source IP ที่ต้องการให้ผ่าน

Firewall Rules ทำงานที่ระดับ VPC แต่สามารถเซ็ตค่าให้ทำงานในระดับ Instance (เหมือน Security Group) หรือ Subnet (เหมือน NACL) ได้

ควบคุมระดับ Instance (เทียบกับ Security Group): อาศัย Target Tags ระบุเป้าหมายกลุ่มของ VM ที่ต้องการบังคับใช้กฎ
ควบคุมระดับ Subnet (เทียบกับ NACL): อาศัยการกำหนด Destination IP เป็น IP range ของ Subnet ที่ต้องการควบคุม

Go กับ Interface ฉบับรวบยอด

Perajit — Tue, 21 Apr 2026 01:27:11 +0000

Interface กับ OOP

จากบทความที่แล้ว เราทำ OOP ด้วยการผูก method ให้ struct ผ่าน receiver ทีนี้ถ้าเราอยากจัดการกับ struct หลายประเภทที่มีพฤติกรรมเหมือนกันในที่เดียวจะทำยังไง?

ปกติในภาษาอื่นเราก็จะสร้าง interface ขึ้นมา แล้วให้แต่ละ class implement interface นั้นใช่มั้ย? ใน Go ก็มี interface เหมือนกัน แต่สิ่งที่ต่างคือ ใน Go เป็น implicit interface ไม่ต้องมีการเขียนคีย์เวิร์ด implement เลย

เช่น เรามี Cat และ Dog ซึ่งทั้งคู่มี method ที่มี method signature เหมือนกันคือ Speaker()

type Cat struct { Name string }
func (c Cat) Speak() { fmt.Println(c.Name, "Meow!") }

type Dog struct { Name string }
func (d Dog) Speak() { fmt.Println(d.Name, "Woof!") }

เราสามารถสร้าง interface ได้แบบนี้

type Speaker interface {
  Speak()
}

โดย Cat และ Dog ของเราจะยังเหมือนเดิม ไม่มีแก้โค้ดใดๆ แต่ Go จะรู้เองว่ามันคือ Speaker เพราะว่า "satisfy interface"

และเราก็สามารถประกาศ slice ของ Speaker แล้วเก็บค่า Cat กับ Dog ไว้ด้วยกัน รวมถึงสามารถเรียก method ของ Speaker จาก slice ได้เลย

cat := Cat{Name: "Kitty"}
dog := Dog{Name: "Bo"}

// slice ของ Speaker เก็บได้ทั้ง cat และ dog ทันที
animals := []Speaker{cat, dog}

for _, a := range animals {
  // เรียก Speak() ของ Speaker ได้เลย
  a.Speak()
}

ไอเดียคือใช้การประกาศ interface จากฝั่ง consumer ตรงข้ามกับใน classic OOP ที่เวลาจะใช้ interface ต้องมีการผูกกันตั้งแต่ต้น ซึ่งการทำ interface แบบ Go มีข้อดีหลายอย่าง

ทำให้เราโฟกัสที่ behavior มากกว่า type
ยืดหยุ่น สามารถเอา library สองตัวจากคนละที่มาทำงานร่วมกันได้ทันทีถ้า method signature ตรงกัน
ไม่ผูกติดกับโค้ดต้นทาง ถ้าสนใจ method ไหนก็ประกาศ interface แค่นั้นพอ ซึ่งข้อนี้ทำให้การ mock (เช่น สำหรับ unit test) ง่ายขึ้นมาก

โครงสร้าง Interface

ภายใต้ตัวแปร interface จะเก็บค่า 2 อย่างเสมอ คือ type (ชนิดของข้อมูล) และ value (ค่าของข้อมูล) เพราะฉะนั้น interface จะเป็น nil ก็ต่อเมื่อทั้ง type และ value เป็น nil

เช่นจากตัวอย่างเดิม เรามี struct Cat และ interface Speaker

var c *Cat = nil
var i Speaker = c

// ตรวจสอบว่า i เป็น nil รึเปล่า
fmt.Println(i == nil)

จะได้ผลลัพธ์เป็น false

Empty Interface

interface ว่าง interface{} คือ interface ที่ไม่มีการกำหนด method อะไรไว้ ซึ่งหมายความว่าสามารถเป็น type อะไรก็ได้ (หรือก็คือ any ในเวอร์ชั่นใหม่ๆ ของ Go)

เรามักจะใช้ในกรณีที่ต้องการ Dynamic Type เช่น ใช้กับฟังก์ชั่นที่รับพารามิเตอร์อะไรก็ได้ หรือใช้กับโครงสร้างข้อมูลที่ dynamic เช่น map[string]interface{}

แต่ข้อควรระวังคือ เราจะไม่สามารถใช้ความสามารถของ type เดิมได้ ต้องแปลงค่ากลับมาก่อน เช่น

var x interface{} = 1

เราไม่สามารถสั่งแบบนี้ได้

sum := x + 5 // จะ error

เนื่องจากตอนนี้ x เป็น interface{} ไม่ใช่ int ต้องแปลงกลับเป็น int ก่อนถึงจะทำ operation ของ int ได้

sum := x.(int) + 5

ปัจจุบัน Go มี Generics ให้ใช้แล้ว แนะนำให้ใช้ Generics แทน interface{}

Go กับ OOP ฉบับเข้าใจง่าย (มั้ง)

Perajit — Tue, 21 Apr 2026 00:17:37 +0000

ออกตัวก่อนว่าไม่ได้เชี่ยวชาญ Go อะไรมากมาย แค่นึกไม่ออกว่าเขียนเรื่องอะไรดี แล้วเรื่องนี้ก็ผุดขึ้นมา

ใน Go สามารถทำ OOP ได้ แต่จะค่อนข้างต่างจากภาษาอื่นที่เคยเจอมา คือไม่มีสิ่งที่เรียกว่า class แต่จะใช้ struct ซึ่งเป็นการ define โครงสร้างข้อมูล เช่น

type Animal struct {
  Name string
  Weight int
}

เป็นการประกาศโครงสร้างของข้อมูลที่ประกอบด้วยฟิลด์ชื่อ Name และ Weight และเนื่องจากใน Go จะใส่ zero value ให้ค่าต่างๆ เสมอ ดังนั้นถ้าประกาศตัวแปรด้วย type ของ struct แต่ละ field ก็จะมีค่าเริ่มต้นเป็น zero value ของแต่ละชนิดข้อมูลโดยอัตโนมัติ ซึ่งก็คือทำหน้าที่เก็บข้อมูลได้เหมือน data class ในภาษาอื่นนั่นเอง

จากตัวอย่าง Animal ถ้าประกาศตัวแปรแบบนี้

cat := Animal{}

เราก็จะได้สิ่งที่เหมือนกับ instance ของ data class ที่มีค่า cat.Name = "" และ cat.Weight = 0

หรือจะกำหนดค่าเริ่มต้นลงไปตั้งแต่ตอนประกาศค่าก็ได้ เช่น

cat := Animal{Name: "Kitty", Weight: 2}

ก็จะได้ค่าตามที่กำหนดคือ cat.Name = "Kitty" และ cat.Weight = 2

Class with methods

ตอนนี้เราสามารถสร้างสิ่งที่เหมือนกับ class ที่มี property แล้ว แต่ว่าในโลกของ OOP เนี่ย class ไม่ได้มีแค่ property แต่ยังมี method ด้วยใช่มั้ย?

ใน Go เราสามารถสร้าง method ให้กับ struct ได้โดยไม่ได้เขียนลงใน struct เลย แต่ใช้การการผูกฟังก์ชั่นเข้าไปโต้งๆ ทีหลัง ซึ่งคำว่า "ผูกโต้งๆ" อาศัยสิ่งที่เรียกว่า receiver

ตัวอย่างเช่น เราจะเติม method Eat() ให้กับ Animal ได้แบบนี้

func(a *Animal) Eat() {
  a.Weight++
}

สังเกตว่ารูปแบบการเขียนฟังก์ชั่นจะมีบางอย่างเพิ่มเข้ามา คือ (a *Animal) สิ่งนี้แหละที่เรียกว่า receiver โดย a คือ receiver variable ส่วน *Animal เป็น receiver type สังเกตว่าจะไม่มีการใช้คีย์เวิร์ด this เหมือนภาษาอื่น แต่จะใช้ receiver อ้างอิงไปเลย

ลองเขียนโค้ดทดสอบดู

cat := Animal{Name: "Kitty", Weight: 2}
cat.Eat()
fmt.Printf("Weight: %v", a.Weight)

จะได้ค่า a.Weight = 3

แล้วทีนี้อยากให้มี method อีกสักกี่อันก็แค่เขียนฟังก์ชั่นโดยผูก receiver เข้าไป

ข้อดีของการเขียนลักษณะนี้คือทำให้สามารถเติม method เข้าไปได้โดย struct ไม่บวม (อยู่คนละไฟล์ได้) และการใช้ชื่อตัวแปร receiver แทน this ทำให้ refactor โค้ดจาก function ธรรมดามาเป็น method ได้ง่ายๆ โดยไม่ต้องแก้ชื่อตัวแปรเป็น this

เสริมอีกนิดว่า receiver มี 2 แบบคือ value receiver กับ pointer receiver สำหรับในตัวอย่างเราใช้ pointer receiver ซึ่งคือแบบนี้ (a *Animal) เพราะต้องการแก้ไขข้อมูล เวลาใช้ value receiver ซึ่งคือแบบนี้ (a Animal) เราจะไม่สามารถแก้ไขข้อมูลได้

เช่น ถ้าแก้โค้ดของ method Eat() เป็นแบบนี้

// การใช้ value receiver จะไม่สามารถแก้ไขข้อมูลได้
func(a Animal) Eat {
  a.Weight++
}

ผลที่ได้คือคือค่าของ a.Weight จะไม่เปลี่ยน

Inheritance (หรือจริงๆ คือ Composition)

การ "สืบทอด" ใน Go ก็แตกต่างจากภาษาอื่นที่ใช้คีย์เวิร์ด extends แต่ Go ออกแบบมาให้ "Composition over Inheritance" จึงใช้การ "ฝัง" (embedding) struct ซ้อนเข้าไปข้างใน เช่น

type Cat struct {
  Animal
  SlaveName string
}
func(c *Cat) Meow() {
  fmt.Println("Meow")
}

เราจะได้ Cat ที่มี property และ method ของ Animal ติดมาด้วยทันที
ทดสอบด้วยการเขียนโค้ดตามด้านล่างนี้

cat := Cat{}
cat.Eat()
fmt.Printf("Name: %v, Weight: %v, SlaveName: %v", cat.Name, cat.Weight, cat.SlaveName)

โค้ดจะไม่พัง และจะได้ผลลัพธ์เป็น Name:, Weight:1, SlaveName:

Name เป็นสตริงว่าง จาก zero value
Weight เป็น 1 เนื่องจากมีการสั่ง cat.Eat() ทำการเพิ่มค่าจาก zero value ครั้งนึง
SlaveName เป็นสตริงว่างจาก zero value

แล้วถ้าเกิดเราต้องการใส่ค่าเริ่มต้นให้กับ cat ล่ะ? ในเมื่อเราสามารถเรียก property ที่มาจาก Animal ได้ตรงๆ งั้นเราลองใส่ Weight เป็น 2 ให้กับ cat ดูหน่อย

cat := Cat{Weight: 2, SlaveName: "Jack"}

ปรากฏว่าเขียนแบบนี้จะเจอ syntax error…

นี่เป็นเรื่องที่เราเจอตอนลองเขียนครั้งแรก แล้วก็งงว่าจะใส่ค่าเริ่มต้นให้มันได้ยังไง แล้วก็ค้นพบว่า วิธีที่ถูกต้องคือ ต้องระบุชื่อ struct ที่ embed มาด้วย!

เนื่องจากตอนประกาศ struct เราใส่ Animal เข้าไป ตอนเซ็ตค่าเริ่มต้นเราก็ต้องระบุ Animal เหมือนกัน แบบนี้

cat := Cat{Animal: Animal{Weight: 2}, SlaveName: "Jack"}

ทีนี้ถ้าลองสั่ง

cat.Eat()
fmt.Printf("Name: %v, Weight: %v, SlaveName: %v", cat.Name, cat.Weight, cat.SlaveName)

เราจะได้ผลลัพธ์ Name:, Weight:3, SlaveName:Jack

Name ยังเป็นสตริงว่างเพราะไม่ได้กำหนดค่า
Weight เป็น 3 เนื่องจากค่าเริ่มต้นถูกเซ็ตเป็น 2
SlaveName ได้ค่า Jack ที่เซ็ตเข้าไป

ตอนที่ดึงค่าออกมาจาก field หรือเรียก method สามารถเรียกได้เลยตรงๆ แต่ตอนประกาศค่าต้องระบุชื่อ struct ที่ embed มาเสมอ

สำหรับ OOP ใน Go คร่าวๆ ก็ประมาณนี้ค่ะ