Week 2 | Lesson 8
SOLID Principles, Design for Testability, Dependency Injection, Application Architecture, Functional Programming, Design Patterns
These principles are not specific to Java, but they are applicable to any object-oriented language.
The SOLID principle is an acronym for the following:
We have seen this principle applied when we talked about encapsulation. Also, you will find that if this principle is applied correctly, your code will be much easier to test.
We have already seen the Liskov principle applied when we worked with inheritance, abstract classes and interfaces.
Imagine you have a class that represents a printer. You could have the class implement one interface with methods print(), scan(), etc.
interface Printer {
fun print()
fun scan()
}
class SimplePrinter : Printer { /* ... */ }
class MultiPrinter : Printer { /* ... */ }Or you could have the class implement multiple interfaces, each with a single method.
interface Printing {
fun print()
}
interface Scanning {
fun scan()
}
class SimplePrinter : Printing { /* ... */ }
class MultiPrinter : Printing, Scanning { /* ... */ }This way, SimplePrinter only implements the interface it needs, and MultiPrinter implements both interfaces as required.
This is commonly demonstrated when working with collections. We will also see how this is helpful once we start developing applications using Inversion of Control.
This allows the higher-level and lower-level components to focus on their functionalities, promotes better decoupling, more flexibility, and easier maintenance.
There are three types of dependency injection:
fun main() {
val car = Car()
car.start()
car.stop()
}interface Engine {
fun on()
fun off()
}class ElectricEngine : Engine {
override fun on() {
println("Electric engine is on")
}
override fun off() {
println("Electric engine is off")
}
}class Car {
// engine dependency is tightly coupled with Car class
private val engine = ElectricEngine()
fun start() {
engine.on()
}
fun stop() {
engine.off()
}
}fun main() {
// First, we need to create an instance of the dependency
val engine: Engine = ElectricEngine()
// Then we inject the dependency via constructor
val car = Car(engine)
car.start()
car.stop()
}interface Engine {
fun on()
fun off()
}class ElectricEngine : Engine {
override fun on() {
println("Electric engine is on")
}
override fun off() {
println("Electric engine is off")
}
}// dependency is injected via constructor
class Car(private val engine: Engine) {
fun start() {
engine.on()
}
fun stop() {
engine.off()
}
}fun main() {
// First, we need to create an instance of the dependency
val engine: Engine = ElectricEngine()
// Then we create an instance of the class that has the dependency
val car = Car()
// Then we inject the dependency via setter
car.setEngine(engine)
car.start()
car.stop()
}interface Engine {
fun on()
fun off()
}class ElectricEngine : Engine {
override fun on() {
println("Electric engine is on")
}
override fun off() {
println("Electric engine is off")
}
}class Car {
private lateinit var engine: Engine
// dependency is injected via setter
fun setEngine(engine: Engine) {
this.engine = engine
}
fun start() {
engine.on()
}
fun stop() {
engine.off()
}
}Application frameworks usually provide such injector for us.
This is just a conceptual example!
@Component
class NotificationApplication(
private var service: MessageService
) {
fun sendNotifications(msg: String, rec: String) {
service.sendMessage(msg, rec)
}
}interface MessageService {
fun sendMessage(msg: String, rec: String)
}@Service
class EmailService : MessageService {
override fun sendMessage(msg: String, rec: String) {
// Logic to send email
println("Email sent to " + rec + " with Message=" + msg)
}
}As a simplification, we can divide design patterns into 3 categories ...
I will not go into detail, but I encourage you to read about them.
The Singleton pattern restricts the instantiation of a class to a single instance. This is useful when exactly one object is needed to coordinate actions across the system.
In Kotlin, the Singleton pattern can be easily implemented using the object declaration, which automatically ensures that only one instance of the object exists.
When to use:
Pros & Cons:
object DatabaseConnection {
private var connectionCount = 0
fun connect() {
connectionCount++
println("Database connected. Total connections: $connectionCount")
}
fun getConnectionCount() = connectionCount
}
fun main() {
DatabaseConnection.connect()
DatabaseConnection.connect()
println("Count: ${DatabaseConnection.getConnectionCount()}")
}Create a singleton Logger object that centralizes application logging.
Requirements:
Loggerlogs to store log messagesfun info(message: String) - adds "[INFO] message" to logsfun error(message: String) - adds "[ERROR] message" to logsfun getAllLogs(): List<String> - returns all logged messagesfun getErrorCount(): Int - counts error messagesPlayground is on the next slide ↓
Playground:
object Logger {
// TODO: Add your code
}
fun main() {
Logger.info("Application started")
Logger.info("User logged in")
Logger.error("Failed to load data")
Logger.info("Processing request")
Logger.error("Network timeout")
println("All logs:")
Logger.getAllLogs().forEach { println(it) }
println("\nTotal errors: ${Logger.getErrorCount()}")
}Expected Output:
All logs: [INFO] Application started [INFO] User logged in [ERROR] Failed to load data [INFO] Processing request [ERROR] Network timeout Total errors: 2
The Factory pattern provides a way to create objects without specifying their exact class. It encapsulates object creation logic and makes the code more flexible and maintainable.
When to use:
Pros & Cons:
interface Transport {
fun deliver(destination: String)
}
class Truck : Transport {
override fun deliver(destination: String) =
println("Delivering by truck to $destination")
}
class Ship : Transport {
override fun deliver(destination: String) =
println("Delivering by ship to $destination")
}
object TransportFactory {
fun createTransport(type: String): Transport = when(type) {
"land" -> Truck()
"sea" -> Ship()
else -> throw IllegalArgumentException("Unknown type")
}
}
fun main() {
val transport1 = TransportFactory.createTransport("land")
transport1.deliver("New York")
val transport2 = TransportFactory.createTransport("sea")
transport2.deliver("London")
}The following code has hardcoded instantiation logic. Refactor it using the Factory pattern.
Requirements:
PaymentFactory objectfun create(type: String): Payment methodcheckout function to use the factoryBenefits of your refactoring:
checkout function no longer knows about concrete payment classescheckoutPlayground is on the next slide ↓
interface Payment {
fun processPayment(amount: Double)
}
class CreditCard : Payment {
override fun processPayment(amount: Double) =
println("Processing credit card payment: $$amount")
}
class PayPal : Payment {
override fun processPayment(amount: Double) =
println("Processing PayPal payment: $$amount")
}
class Bitcoin : Payment {
override fun processPayment(amount: Double) =
println("Processing Bitcoin payment: $$amount")
}
fun checkout(paymentType: String, amount: Double) {
val payment: Payment = when (paymentType) {
"credit" -> CreditCard()
"paypal" -> PayPal()
"bitcoin" -> Bitcoin()
else -> error("Unknown payment type")
}
payment.processPayment(amount)
}
fun main() {
checkout("credit", 100.0)
checkout("paypal", 50.0)
checkout("bitcoin", 200.0)
}The Builder pattern is useful when you need to create complex objects with many optional parameters. It provides a fluent interface for building objects incrementally.
When to use:
Pros & Cons:
data class Email(
val to: String,
val subject: String = "",
val body: String = "",
val cc: List<String> = emptyList(),
val attachments: List<String> = emptyList()
)
class EmailBuilder {
private var to: String = ""
private var subject: String = ""
private var body: String = ""
private var cc: MutableList<String> = mutableListOf()
private var attachments: MutableList<String> = mutableListOf()
fun to(address: String) = apply { this.to = address }
fun subject(text: String) = apply { this.subject = text }
fun body(text: String) = apply { this.body = text }
fun cc(address: String) = apply { this.cc.add(address) }
fun attach(file: String) = apply { this.attachments.add(file) }
fun build() = Email(to, subject, body, cc, attachments)
}
fun main() {
val email = EmailBuilder()
.to("john@example.com")
.subject("Meeting")
.body("See you at 3pm")
.cc("jane@example.com")
.attach("agenda.pdf")
.build()
println(email)
}Create a PizzaBuilder that allows customers to customize their pizza.
data class Pizza with:size: String ("small", "medium", "large")cheese: Boolean = truetoppings: List<String> = emptyList()class PizzaBuilder with:fun size(s: String) - sets sizefun noCheese() - removes cheesefun addTopping(topping: String) - adds one toppingfun build(): Pizza - creates pizzafun reset() method to start a new pizzaPlayground is on the next slide ↓
data class Pizza(/* TODO */) {
fun calculatePrice(): Double {
val base = 10.0
val toppingCost = toppings.size * 2.0
val sizeMultiplier = when(size) {
"small" -> 1.0
"medium" -> 1.5
"large" -> 2.0
else -> 1.0
}
return (base + toppingCost) * sizeMultiplier
}
}
class PizzaBuilder {
// TODO: Implement builder
}
fun main() {
val margherita = PizzaBuilder()
.size("medium")
.addTopping("basil")
.build()
val meatLovers = PizzaBuilder()
.size("large")
.addTopping("pepperoni")
.addTopping("sausage")
.addTopping("bacon")
.addTopping("ham")
.build()
println("$margherita - Price: ${margherita.calculatePrice()}")
println("$meatLovers - Price: ${meatLovers.calculatePrice()}")
}The Repository pattern abstracts data access logic and provides a centralized way to manage domain objects. It acts as an in-memory collection of objects, hiding the details of data persistence.
When to use:
Pros & Cons:
data class User(val id: Int, val name: String, val email: String)
interface UserRepository {
fun findById(id: Int): User?
fun findAll(): List<User>
fun save(user: User)
fun delete(id: Int)
}
class InMemoryUserRepository : UserRepository {
private val users = mutableMapOf<Int, User>()
private var nextId = 1
override fun findById(id: Int): User? = users[id]
override fun findAll(): List<User> = users.values.toList()
override fun save(user: User) {
val id = if (user.id == 0) nextId++ else user.id
users[id] = user.copy(id = id)
}
override fun delete(id: Int) {
users.remove(id)
}
}
fun main() {
val repo: UserRepository = InMemoryUserRepository()
repo.save(User(0, "Alice", "alice@example.com"))
repo.save(User(0, "Bob", "bob@example.com"))
println("All users:")
repo.findAll().forEach { println(it) }
println("\nFind user 1:")
println(repo.findById(1))
}Create a ProductRepository for managing products in an e-commerce system.
Requirements:
data class Product(id: Int, name: String, price: Double, category: String)interface ProductRepository with:fun findById(id: Int): Product?fun findAll(): List<Product>fun save(product: Product): Product - returns saved product with IDfun delete(id: Int): Boolean - returns true if deletedfun findByCategory(category: String): List<Product>fun findByPriceRange(min: Double, max: Double): List<Product>class InMemoryProductRepositoryPlayground is on the next slide ↓
// Your implementation here
data class Product(
val id: Int,
val name: String,
val price: Double,
val category: String
)
interface ProductRepository {
// TODO: Add method signatures
}
class InMemoryProductRepository : ProductRepository {
// TODO: Implement repository
}
fun main() {
val repo: ProductRepository = InMemoryProductRepository()
// Add products
repo.save(Product(0, "Laptop", 999.99, "Electronics"))
repo.save(Product(0, "Mouse", 29.99, "Electronics"))
repo.save(Product(0, "Desk", 299.99, "Furniture"))
repo.save(Product(0, "Chair", 199.99, "Furniture"))
println("=== All Products ===")
repo.findAll().forEach { println(it) }
println("\n=== Electronics ===")
repo.findByCategory("Electronics").forEach { println(it) }
println("\n=== Products $50-$300 ===")
repo.findByPriceRange(50.0, 300.0).forEach { println(it) }
println("\n=== After deleting product 2 ===")
repo.delete(2)
repo.findAll().forEach { println(it) }
}The Strategy pattern lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. Clients can choose which algorithm to use at runtime.
When to use:
Pros & Cons:
interface SortingStrategy {
fun sort(data: MutableList<Int>)
}
class BubbleSort : SortingStrategy {
override fun sort(data: MutableList<Int>) {
println("Sorting using Bubble Sort")
// Simplified bubble sort
for (i in 0 until data.size) {
for (j in 0 until data.size - 1 - i) {
if (data[j] > data[j + 1]) {
val temp = data[j]
data[j] = data[j + 1]
data[j + 1] = temp
}
}
}
}
}
class QuickSort : SortingStrategy {
override fun sort(data: MutableList<Int>) {
println("Sorting using Quick Sort")
data.sort() // Using built-in sort
}
}
class DataProcessor(private var strategy: SortingStrategy) {
fun setStrategy(strategy: SortingStrategy) {
this.strategy = strategy
}
fun process(data: MutableList<Int>) {
strategy.sort(data)
println("Result: $data")
}
}
fun main() {
val processor = DataProcessor(BubbleSort())
processor.process(mutableListOf(5, 2, 8, 1, 9))
processor.setStrategy(QuickSort())
processor.process(mutableListOf(7, 3, 6, 4, 2))
}Create a payment processing system that supports multiple payment methods using the Strategy pattern.
Requirements:
interface PaymentStrategy with fun pay(amount: Double): BooleanCreditCardPayment(cardNumber: String) strategyPayPalPayment(email: String) strategyCryptoPayment(walletAddress: String) strategyclass ShoppingCart that uses PaymentStrategyPlayground is on the next slide ↓
// Your implementation here
interface PaymentStrategy {
fun pay(amount: Double): Boolean
}
// TODO: Implement payment strategies
class ShoppingCart {
private val items = mutableListOf<Pair<String, Double>>()
private var paymentStrategy: PaymentStrategy? = null
fun addItem(name: String, price: Double) {
items.add(name to price)
}
fun setPaymentMethod(strategy: PaymentStrategy) {
this.paymentStrategy = strategy
}
fun checkout(): Boolean {
val total = items.sumOf { it.second }
println("Total: $${"%.2f".format(total)}")
return paymentStrategy?.pay(total) ?: false
}
}
fun main() {
val cart = ShoppingCart()
cart.addItem("Laptop", 999.99)
cart.addItem("Mouse", 29.99)
println("=== Paying with Credit Card ===")
cart.setPaymentMethod(CreditCardPayment("1234567890123456"))
cart.checkout()
println("\n=== Paying with PayPal ===")
cart.setPaymentMethod(PayPalPayment("user@example.com"))
cart.checkout()
println("\n=== Paying with Crypto ===")
cart.setPaymentMethod(CryptoPayment("0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7"))
cart.checkout()
}These are high-level application architecture patterns used to define the structure of the application and the way in which the different components of the application interact with each other.
of the most common architecture patterns include:
Monolithic architecture tends to be tightly coupled, which can make it difficult to scale and maintain the application over time.
You will get it wrong!
And you will re-do it.
And you will still get it wrong again.
And then you will re-do it again.
And it will never be perfect.
And that's OK.
Embrace failure, learn from it, and go on.
You'll receive an expanded Coffee Shop codebase with SOLID violations. Identify the violations and refactor into a well-architected application.