04 thg 10, 2025·8 phút
Cách Scala kết hợp lập trình hàm và hướng đối tượng trên JVM
Tìm hiểu vì sao Scala được thiết kế để hội tụ ý tưởng lập trình hàm và hướng đối tượng trên JVM, những điểm làm tốt, và các đánh đổi mà đội cần biết.
Tìm hiểu vì sao Scala được thiết kế để hội tụ ý tưởng lập trình hàm và hướng đối tượng trên JVM, những điểm làm tốt, và các đánh đổi mà đội cần biết.
Java làm nên thành công cho JVM, nhưng cũng tạo ra những kỳ vọng mà nhiều nhóm cuối cùng gặp phải: nhiều boilerplate, nhấn mạnh trạng thái có thể thay đổi, và các mẫu thường cần framework hoặc sinh mã để giữ cho mọi thứ có thể quản lý. Developer thích hiệu năng, công cụ và câu chuyện triển khai của JVM — nhưng họ muốn một ngôn ngữ cho phép biểu đạt ý tưởng trực tiếp hơn.
Vào đầu những năm 2000, công việc hàng ngày trên JVM thường liên quan tới các hệ lớp verbose, nghi thức getter/setter và lỗi liên quan tới null lọt vào production. Viết chương trình đồng thời là khả thi, nhưng trạng thái chia sẻ có thể thay đổi khiến các race condition tinh vi dễ phát sinh. Ngay cả khi các đội tuân theo thiết kế hướng đối tượng tốt, code hàng ngày vẫn mang nhiều độ phức tạp vô tình.
Scala đặt cược rằng một ngôn ngữ tốt hơn có thể giảm ma sát đó mà không bỏ JVM: giữ hiệu năng “đủ tốt” bằng cách biên dịch sang bytecode, nhưng cung cấp cho developer các tính năng giúp họ mô tả miền rõ ràng và xây dựng hệ thống dễ thay đổi hơn.
Hầu hết các đội JVM không chọn giữa “thuần functional” và “thuần hướng đối tượng” — họ cố gắng giao phần mềm theo tiến độ. Scala hướng tới để bạn dùng OO nơi nó phù hợp (đóng gói, API module, ranh giới dịch vụ) trong khi dựa vào ý tưởng chức năng (bất biến, code theo biểu thức, các phép biến đổi có thể ghép) để làm chương trình an toàn hơn và dễ suy luận hơn.
Sự pha trộn đó phản ánh cách hệ thống thực tế thường được xây: ranh giới hướng đối tượng xung quanh module và dịch vụ, với kỹ thuật chức năng bên trong các module để giảm lỗi và đơn giản hóa kiểm thử.
Scala muốn cung cấp kiểu tĩnh mạnh hơn, khả năng composition và tái sử dụng tốt hơn, cùng công cụ ngôn ngữ giảm boilerplate — tất cả trong khi vẫn tương thích với thư viện và hoạt động JVM.
Martin Odersky thiết kế Scala sau khi làm việc trên generics của Java và thấy điểm mạnh ở các ngôn ngữ như ML, Haskell và Smalltalk. Cộng đồng quanh Scala — học thuật, đội enterprise JVM, và sau này là data engineering — đã góp phần định hình nó thành một ngôn ngữ cố gắng cân bằng lý thuyết với nhu cầu production.
Scala cực kỳ coi trọng cụm từ “mọi thứ là một đối tượng”. Những giá trị bạn nghĩ là “nguyên thủy” trong ngôn ngữ JVM khác — như 1, true hay 'a' — hành xử như đối tượng bình thường có phương thức. Điều đó nghĩa là bạn có thể viết 1.toString hay 'a'.isLetter mà không phải đổi chế độ tư duy giữa “phép toán nguyên thủy” và “phép toán đối tượng”.
Nếu bạn quen với mô hình Java, bề mặt OO của Scala ngay lập tức dễ nhận ra: bạn định nghĩa class, tạo instance, gọi method, và nhóm hành vi bằng các kiểu giống interface.
Bạn có thể mô hình một miền theo cách trực tiếp:
class User(val name: String) {
def greet(): String = s"Hi, $name"
}
val u = new User("Sam")
println(u.greet())
Sự quen thuộc này quan trọng trên JVM: các đội có thể áp dụng Scala mà không bỏ cách tư duy “đối tượng có phương thức”.
Mô hình đối tượng của Scala đồng nhất và linh hoạt hơn Java:
object Config { ... }), thường thay cho các pattern static trong Java.val/var, giảm boilerplate.Kế thừa vẫn tồn tại và thường được dùng, nhưng nhẹ hơn:
class Admin(name: String) extends User(name) {
override def greet(): String = s"Welcome, $name"
}
Trong công việc hàng ngày, điều này nghĩa là Scala hỗ trợ các khối xây dựng OO mà mọi người cần — class, đóng gói, override — trong khi xóa đi vài điểm gượng của thời JVM (như dùng static quá nhiều và getter/setter verbose).
Mặt chức năng của Scala không phải là một “chế độ” riêng biệt — nó hiện diện ở các mặc định hàng ngày mà ngôn ngữ khuyến khích. Hai ý tưởng dẫn dắt phần lớn: ưu tiên dữ liệu bất biến, và coi code là các biểu thức tạo ra giá trị.
val vs var)Trong Scala, bạn khai báo giá trị với val và biến với var. Cả hai tồn tại, nhưng mặc định văn hoá là val.
Khi dùng val, bạn nói: “tham chiếu này sẽ không bị gán lại.” Lựa chọn nhỏ đó giảm lượng trạng thái ẩn trong chương trình. Ít trạng thái hơn nghĩa là ít bất ngờ hơn khi code lớn lên, đặc biệt trong các workflow nghiệp vụ nhiều bước nơi giá trị được biến đổi nhiều lần.
var vẫn có chỗ — glue trong UI, bộ đếm, hoặc vùng cần tối ưu hiệu năng — nhưng việc dùng nó nên có chủ ý thay vì mặc định.
Scala khuyến khích viết code như các biểu thức trả về kết quả, thay vì chuỗi các câu lệnh chủ yếu làm thay đổi trạng thái.
Điều đó thường trông như xây dựng một kết quả từ các kết quả nhỏ hơn:
val discounted =
if (isVip) price * 0.9
else price
Ở đây, if là một biểu thức, nên nó trả về một giá trị. Phong cách này giúp dễ xác định “giá trị này là gì?” mà không cần truy vết một chuỗi gán.
map/filter)Thay vì vòng lặp sửa collection, code Scala thường biến đổi dữ liệu:
val emails = users
.filter(_.isActive)
.map(_.email)
filter và map là hàm bậc cao: chúng nhận hàm khác làm đầu vào. Lợi ích không phải chỉ ở lý thuyết — đó là rõ ràng. Bạn có thể đọc pipeline như một câu chuyện nhỏ: giữ user active, rồi lấy email.
Hàm tinh khiết chỉ phụ thuộc vào đầu vào và không có side effect (không ghi ẩn, không I/O). Khi nhiều code hơn là tinh khiết, kiểm thử trở nên đơn giản: đưa input, khẳng định output. Suy luận cũng dễ hơn vì bạn không cần đoán còn gì bị thay đổi ở nơi khác trong hệ thống.
Câu trả lời của Scala cho “chia sẻ hành vi mà không xây cây lớp lớn?” là trait. Trait giống như interface nhưng có thể mang phần triển khai — phương thức, field, và logic trợ giúp nhỏ.
Traits cho phép mô tả một khả năng (“có thể log”, “có thể validate”, “có thể cache”) rồi đính khả năng đó vào nhiều class khác nhau. Điều này khuyến khích các khối nhỏ, tập trung thay vì vài base class khổng lồ mà mọi người phải kế thừa.
Không giống như kế thừa đơn, trait được thiết kế cho đa kế thừa hành vi theo cách có kiểm soát. Bạn có thể thêm hơn một trait vào một class, và Scala định nghĩa thứ tự linearization rõ ràng cho cách phương thức được giải quyết.
Khi bạn “mix in” trait, bạn đang ghép hành vi ở ranh giới lớp thay vì khoan sâu vào inheritance. Điều đó thường dễ bảo trì hơn:
Ví dụ đơn giản:
trait Timestamped { def now(): Long = System.currentTimeMillis() }
trait ConsoleLogging { def log(msg: String): Unit = println(msg) }
class Service extends Timestamped with ConsoleLogging {
def handle(): Unit = log(s"Handled at ${now()}")
}
Dùng trait khi:
Dùng abstract class khi:
Lợi ích thực sự là Scala làm cho tái sử dụng giống ghép các bộ phận hơn là thừa hưởng định mệnh.
Pattern matching là một trong những tính năng khiến ngôn ngữ có cảm giác mạnh mẽ “chức năng”, mặc dù vẫn hỗ trợ thiết kế hướng đối tượng cổ điển. Thay vì dồn logic vào một mạng lưới phương thức ảo, bạn có thể kiểm tra một giá trị và chọn hành vi dựa trên cấu trúc của nó.
Ở mức đơn giản, pattern matching là một switch mạnh hơn: nó có thể khớp trên hằng số, kiểu, cấu trúc lồng nhau, và thậm chí gán các phần của giá trị cho tên. Vì nó là một biểu thức, nó tự nhiên sinh ra một kết quả — thường dẫn tới code ngắn gọn, dễ đọc.
sealed trait Payment
case class Card(last4: String) extends Payment
case object Cash extends Payment
def describe(p: Payment): String = p match {
case Card(last4) => s"Card ending $last4"
case Cash => "Cash"
}
Ví dụ trên cũng cho thấy một ADT theo phong cách Scala:
sealed trait định nghĩa một tập hợp khả thi đóng.case class và case object định nghĩa các biến thể cụ thể.“Sealed” là chìa khoá: compiler biết tất cả các subtype hợp lệ (trong cùng file), điều này mở ra pattern matching an toàn hơn.
ADT khuyến khích bạn mô tả trạng thái thực của miền. Thay vì dùng null, chuỗi ma thuật, hay boolean có thể kết hợp thành các trạng thái vô lý, bạn định nghĩa các trường hợp được phép rõ ràng. Điều đó khiến nhiều lỗi không thể biểu diễn trong mã — và vì thế không thể chạy vào production.
Pattern matching tỏa sáng khi bạn:
Nó có thể bị lạm dụng khi mọi hành vi đều được thể hiện dưới dạng các khối match lớn rải rác trong codebase. Nếu match phình to hoặc xuất hiện khắp nơi, đó thường là dấu bạn cần tách thành hàm trợ giúp hoặc chuyển một số hành vi gần hơn với kiểu dữ liệu.
Hệ thống kiểu của Scala là một trong những lý do lớn khiến các đội chọn nó — và cũng là một trong những lý do khiến một số đội bỏ cuộc. Ở trạng thái tốt nhất, nó cho phép bạn viết code ngắn gọn mà vẫn có kiểm tra mạnh lúc biên dịch. Ở trạng thái tồi tệ nhất, bạn có cảm giác đang debug compiler.
Type inference nghĩa là bạn thường không phải khai báo kiểu ở khắp nơi. Compiler thường tự suy ra từ ngữ cảnh.
Điều này giảm boilerplate: bạn tập trung vào ý nghĩa của giá trị hơn là liên tục chú thích kiểu. Khi bạn điền chú thích kiểu, thường là để làm rõ ý định ở ranh giới (API public, generic phức tạp) hơn là cho mọi biến cục bộ.
Generics cho phép viết container và utility dùng cho nhiều kiểu (như List[Int] và List[String]). Variance liên quan tới việc một kiểu generic có thể thay thế khi tham số kiểu thay đổi hay không.
+A) xấp xỉ nghĩa là “một list mèo có thể dùng nơi list động vật được mong đợi”.-A) xấp xỉ nghĩa là “một handler động vật có thể dùng nơi handler mèo được mong đợi”.Điều này mạnh cho thiết kế thư viện, nhưng có thể gây bối rối khi gặp lần đầu.
Scala phổ biến một mẫu nơi bạn có thể “thêm hành vi” cho kiểu mà không sửa nó, bằng cách truyền các năng lực một cách ngầm. Ví dụ, bạn có thể định nghĩa cách so sánh hoặc in một kiểu và logic đó sẽ được chọn tự động.
Trong Scala 2 dùng implicit; trong Scala 3 biểu đạt rõ ràng hơn với given/using. Ý tưởng giống nhau: mở rộng hành vi theo cách có thể kết hợp.
Đổi lại là độ phức tạp. Các mánh type-level có thể tạo ra thông báo lỗi dài, và code trừu tượng hóa quá mức khó đọc với người mới. Nhiều đội áp dụng nguyên tắc: dùng hệ thống kiểu để đơn giản hóa API và ngăn lỗi, nhưng tránh thiết kế yêu cầu mọi người suy nghĩ như compiler để thay đổi.
Scala có nhiều “làn” để viết code đồng thời. Điều đó hữu ích — vì không phải vấn đề nào cũng cần cùng mức máy móc — nhưng cũng nghĩa là các đội cần có chủ ý về cái họ chọn.
Với nhiều app JVM, Future là cách đơn giản nhất để chạy công việc đồng thời và ghép kết quả. Bạn khởi công việc, rồi dùng map/flatMap để xây workflow bất đồng bộ mà không chặn thread.
Mô hình tư duy tốt: Futures phù hợp cho tác vụ độc lập (gọi API, truy vấn DB, tính nền) nơi bạn muốn kết hợp kết quả và xử lý lỗi ở một nơi.
Scala cho phép biểu đạt chuỗi Future theo phong cách tuyến tính hơn (qua for-comprehensions). Điều này không thêm primitive đồng thời mới, nhưng làm ý định rõ ràng hơn và giảm nesting callback.
Đổi lại: vẫn dễ vô tình block (ví dụ chờ Future) hoặc làm quá tải execution context nếu bạn không tách rõ công việc CPU-bound và IO-bound.
Cho pipeline chạy lâu — sự kiện, log, xử lý dữ liệu — thư viện streaming (Akka/Pekko Streams, FS2, hoặc tương tự) tập trung vào flow control. Tính năng chính là backpressure: producer chậm lại khi consumer không bắt kịp.
Mô hình này thường thắng “chỉ spawn thêm Futures” vì nó xử lý throughput và bộ nhớ như các mối quan tâm hàng đầu.
Thư viện actor (Akka/Pekko) mô hình hoá đồng thời như các thành phần độc lập giao tiếp qua tin nhắn. Điều này có thể đơn giản hoá suy luận về trạng thái, vì mỗi actor xử lý một tin nhắn tại một thời điểm.
Actors tỏa sáng khi bạn cần các tiến trình trạng thái lâu dài (thiết bị, session, coordinator). Chúng có thể quá tải cho app request/response đơn giản.
Cấu trúc dữ liệu bất biến giảm trạng thái chia sẻ có thể thay đổi — nguồn nhiều race condition. Ngay cả khi dùng thread, Futures hay actors, truyền giá trị bất biến làm lỗi đồng thời ít xảy ra và dễ debug hơn.
Bắt đầu với Futures cho công việc song song đơn giản. Chuyển sang streaming khi cần kiểm soát throughput, và cân nhắc actors khi trạng thái và phối hợp thống trị thiết kế.
Lợi thế thực dụng lớn nhất của Scala là nó sống trên JVM và có thể dùng trực tiếp hệ sinh thái Java. Bạn có thể khởi tạo lớp Java, implement interface Java, và gọi method Java với ít nghi thức — thường cảm giác như đang dùng thư viện Scala khác.
Hầu hết interop “đường vui” rất thẳng:
Dưới hood, Scala biên dịch sang bytecode JVM. Về mặt vận hành, nó chạy như các ngôn ngữ JVM khác: cùng runtime, cùng GC, và được profiling/monitor với công cụ quen thuộc.
Ma sát xuất hiện khi mặc định của Scala không khớp với Java:
Null. Nhiều API Java trả null; Scala thích Option. Bạn thường bọc kết quả Java phòng ngừa để tránh NullPointerException bất ngờ.
Checked exceptions. Scala không bắt bạn khai báo hoặc catch checked exceptions, nhưng thư viện Java có thể ném chúng. Điều này làm xử lý lỗi cảm giác không nhất quán trừ khi bạn chuẩn hoá cách dịch ngoại lệ.
Mutability. Collection Java và API nặng setter khuyến khích mutation. Trong Scala, trộn lẫn mutable và immutable có thể dẫn tới code khó hiểu, đặc biệt ở biên API.
Đối xử ranh giới như lớp dịch:
Option ngay; chỉ chuyển Option về null ở biên.Làm tốt, interop khiến đội Scala đi nhanh hơn bằng cách tái dùng thư viện JVM đã được kiểm chứng trong khi giữ code Scala biểu đạt và an toàn bên trong dịch vụ.
Lời hứa của Scala rất hấp dẫn: bạn có thể viết code chức năng tinh tế, giữ cấu trúc OO khi cần, và ở lại JVM. Thực tế, đội không chỉ “chọn Scala” — họ trải nghiệm một tập các đánh đổi hàng ngày xuất hiện trong onboarding, build và code review.
Scala trao cho bạn nhiều quyền biểu đạt: nhiều cách mô tả dữ liệu, nhiều cách trừu tượng hoá hành vi, nhiều cách cấu trúc API. Sự linh hoạt đó sinh lợi khi bạn chia sẻ mô hình tư duy — nhưng ban đầu có thể làm chậm đội.
Người mới có thể không gặp vấn đề với cú pháp mà gặp với lựa chọn: “Cái này nên là case class, class thường, hay ADT?” “Chúng ta dùng inheritance, trait, type class hay chỉ là function?” Vấn đề khó không phải Scala không thể học — mà là đồng ý với nhau về cái gọi là “Scala bình thường”.
Biên dịch Scala nặng hơn nhiều đội dự kiến, đặc biệt khi project lớn hoặc dùng thư viện nặng macro (phổ biến ở Scala 2). Build incremental có thể giúp, nhưng thời gian biên dịch vẫn là mối quan tâm thực tế: CI chậm hơn, vòng phản hồi lâu hơn, và áp lực giữ module nhỏ và dependency gọn.
Công cụ build thêm một lớp nữa. Dù bạn dùng sbt hay hệ thống khác, cần chú ý cache, song song và cách chia project thành submodule. Đây không phải vấn đề lý thuyết — chúng ảnh hưởng tới hạnh phúc developer và tốc độ sửa lỗi.
Tooling Scala đã tiến bộ, nhưng vẫn đáng thử với stack cụ thể của bạn. Trước khi chuẩn hoá, các đội nên đánh giá:
Nếu IDE vật trở, tính biểu đạt của ngôn ngữ có thể phản tác dụng: code "đúng" nhưng khó khám phá trở nên tốn kém để duy trì.
Vì Scala hỗ trợ FP và OOP (và nhiều hybrid), codebase có thể thành một tập hợp phong cách khác nhau. Đó thường là nơi nảy sinh thất vọng: không phải vì Scala, mà vì conventions không đồng bộ.
Conventions và linter quan trọng vì giảm tranh luận. Quyết định trước “Scala tốt” nghĩa là gì cho đội — cách xử lý bất biến, xử lý lỗi, đặt tên, và khi nào dùng các pattern type-level — sẽ làm onboarding mượt hơn và giữ review tập trung vào hành vi hơn là thẩm mỹ.
Scala 3 (thường gọi là “Dotty” khi phát triển) không phải là viết lại bản sắc Scala — nó cố gắng giữ cái cân giữa FP/OOP trong khi làm mượt những cạnh sắc mà đội gặp ở Scala 2.
Scala 3 giữ các nền tảng quen thuộc, nhưng khuyến khích cấu trúc rõ ràng hơn.
Bạn sẽ thấy optional braces với indentation có ý nghĩa, khiến code hàng ngày đọc giống ngôn ngữ hiện đại hơn và bớt giống một DSL dày đặc. Nó cũng chuẩn hóa vài pattern từng “có thể làm nhưng lộn xộn” trong Scala 2 — như thêm phương thức qua extension thay vì một mớ implicit.
Về triết lý, Scala 3 cố gắng làm các tính năng mạnh mẽ rõ ràng hơn, để người đọc biết điều gì đang xảy ra mà không phải nhớ hàng loạt quy ước.
Implicits của Scala 2 rất linh hoạt: tốt cho typeclass và dependency injection, nhưng cũng là nguồn lỗi biên dịch khó hiểu và “hành động từ xa”.
Scala 3 thay thế hầu hết implicit bằng given/using. Khả năng tương tự, nhưng ý định rõ hơn: “đây là một instance được cung cấp” (given) và “phương thức này cần một instance” (using). Điều đó cải thiện tính dễ đọc và khiến pattern typeclass theo phong cách FP dễ theo dõi hơn.
Enums cũng quan trọng. Nhiều đội Scala 2 dùng sealed trait + case object/class để mô hình ADT. enum của Scala 3 cho bạn pattern đó với cú pháp gọn gàng hơn — ít boilerplate, cùng sức mạnh mô hình.
Hầu hết dự án di chuyển bằng cách cross-build (xuất artifact cho Scala 2 và Scala 3) và chuyển module từng bước.
Công cụ hỗ trợ, nhưng vẫn mất công: không tương thích nguồn (nhất là liên quan implicits), thư viện nặng macro, và tooling build có thể làm chậm. Tin tốt là code nghiệp vụ thông thường port sạch hơn code lạm dụng magie compiler.
Trong code hàng ngày, Scala 3 làm các pattern FP cảm nhận là “first-class” hơn: wiring typeclass rõ ràng hơn, ADT gọn hơn với enum, và công cụ kiểu mạnh (như union/intersection) mà không quá nhiều nghi thức.
Đồng thời, nó không bỏ OO — trait, class và mixin vẫn trung tâm. Khác biệt là Scala 3 làm ranh giới giữa “cấu trúc OO” và “trừu tượng FP” dễ thấy hơn, điều này thường giúp các đội giữ codebase nhất quán theo thời gian.
Scala có thể là một “công cụ mạnh” tốt trên JVM — nhưng không phải lựa chọn mặc định cho mọi trường hợp. Lợi ích lớn nhất xuất hiện khi bài toán hưởng lợi từ mô hình mạnh và composition an toàn, và khi đội sẵn sàng dùng ngôn ngữ có chủ ý.
Hệ thống và pipeline xử lý dữ liệu. Nếu bạn biến đổi, validate và enrich nhiều dữ liệu (stream, ETL, event processing), phong cách chức năng và kiểu mạnh của Scala giúp giữ các phép biến đổi rõ ràng và ít lỗi.
Mô hình miền phức tạp. Khi quy tắc nghiệp vụ tinh vi — giá, rủi ro, điều kiện hợp lệ, permission — khả năng diễn đạt ràng buộc trong kiểu và xây các phần nhỏ, có thể ghép giúp giảm “if-else bùng nổ” và làm trạng thái không hợp lệ khó biểu diễn.
Tổ chức đã đầu tư vào JVM. Nếu hệ thống của bạn đã phụ thuộc thư viện Java, tooling JVM và quy trình vận hành, Scala mang lại ergonomics phong cách FP mà không rời khỏi hệ sinh thái đó.
Scala thưởng cho tính nhất quán. Đội thường thành công khi có:
Không có những điều này, codebase dễ drift thành một hỗn hợp phong cách khó theo dõi cho người mới.
Đội nhỏ cần onboarding nhanh. Nếu bạn mong nhiều thay đổi nhân sự, nhiều contributor junior hoặc chuyển giao nhanh, độ dốc học tập và đa dạng idiom có thể làm chậm.
Ứng dụng CRUD đơn giản. Với dịch vụ “request in / record out” đơn giản, lợi ích Scala có thể không bù đắp chi phí tooling, thời gian biên dịch và quyết định style.
Hỏi:
Nếu đa số trả lời “có”, Scala thường phù hợp. Nếu không, một ngôn ngữ JVM đơn giản hơn có thể đem lại kết quả nhanh hơn.
Một mẹo thực tế khi đánh giá ngôn ngữ: giữ vòng prototype ngắn. Ví dụ, các đội đôi khi dùng nền tảng vibe-coding như Koder.ai để dựng một app tham chiếu nhỏ (API + database + UI) từ một đặc tả chat, lặp trong giai đoạn planning, và dùng snapshots/rollback để thử các phương án nhanh. Ngay cả khi mục tiêu production là Scala, có một prototype nhanh bạn có thể xuất mã nguồn và so sánh với triển khai JVM giúp cuộc hội thoại “chọn Scala?” cụ thể hơn — dựa trên workflow, triển khai và khả năng bảo trì chứ không chỉ tính năng ngôn ngữ.
Scala được thiết kế để giảm bớt các điểm đau phổ biến trên JVM — boilerplate, lỗi liên quan đến null và các thiết kế kế thừa dễ gãy — trong khi vẫn giữ hiệu năng, công cụ và truy cập thư viện của JVM. Mục tiêu là biểu đạt logic miền rõ ràng hơn mà không rời khỏi hệ sinh thái Java.
Dùng OOP để định nghĩa ranh giới module rõ ràng (API, đóng gói, giao diện dịch vụ), và dùng kỹ thuật FP bên trong những ranh giới đó (bất biến, code theo biểu thức, hàm gần như tinh khiết) để giảm trạng thái ẩn và làm cho hành vi dễ kiểm thử và thay đổi hơn.
Ưu tiên val theo mặc định để tránh gán lại vô ý và giảm trạng thái ẩn. Dùng var một cách có chủ ý ở những chỗ nhỏ, cục bộ (ví dụ: vòng lặp hiệu năng, glue UI), và giữ mutation ra khỏi logic nghiệp vụ chính khi có thể.
Traits là các “khả năng” có thể tái sử dụng để mix vào nhiều lớp khác nhau, thường tránh được các cây kế thừa sâu và mong manh.
Mô hình hoá tập hợp trạng thái đóng bằng sealed trait cộng với case class/case object, rồi dùng match để xử lý từng trường hợp.
Điều này khiến các trạng thái không hợp lệ khó biểu diễn và cho phép refactor an toàn hơn vì trình biên dịch có thể cảnh báo khi một trường hợp mới chưa được xử lý.
Type inference loại bỏ những chú thích lặp đi lặp lại để code ngắn gọn hơn nhưng vẫn được kiểm tra kiểu.
Thực hành phổ biến là thêm kiểu rõ ràng ở các ranh giới (phương thức public, API module, generic phức tạp) để cải thiện dễ hiểu và ổn định lỗi biên dịch mà không cần chú thích mọi biến cục bộ.
Variance mô tả cách subtyping hoạt động cho các kiểu generic.
+A): một container có thể được "mở rộng" (ví dụ dùng nơi được mong đợi).Chúng là cơ chế đằng sau kiểu kiểu-class (type-class) và cho phép thêm hành vi cho kiểu mà không sửa đổi nó:
implicitgiven / usingScala 3 làm ý định rõ ràng hơn (cái gì được cung cấp vs cái gì cần), thường cải thiện tính dễ đọc và giảm "hành động từ xa".
Bắt đầu đơn giản và chỉ nâng cấp khi cần:
Trong mọi trường hợp, truyền dữ liệu bất biến giúp tránh các điều kiện race.
Đối xử biên Java/Scala như lớp dịch:
null của Java thành Option ngay lập tức (và chỉ chuyển lại về null ở rìa).\n- Chuyển collection Java thành kiểu collection Scala mà đội bạn dùng.\n- Chuẩn hóa ngoại lệ Java thành một mô hình lỗi nhất quán.\n- Giữ API hướng Java đơn giản; API nội bộ Scala thì idiomatic.Điều này giữ cho interop có thể dự đoán và ngăn các mặc định Java (null, mutation) lan tràn khắp nơi.
List[Cat]List[Animal]-A): một consumer/handler có thể được mở rộng (ví dụ Handler[Animal] dùng nơi Handler[Cat] được mong đợi).Bạn sẽ gặp điều này rõ nhất khi thiết kế thư viện hoặc API nhận/trả kiểu generic.