DEV Community: Fernando Aparicio

From PHP to Kotlin - Day 6 - Entities

Fernando Aparicio — Fri, 28 Jan 2022 15:58:27 +0000

Entities are other thing. Are more complex and require more care.

Specifications
Mush have unique identifier
Must have value objects
Must be able to contain other entities
Must be able to be constructed in different ways if necessary "named constructors"

In this case we're going to create the Mower Entity.

The truth is that before starting this activity, the Mower entity was de first that was created, but it was quite anemic, since it needed other value objects like position or orientation to be created by composition and that's why I left it parked, since that didn't serve our purpose.

What we need from our Mower is:

That can be build
That can turn left
That can turn right
That can move along
That detects if it goes out of the limits of the map

Which leaves us with a test like this:

private const val MOVE_LEFT: String = "L"
private const val MOVE_RIGHT: String = "R"
private const val MOVE_FORWARD: String = "F"

private const val X_POSITION: Int = 1
private const val Y_POSITION: Int = 1
private const val STEP: Int = 1

private const val NORTH_ORIENTATION: String = "N"
private const val WEST_ORIENTATION: String = "W"
private const val EAST_ORIENTATION: String = "E"
private const val SOUTH_ORIENTATION: String = "S"

internal class MowerTest {
    private lateinit var mower: Mower
    private val mowerId: MowerId = MowerId.build(UUID.randomUUID().toString())
    private lateinit var mowerPosition: MowerPosition

    @BeforeEach
    fun setUp() {
        mowerPosition = MowerPosition.build(
            XMowerPosition.build(X_POSITION),
            YMowerPosition.build(Y_POSITION),
            MowerOrientation.build(NORTH_ORIENTATION)
        )

        mower = Mower.build(mowerId, mowerPosition)
    }

    @Test
    fun `Should be build`() {
        val mower = Mower.build(mowerId, mowerPosition)

        assertThat(mower).isInstanceOf(Mower::class.java)
        assertThat(mower.mowerId).isEqualTo(mowerId)
        assertThat(mower.mowerPosition()).isEqualTo(mowerPosition)
    }

    @Test
    fun `Should be able to turn left`() {
        val expectedMowerOrientation = MowerOrientation.build(WEST_ORIENTATION)

        mower.move(MowerMovement.build(MOVE_LEFT))
        assertThat(mower.mowerPosition().orientation).isEqualTo(expectedMowerOrientation)
    }

    @Test
    fun `Should be able to turn right`() {
        val expectedMowerOrientation = MowerOrientation.build(EAST_ORIENTATION)

        mower.move(MowerMovement.build(MOVE_RIGHT))
        assertThat(mower.mowerPosition().orientation).isEqualTo(expectedMowerOrientation)
    }

    @Test
    fun `Should be able to move forward`() {
        mower.move(MowerMovement.build(MOVE_FORWARD))
        assertThat(mower.mowerPosition().xPosition.value).isEqualTo(X_POSITION)
        assertThat(mower.mowerPosition().yPosition.value).isEqualTo(Y_POSITION + STEP)
    }

    @ParameterizedTest
    @MethodSource("positionAndMovementProvider")
    fun `Should throw exception if goes out of bounds`(xPosition: Int, yPosition: Int, orientation: String) {
        val mowerPosition = MowerPosition.build(
            XMowerPosition.build(xPosition),
            YMowerPosition.build(yPosition),
            MowerOrientation.build(orientation)
        )

        val mower = Mower.build(mowerId, mowerPosition)

        assertThrows(InvalidMowerPositionException::class.java) {
            mower.move(MowerMovement.build(MOVE_FORWARD))
        }
    }

    companion object {
        @JvmStatic
        fun positionAndMovementProvider(): Stream<Arguments> {
            return Stream.of(
                Arguments.arguments(0, 0, SOUTH_ORIENTATION),
                Arguments.arguments(0, 0, WEST_ORIENTATION),
                Arguments.arguments(0, 5, NORTH_ORIENTATION),
                Arguments.arguments(5, 0, EAST_ORIENTATION)
            )
        }
    }
}

If all went well in the previous value objects, our Mower should look like this:

import mower.mower.value_object.MowerId
import mower.mower.value_object.MowerMovement
import mower.mower.value_object.MowerPosition

class Mower private constructor(val mowerId: MowerId, private var mowerPosition: MowerPosition) {

    fun move(movement: MowerMovement) {
        mowerPosition = mowerPosition.move(movement)
    }

    companion object {
        @JvmStatic
        fun build(mowerId: MowerId, mowerPosition: MowerPosition): Mower {
            return Mower(mowerId, mowerPosition)
        }
    }

    fun mowerPosition(): MowerPosition {
        return mowerPosition
    }
}

All the logic has been distributed in the value objects in a natural way. Every piece fulfills its function. Te Mower sould only apply the movement that it passes to the MowrePosition object, which decides if it's a forward movement or a change of direction, and executes the necessary changes...

The Value objects XMowerPosition and YMowerPosition watch for negative positions in the coordinates. But there aren't able to know if they are outside the map in positive coordinates. The tests that we've created for Mower will fail in this specific field, so we must pass the map to it to validate that casuistry...

Bonus test and context

The truth is that I'm quite a fan of giving a little explanation when the tests are executed. You never know when one is going to fail and the idea is that the person who comes after us has a bit of context as to why is failing.
See a test without context about values used it can be difficult.

...
    @ParameterizedTest(name = "{0}")
    @MethodSource("positionAndMovementProvider")
    fun `Should throw exception if goes out of bounds`(scenario: String, xPosition: Int, yPosition: Int, orientation: String) {
...
    }

    companion object {
        @JvmStatic
        fun positionAndMovementProvider(): Stream<Arguments> {
            return Stream.of(
                Arguments.arguments("Out of bounds by negative value movement axis Y", 5, 0, SOUTH_ORIENTATION),
                Arguments.arguments("Out of bounds by negative value movement axis X", 0, 5, WEST_ORIENTATION),
                Arguments.arguments("Out of bounds movement axis Y", 0, 5, NORTH_ORIENTATION),
                Arguments.arguments("Out of bounds movement axis X", 5, 0, EAST_ORIENTATION)
            )
        }
    }

It may seem a bit strange to add an argument that is not going to be used in the test.... but it makes sense when...

We go from this:

Or this:

To this:

Much clearer and more readable...

Although JUnit gives us a warning for not actually using the variable... it seems that it doesn't like our use of it.

Links and resources

Repository Mower Kata

From PHP to Kotlin - Day 5 - Extending the use of Enum

Fernando Aparicio — Fri, 28 Jan 2022 15:57:19 +0000

In the previous post I told you how easy it's to add information to Enum. Apart from context, we can add values to it to give it functionality.

Finally, adding functionalities to mower orientation, we need to add directionality in the displacement axes to know if moving should add values (N, E), or substract values (S, W).

The tests and the interaction with the MowerPosition object led us to this point:

Testing and interaction with the MowerPosition object brought us to this point:

package mower.mower.domain.value_object

import mower.mower.domain.exception.InvalidOrientationException
import org.assertj.core.api.Assertions.assertThat
import org.junit.jupiter.api.Assertions.*
import org.junit.jupiter.params.ParameterizedTest
import org.junit.jupiter.params.provider.Arguments
import org.junit.jupiter.params.provider.MethodSource
import org.junit.jupiter.params.provider.ValueSource
import java.util.stream.Stream
import kotlin.test.Test

private const val ORIENTATION: String = "N"
private const val INVALID_ORIENTATION: String = "H"

internal class MowerOrientationTest
{
    @Test
    fun `Should be build`() {
        val orientation = MowerOrientation.build(ORIENTATION)

        assertInstanceOf(MowerOrientation::class.java, orientation)
        assertThat(orientation.value).isEqualTo(ORIENTATION)
    }

    @ParameterizedTest(name = "{index} => orientation = ''{0}''")
    @ValueSource(strings = [ "N", "S", "E", "W" ])
    fun `Should be build with valid orientations`(value: String) {
        val orientation = MowerOrientation.build(value)

        assertThat(orientation.value).isEqualTo(value)
    }

    @Test
    fun `Should throw exception for invalid Orientation`() {
        assertThrows(InvalidOrientationException::class.java) {
            MowerOrientation.build(INVALID_ORIENTATION)
        }
    }

    @ParameterizedTest(name = "{index} => orientation = ''{0}'', movement = ''{1}'', result = ''{2}''")
    @MethodSource("orientationAndMovementProvider")
    fun `Should apply orientation movements`(orientationData: String, movementData: String, expectedOrientationData: String) {
        var orientation = MowerOrientation.build(orientationData)
        val movement = MowerMovement.build(movementData)
        val expectedOrientation = MowerOrientation.build(expectedOrientationData)

        orientation = orientation.changeOrientation(movement)

        assertThat(orientation.value).isEqualTo(expectedOrientation.value)
    }

    @ParameterizedTest
    @MethodSource("orientationAndYAxisAffectationProvider")
    fun `Should eval if affects Y axis`(orientationData: String, affectsYAxis: Boolean) {
        val orientation = MowerOrientation.build(orientationData)

        assertThat(orientation.affectsYAxis()).isEqualTo(affectsYAxis)
    }

    @ParameterizedTest
    @MethodSource("orientationAndXAxisAffectationProvider")
    fun `Should eval if affects X axis`(orientationData: String, affectsXAxis: Boolean) {
        val orientation = MowerOrientation.build(orientationData)

        assertThat(orientation.affectsXAxis()).isEqualTo(affectsXAxis)
    }

    @ParameterizedTest
    @MethodSource("orientationAndStepDirectionProvider")
    fun `Should eval direction step` (orientationData: String, expectedStepDirection: Int) {
        val orientation = MowerOrientation.build(orientationData)

        assertThat(orientation.stepMovement()).isEqualTo(expectedStepDirection)
    }

    companion object {
        @JvmStatic
        fun orientationAndMovementProvider(): Stream<Arguments> {
            return Stream.of(
                Arguments.arguments("N", "F", "N"),
                Arguments.arguments("N", "R", "E"),
                Arguments.arguments("E", "R", "S"),
                Arguments.arguments("S", "R", "W"),
                Arguments.arguments("W", "R", "N"),
                Arguments.arguments("N", "L", "W"),
                Arguments.arguments("W", "L", "S"),
                Arguments.arguments("S", "L", "E"),
                Arguments.arguments("E", "L", "N")
            )
        }

        @JvmStatic
        fun orientationAndYAxisAffectationProvider(): Stream<Arguments> {
            return Stream.of(
                Arguments.arguments("N", true),
                Arguments.arguments("S", true),
                Arguments.arguments("E", false),
                Arguments.arguments("W", false)
            )
        }

        @JvmStatic
        fun orientationAndXAxisAffectationProvider(): Stream<Arguments> {
            return Stream.of(
                Arguments.arguments("N", false),
                Arguments.arguments("S", false),
                Arguments.arguments("E", true),
                Arguments.arguments("W", true)
            )
        }

        @JvmStatic
        fun orientationAndStepDirectionProvider(): Stream<Arguments> {
            return Stream.of(
                Arguments.arguments("N", 1),
                Arguments.arguments("E", 1),
                Arguments.arguments("S", -1),
                Arguments.arguments("W", -1),
            )
        }
    }
}

The class that implements it was left like this

@JvmInline
value class MowerOrientation private constructor(val value: String) {
    private enum class Compass (val stepDirection: Int){
        N (POSITIVE_DIRECTION),
        E (POSITIVE_DIRECTION),
        S (NEGATIVE_DIRECTION),
        W (NEGATIVE_DIRECTION)
    }

    init {
        try {
            Compass.valueOf(value)
        } catch (exception: IllegalArgumentException) {
            throw InvalidOrientationException.withValues(value, Compass.values().contentToString())
        }
    }

    companion object {
        private const val COMPASS_STEP: Int = 1
        private const val POSITIVE_DIRECTION: Int = 1
        private const val NEGATIVE_DIRECTION: Int = -1

        @JvmStatic
        fun build(value: String): MowerOrientation
        {
            return MowerOrientation(value)
        }
    }

    fun changeOrientation(mowerMovement: MowerMovement): MowerOrientation {
        val currentCompass = Compass.valueOf(value)

        if (mowerMovement.isClockWise()) {
            val futureCompass = Compass.values().getOrElse(currentCompass.ordinal + COMPASS_STEP) { Compass.N }
            return MowerOrientation(futureCompass.name)
        }

        if (mowerMovement.isCounterClockWise()) {
            val futureCompass = Compass.values().getOrElse(currentCompass.ordinal - COMPASS_STEP) { Compass.W }
            return MowerOrientation(futureCompass.name)
        }

        return this
    }

    fun affectsYAxis(): Boolean {
        return Compass.N.name == value || Compass.S.name == value
    }

    fun affectsXAxis(): Boolean {
        return Compass.E.name == value || Compass.W.name == value
    }

    fun stepMovement(): Int {
        return Compass.valueOf(value).stepDirection
    }
}

Possible refactor

We could add features to Enum to simplify affectsYAxis and affectsXAxis functions in the same way that it's articulated with the stepMovement function. Leaving the class with these changes.

...

@JvmInline
value class MowerOrientation private constructor(val value: String) {
    private enum class Compass (val stepDirection: Int, val affectsXAxis: Boolean, val affectsYAxis: Boolean){
        N(POSITIVE_DIRECTION, NOT_X_AXIS, Y_AXIS),
        E(POSITIVE_DIRECTION, X_AXIS, NOT_Y_AXIS),
        S(NEGATIVE_DIRECTION, NOT_X_AXIS, Y_AXIS),
        W(NEGATIVE_DIRECTION, X_AXIS, NOT_Y_AXIS)
    }
...
    companion object {
...
        private const val NOT_X_AXIS: Boolean = false
        private const val NOT_Y_AXIS: Boolean = false
        private const val X_AXIS: Boolean = true
        private const val Y_AXIS: Boolean = true
...
    }
...
    fun affectsYAxis(): Boolean {
        return Compass.valueOf(value).affectsYAxis
    }

    fun affectsXAxis(): Boolean {
        return Compass.valueOf(value).affectsXAxis
    }

    fun stepMovement(): Int {
        return Compass.valueOf(value).stepDirection
    }
}

From PHP to Kotlin - Day 4 - Validating a Value object with enum and parametrized tests

Fernando Aparicio — Fri, 28 Jan 2022 15:57:03 +0000

The interesting thing about Enums in Kotlin, is that it's too easy add context to them.

Even if Enums in Kotlin has a los of possibilities, we'll use just the basic and necessary for our needs.

Although Enums in Kotlin have many possibilities, we will use what is just and necessary for our needs.

To see it, we'll use the MowerOrientation Value object.

As always, we set up a test scenario to start working.

import mower.mower.exception.InvalidOrientationException
import org.assertj.core.api.Assertions.assertThat
import org.junit.jupiter.api.Assertions.*
import org.junit.jupiter.params.ParameterizedTest
import org.junit.jupiter.params.provider.ValueSource
import kotlin.test.Test

private const val ORIENTATION = "N"
private const val INVALID_ORIENTATION = "H"

internal class MowerOrientationTest {
    @Test
    fun `Should be build`() {
        val orientation = MowerOrientation.build(ORIENTATION)

        assertInstanceOf(MowerOrientation::class.java, orientation)
        assertThat(orientation.value).isEqualTo(ORIENTATION)
    }

    @ParameterizedTest(name = "{index} => orientation = ''{0}''")
    @ValueSource(strings = [ "N", "S", "E", "W" ])
    fun `Should be build with valid orientations`(value: String) {
        val orientation = MowerOrientation.build(value)

        assertThat(orientation.value).isEqualTo(value)
    }

    @Test
    fun `Should throw exception for invalid Orientation`() {

        assertThrows(InvalidOrientationException::class.java) {
            MowerOrientation.build(INVALID_ORIENTATION)
        }
    }
}

We want to validate that the value we pass to the value object satisfies all four possible directions. We also want a custom error and the code remains elegant (without try-catch)

Notice how the test is configured with several possible values.
The ParameterizedTest in JUnit is the equivalent of the PHPUnit DataProvider. We can add context to it by launching them with a template like the one described in the test.

...
    @ParameterizedTest(name = "{index} => orientation = ''{0}''")
...

The required object can be articulated as follows.

import mower.mower.exception.InvalidOrientationException

@JvmInline
value class MowerOrientation private constructor(val value: String) {
    private enum class Compass(val value: String){
        NORTH("N"),
        EAST("E"),
        SOUTH("S"),
        WEST("W")
    }

    init {
        if(null === enumValues<Compass>().find { it.value == value}){
            throw InvalidOrientationException.withValues(value, Orientations.values().map { it.value }.toString())
        }
    }

    @JvmStatic
    companion object {
        fun build(value: String): MowerOrientation
        {
            return MowerOrientation(value)
        }
    }
}

The most interesting thing is that we can create a constant, which serves as a context, and an associated value, which is what the system will use to initialize the value of the value object. There are more ways to feed the parameters in the documentation that I put below.

Ongoing dilemma...

Kotlin is more in favor of throwing exceptions than using the null value as a response. We can do some changes to meet your requirements. We would save ourselves the cost of processing with "find" and "map" in case of responding with an error.

Although I prefer the first implementation, I understand that if we don't handle null values, we can have a hidden problem in our code, something that doesn't happen in an unhandled exception.

    ...
    private enum class Compass{ N, E, S, W }

    init {
        try {
            Compass.valueOf(value)
        } catch (exception: IllegalArgumentException) {
            throw InvalidOrientationException.withValues(value, Compass.values().contentToString())
        }
    }
    ...

If later we want to use enum to retrieve information, in the first way we must use "find" and treat the null value, which is not optimal. For me is the eternal dilemma... and there's no hard answer. Depends... like everything...

The worst thing I've seen is an escalation of try-catch between objects that calling other objects, and that usually ends badly... hard to read and manage.

In this case I think that it's more accurate to go the Kotlin way and we'll leave you with the exception handling. Since later we'll have to use the Enum values for other things and we would be doing "find" every time, thus hampering the utility funcionality.

Links and resources

Enum class

https://kotlinlang.org/docs/enum-classes.html

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/enum-values.html

Parameterized test sources

https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests-sources

https://www.petrikainulainen.net/programming/testing/junit-5-tutorial-writing-parameterized-tests/

From PHP to Kotlin - Day 3 - Dealing with exceptions

Fernando Aparicio — Fri, 28 Jan 2022 15:56:44 +0000

Previously, our Value object validated that the value was correct. But we used a generic exception, which only lets us put a message.

That may be fine, but in DDD context it's not quite right. The idea is that through folder struture and files that we have, we can get an idea of the domain.

In this case, it's more wise to handle a custom exception. And in the future, we will be able to better control the exceptions in our flow.

So, we're going to change the test that expects the exception and we're going to be more explicit.

...
internal class YMowerPositionTest
{
...
    @Test
    fun `Should throw exception for invalid values` ()
    {
        assertThrows(InvalidMowerPositionException::class.java) {
            YMowerPosition.build(INVALID_POSITION)
        }
    }
}

And to create the exception, we'll use a test for the
InvalidMowerPositionException.

import org.assertj.core.api.Assertions.assertThat
import org.junit.jupiter.api.Assertions.*
import kotlin.test.Test

private const val POSITION: Int = 4;
private const val MESSAGE: String = "Invalid Y position $POSITION. Only positive values are valid."

internal class InvalidMowerPositionExceptionTest
{
    @Test
    fun `Should be build with custom value`() {
        val exception = assertThrows(InvalidMowerPositionException::class.java) {
            throw InvalidMowerPositionException.withValue(POSITION)
        }

        assertThat(exception.message).isEqualTo(MESSAGE)
    }
}

And the code that implements it.

class InvalidMowerPositionException private constructor (message: String? = null, cause: Throwable? = null) : Exception(message, cause) {
    companion object {
        private const val MESSAGE: String = "Invalid Y position %d. Only positive values are valid."

        @JvmStatic
        fun withValue(value: Int): InvalidMowerPositionException
        {
            return InvalidMowerPositionException(String.format(MESSAGE, value), null)
        }
    }
}

This time we've gone faster creating that class. We know a little better how to do it and it's not more complex.

Tip

If you take a closer look, when creating the message, the test uses a simple concatenation, and the exception a String.format(). This is done on purpose to avoid do copy/pasting from test to implementation. This ensures that the result is as expected.

Links and resources

Exceptions

https://kotlinlang.org/docs/exceptions.html?q=con#exception-classes

From PHP to Kotlin - Day 2 - Value objects

Fernando Aparicio — Fri, 28 Jan 2022 15:56:31 +0000

First hurdle, finding and understanding the equivalent of Composer in Kotlin. In this case I was lucky to have the Jetbrains IDE (community version is enough) that makes your life easier by creating a console project from scratch.

Also in my case I had to use the 16 version of Java due to incompatibilties with 17 version.

So far so good. Now the good begins...

1. Put the mower kata README to define the goals

As we said, laying the first stone means starting with the tests usind DDD as a structural element.

In Java and Kotlin, by heritage of the former, the main and test folder are at the same level within src.

Let's create inside main/kotlin our bounded context mower and module mower.

Java naming convention rule. The folders (or packages as it is usually called) always in lowercase.

2. Watch how to create a Value object

In this case we're going to see how to create the smallest piece of the DDD universe. The Value object.

A value object must meet the following specifications.

Specifications
Should have a primitive or another value objects
Should be immutable
Should be able to validate itself when built
Should be able to be constructed in different ways if it's necessary "named constructors"

In PHP, a Value object might look like this.

final class YCoordinate
{
    private const MINIMUM_AXIS_VALUE = 0;

    /**
     * @throws YCoordinateOutOfBoundsException
     */
    private function __construct(private int $value)
    {
        if (self::MINIMUM_AXIS_VALUE > $this->value) {
            throw YCoordinateOutOfBoundsException::withCoordinate($this->value);
        }
    }

    public static function build(int $value): self
    {
        return new self($value);
    }

    public function value(): int
    {
        return $this->value;
    }
}

This class conforms to the standards for a Value object.

It should be noted that I am a strong advocate of using named constructors. They provide context and when an object can be created in different ways, having made a first named constructor then opens the door to adding a second or third one, focusing on the context of why that one was used and not another one that the object may have.

Now let's see if a Value object in Kotlin can be created in a similar way with the same rules.

Looking at the language specifications, it seems that the named constructor issue is different. We'll have to work on it a bit...

As we said before... we write tests with our targets for the Value object before we write anything else.

import org.assertj.core.api.Assertions.assertThat
import org.junit.jupiter.api.Assertions.*
import kotlin.test.Test

private const val Y_POSITION: Int = 3
private const val INVALID_POSITION: Int = -1

internal class YMowerPositionTest
{
    @Test
    fun `Should be build` ()
    {
        var yMowerPosition = YMowerPosition.build(Y_POSITION)

        assertInstanceOf(YMowerPosition::class.java, yMowerPosition)
        assertThat(yMowerPosition.value).isEqualTo(Y_POSITION)
    }

    @Test
    fun `Should throw exception for invalid values` ()
    {
        assertThrows(Exception::class.java) {
            YMowerPosition.build(INVALID_POSITION)
        }
    }
}

Using data class

The Data class is promising... with few code you have almost everything we need, but there's a problem with named constructors that invalidates this option.

We can make it immutable declaring its values as "val" instead of "var". They accept "copy", "equals", "toString" directly without our intervention... and access values is easy... buuuuut we can't make the original constructor private, since the "copy" needs to have access to the constructor... and that would create a doorway to a contextless constructor, which is exactly what we want to avoid.

While it would have been nice to have all of that by default, just because you can't make the original constructor private, it's ruled out. Although they can still be used as DTOs.

private const val MINIMUM_AXIS_VALUE: Int = 0

data class YMowerPosition constructor (val value: Int) {

    init {
        if(value < MINIMUM_AXIS_VALUE){
            throw Exception("Invalid value")
        }
    }
}

Data class as Value Object	Meets	Comments
Should have a primitive or another value objects		-
Should be immutable		-
Should be able to validate itself when built		-
Should be able to be constructed in different ways if it's necessary "named constructors"		We cannot make private primary constructor

Using normal class with "companion object"

With the companion object in a standard class we can achieve the goal of named constructors.

class YMowerPosition private constructor (val value: Int) {

    init {
        if(value < MINIMUM_AXIS_VALUE){
            throw Exception("Invalid value")
        }
    }

    @JvmStatic
    companion object {
        private const val MINIMUM_AXIS_VALUE: Int = 0

        fun build(value: Int): YMowerPosition {
            return YMowerPosition(value)
        }
    }
}

Normal class with companion object	Meets
Should have a primitive or another value objects
Should be immutable
Should be able to validate itself when built
Should be able to be constructed in different ways if it's necessary "named constructors"

You may be wondering why there is no accessor for "value".

It's simple, by being able to declare a property as immutable with "val", we can make it public, so that cannot change anymore.

Optimizing the Value object with Inline class

If we are going to host primitives, Kotlin brought out the concept of Inline classes.

Its use is intended to optimize resources and discards the concept of identity implicit in an object at the instance level.

By declaring a class as "value class", you basically just allow values to be compared with == operator.

So, our value object can be refactored a bit...

@JvmInline
value class YMowerPosition private constructor (val value: Int) {
...
}

And the tests will continue to pass.

Inline classes have a limit!!!

They are only capable of holding a value using their constructor, so if your value object has more values when it is initialized, it should be a normal class.

Bonus track about constants and static functions

Constants can be at companion object level o at file level out of the class. I prefer within the class. There are other ways to achieve something similar, but without using the const* keyword and it doesn't make sense to me. Also, note that constants can be declared with a data type.

Static functions, in order to be called from Java, must hace tha annotation @JvmStatic. If not, Java doesn't be able to use it comfortably.

class C {
    companion object {
        @JvmStatic fun callStatic() {}
        fun callNonStatic() {}
    }
}

C.callStatic(); // works fine
C.callNonStatic(); // error: not a static method
C.Companion.callStatic(); // instance method remains
C.Companion.callNonStatic(); // the only way it works

Links and resources

Static functions

https://kotlinlang.org/docs/java-to-kotlin-interop.html#static-methods

From PHP to Kotlin - Day 1 - Setting goals

Fernando Aparicio — Fri, 28 Jan 2022 15:56:05 +0000

To switch to another language, you have to learn its structure and rules. But really, to get the best benefit, it's more useful to think about doing an exercise you've solved before using your favorite language and try to solve it using the new one.

Thinking about how to approach the language change, I've done a list of rules so as not to get lost in the transition.

Rules for changing language

To start with, find a kata that has varied elements to test your skills.
Use the good practices that you already know from your usual language and fight to achieve the same. Never lower the quality!!!
You may have to rethink certain terms that seemed non-negotiable in your usual language and that are approached differently in the new language... that mental process of arguing why it is different will give you the deep knowledge of the new language.
Apply TDD with DDD always. That means that you have to start thinking about how to use the testing framework of that language and then writing the code. As we know, TDD without an structure like DDD is useless. You can do something unreadable but full tested and it's not the goal. Change the language, not the structure.

It may seem a bit crude to fight with the testing framework before the code. But if you have decided to change to another language, it's surely because you've already read something about how it's articulated and you've liked what you see,

so now it's time to get serious (from kindness, of course) and see how to set up the tests with the new language. Having different rules may susprise you and will also make you change your mentality.

You will hardly be able to do the same thing the way you are used to... and tests are no exception. In my case I'll use the mower kata.

Getting out of the comfort zone with Kotlin

Fernando Aparicio — Fri, 28 Jan 2022 15:55:23 +0000

Here we are. Actually I don't want go out of PHP. It gives me great stuff and has a lot of impressive libraries. But if I want to grow, I have to embrace another language and see if I can write the same as makes me happy in PHP.

Essentially, the goal is to see if I have the necessary architecture tools to achieve the same result in another language. With other rules and philosophy.

Having Symfony with Messenger and Doctrine makes my life easy, but.... What if I didn't have this pieces of software?... What if I was in another language with other rules or another reality?.. what would happen?

The first language chosen is... Kotlin!!... Why?... Because is used in Android, server side applications. It shares strong roots with Java, there's a community version of IntelliJ... and because it's hot...

Movement is demonstrated by walking... and that's what we're going to do...

DEV Community: Fernando Aparicio

From PHP to Kotlin - Day 6 - Entities

Bonus test and context

Links and resources

From PHP to Kotlin - Day 5 - Extending the use of Enum

Possible refactor

From PHP to Kotlin - Day 4 - Validating a Value object with enum and parametrized tests

Ongoing dilemma...

Links and resources

Enum class

Parameterized test sources

From PHP to Kotlin - Day 3 - Dealing with exceptions

Tip

Links and resources

Exceptions

From PHP to Kotlin - Day 2 - Value objects

1. Put the mower kata README to define the goals

2. Watch how to create a Value object

Using data class

Using normal class with "companion object"

Optimizing the Value object with Inline class

Inline classes have a limit!!!

Bonus track about constants and static functions

Links and resources

Naming conventions

Data classes

Inline classes

Constructors and validation

Constants

Static functions

From PHP to Kotlin - Day 1 - Setting goals

Rules for changing language

Getting out of the comfort zone with Kotlin