DEV Community: Aviv Mor

Strategy Design Pattern with Spring Boot + Kotlin - Cleaner code with no boilerplate

Aviv Mor — Thu, 02 Mar 2023 09:48:50 +0000

The Strategy Pattern

If you already know the strategy pattern just jump here.

What is it?

According to Wikipedia, the strategy pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

In simple words, the strategy pattern is used to specify how something should be done by providing a specific algorithm.
For example, a strategy for payment could be Credit Card, PayPal, or any other payment provider.

Why should we use it?

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it (source).

In short, it makes our code cleaner, easier to maintain, and reusable.

The Strategy Pattern in Code

Implementations of the pattern consist of an interface defining the strategy, multiple concrete implementations of the strategy and a context using the strategy.

By Vanderjoe - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=60733582

Code Example

Let's look at the following simplified scenario:

We have an application with users and we need to send them verification codes for 2FA.
The application supports multiple communication options for receiving the verification code: Email, SMS, Notifications...
Each user selects its preferred communication method.

First we will define our strategy interface:

interface VerificationCodeCommunicationStrategy {
    fun sendVerificationCode(user: User, code: String)
}

Now let's add our implementations:

class EmailCommunicationStrategy : VerificationCodeCommunicationStrategy {
    override fun sendVerificationCode(user: User, code: String) {
        emailClient.sendEmail(user.email, "Verification code", "Your verification is $code.")
    }
}

class SmsCommunicationStrategy : VerificationCodeCommunicationStrategy {
    override fun sendVerificationCode(user: User, code: String) {
        smsClient.sendSMS(user.phone, "Your verification is $code.")
    }
}

// ...

All that's left is to use the strategy.

enum class CommunicationMethod {
    Email, SMS, Notification
}

class VerificationCodeService {
    val verificationCodeStrategyMap: Map<CommunicationMethod, VerificationCodeCommunicationStrategy> = mapOf(
        CommunicationMethod.Email to EmailCommunicationStrategy(),
        CommunicationMethod.SMS to SmsCommunicationStrategy(),
        // ...
    )

    fun sendVerificationCode(user: User) {
        val code = generateVerificationCode()

        val verificationCodeStrategy = verificationCodeStrategyMap[user.preferredCommunicationMethod]
        verificationCodeStrategy?.sendVerificationCode(user, code)
    }
}

We can see how the code is clean and easy to maintain. Adding a new communication method would be easy and will not need to change existing code other than adding it to the map of strategies.

The Library

We use the strategy pattern a-looot in our projects. Moreover, like all developers we are lazy and want to make our life as easy as possible. This is why we created our library.

Code Example WITHOUT the library

Let's revise the previous example for a regular Spring Boot implementation.

When using the strategy pattern in a Spring Boot application the context and strategy implementations are usually Spring components.

We will start with the strategies:

interface VerificationCodeCommunicationStrategy {
    fun sendVerificationCode(user: User, code: String)
}

@Component
class EmailCommunicationStrategy : VerificationCodeCommunicationStrategy {
    override fun sendVerificationCode(user: User, code: String) {
        emailClient.sendEmail(user.email, "Verification code", "Your verification is $code.")
    }
}

@Component
class SmsCommunicationStrategy : VerificationCodeCommunicationStrategy {
    override fun sendVerificationCode(user: User, code: String) {
        smsClient.sendSMS(user.phone, "Your verification is $code.")
    }
}

// ...

The interface remains the same and the implementations receive the @Component annotation.

Now let's move on to the verification service.

@Service
class VerificationCodeServiceImpl(
    private val emailCommunicationStrategy: EmailCommunicationStrategy,
    private val smsCommunicationStrategy: SmsCommunicationStrategy
) {
    private val verificationCodeStrategyMap: Map<CommunicationMethod, VerificationCodeCommunicationStrategy> = mapOf(
        CommunicationMethod.Email to emailCommunicationStrategy,
        CommunicationMethod.SMS to smsCommunicationStrategy
    )

    fun sendVerificationCode(user: User) {
        val code = generateVerificationCode()

        val verificationCodeStrategy = verificationCodeStrategyMap[user.preferredCommunicationMethod]
        verificationCodeStrategy?.sendVerificationCode(user, code)
    }
}

We need to add the strategy implementations to the constructor and build the map manually. That's no fun!

Code Example WITH the library

The entire objective of the library is to make our life easier and the code cleaner and less bug prone. It does it by simply building the strategy map automatically.

We will start by modifying the strategy interface.

interface VerificationCodeCommunicationStrategy {
    @get:ComponentMapKey
    val method: CommunicationMethod

    fun sendVerificationCode(user: User, code: String)
}

As you can see we have added a new field method with the annotation @ComponentMapKey. This informs the library which field is the key for the strategy map.

Let's update the implementations according to the modified interface.

@Component
class EmailCommunicationStrategy : VerificationCodeCommunicationStrategy {
    override val method = CommunicationMethod.Email

    override fun sendVerificationCode(user: User, code: String) {
        emailClient.sendEmail(user.email, "Verification code", "Your verification is $code.")
    }
}

@Component
class SmsCommunicationStrategy : VerificationCodeCommunicationStrategy {
    override val method = CommunicationMethod.SMS

    override fun sendVerificationCode(user: User, code: String) {
        smsClient.sendSMS(user.phone, "Your verification is $code.")
    }
}

// ...

Now let's modify the service to use the library.

@Service
class VerificationCodeServiceImpl {
    @ComponentMap
    private lateinit var verificationCodeStrategyMap: Map<CommunicationMethod, VerificationCodeCommunicationStrategy>

    fun sendVerificationCode(user: User) {
        val code = generateVerificationCode()

        val verificationCodeStrategy = verificationCodeStrategyMap[user.preferredCommunicationMethod]
        verificationCodeStrategy?.sendVerificationCode(user, code)
    }
}

That's it! All we had to do is to add the @ComponentMap annotation to the strategy map and voila! The map is built automatically from the components. No boiler-plate code. To add a new strategy all you need to do is to create a new implementation and it will be "magically" added to all relevant strategy maps.

Final Words

This library is the most used library in our projects. Although it's not life changing, it's just useful, helps us keep our code clean and prevents lots of recurring bugs from forgetting to add new strategies to their appropriate maps.

If you would like to use it you can start with the quick start guide.

We develop open source because we love it and want to contribute to the cause. If you would like to support us please consider starring the repository.

Introducing ShapeShift: A lightweight, modular, performant and extensible object mapping library for Kotlin/Java

Aviv Mor — Wed, 12 Oct 2022 12:07:23 +0000

WHY

The short answer

We needed a simple to use, minimal boiler plate mapping engine, that is also flexible and supports the most advanced use cases.

The long answer

A few years ago we got tired of developing the same boiler plate code for CRUD and decided to develop a generic CRUD framework.

As a part of this framework we needed an object mapping library and could not find one that answered all of our requirements.

The first iteration of the library was part of the entire CRUD framework. However, some time ago we decided we want to start contributing to the open source community and we thought "What is the best way to contribute if not to release our CRUD framework?". The issue with this thought is that the framework is huge and contains lots of code, polishing it and getting it ready to be published as open source would take a lot of time (documentation anyone?).

Our solution was to separate the framework into multiple smaller libraries we can polish and publish in smaller time frames. The first of these libraries is ShapeShift.

WHAT

The short answer

ShapeShift will help you transform object of type A to object of type B easily, fast and without boiler plate code.

ShapeShift main features:

Auto mapping
Custom field transformers
Default transformers
Deep mapping
Multiple mapping targets
Conditional mapping
Mapping decorators
Seamless spring integration
Native Kotlin DSL API
Java builder API
Annotations API
Native Android support

The longer answer

ShapeShift's job seems simple, convert object of type A to object of type B. But to do its job in the best way possible, the library offers lots of features, to name a few:

Advanced auto mapping - Automatically map fields with the same name from the source object to the target object. Control wether to map only fields of the same type or use the advanced default transformers feature to auto map fields of different types!
Seamless Spring integration - ShapeShift's Spring Boot library allows to integrate it with Spring easily. Use Spring's power to create custom transformers beans with access to DB or other resources.

More about the advanced features with code examples is available in Kotlin version and Java version.

HOW

The short answer

ShapeShift supports multiple APIs to configure your mappings.
Annotations, Kotlin DSL and Java Builder.

The long answer

ShapeShift's documentation is available here. You can check our Quick Start guide to get it up and running in 5 minutes.

Built with Kotlin in mind, ShapeShift was designed around its ecosystem and best practices. The library APIs for mapping with Kotlin:

Annotations - Fully featured annotation based mapping, just add annotations to your objects and ShapeShift handles the rest. Including using custom field transformers, conditional mapping, advanced object decoration and much more.
Kotlin DSL - Allowing you to define the relations between objects. This allows you to map objects you can't change (or don't want to), like objects from 3rd party libraries. Additionally you can define inline transformations, conditions and decorations, enabling deep customization and very advanced mapping.

ShapeShift also has full Java support available with multiple APIs for mapping:

Annotations - Same API as Kotlin with full Java support.
Java Builder - The equivalent Java API for the Kotlin DSL. Allowing you to define the relations between objects without modifying their code, and map objects you can't change (or don't want to).

Final words

We poured our love, time, knowledge and what not into ShapeShift. I'm proud of the result and our greatest achievement is to be able to help others with their work.

If you would like to contribute, please feel free to open issues, join as a contributor or star the repository. Thanks in advance!

Object Mapping advanced features & QoL with Java

Aviv Mor — Thu, 08 Sep 2022 12:04:01 +0000

This is the Java version of the Kotlin article.

When working with multi-layered applications, external libraries, a legacy code base or external APIs, we are often required to map between different objects or data structures.

In this tutorial, we will check out some Object Mapping libraries advanced features to simplify this task while saving development and maintenance time.

In our examples we will use the library ShapeShift. It's a light-weight object mapping library for Java/Kotlin with lots of cool features.

Auto Mapping

We will start with a bang. Auto mapping can and will save you lots of time and boiler-plate code. Some applications require manual mapping between objects, but most applications will save tons of time working on boring boiler-plate by just using this one feature. And it gets even better, with ShapeShift's default transformers we can even use automatic mapping between different data types.

Simple Mapping

Let's start with a simple example for auto mapping. We have our two objects, imagine they could also have tens, hundreds, or even thousands (for the crazy people here) of fields.

public class User {
    private String id;
    private String name;
    private String email;
    private String phone;
    // Getters, Setters, Constructors, Equals...
}

public class UserDTO {
    private String id;
    private String name;
    private String email;
    private String phone;
    // Getters, Setters, Constructors, Equals...
}

We want to map all the field from User to UserDTO. Using auto mapping we don't need to write any boiler-plate code. The mapper will be defined as follow:

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(User.class, UserDTO.class)
        .autoMap(AutoMappingStrategy.BY_NAME_AND_TYPE)
        .build();

Voila! All the fields will be mapped automatically without any manual boiler-plate code.

Advanced Mapping

In this example we will use the power of default transformers to take auto mapping even further.

public class User {
    private String id;
    private String name;
    private Date birthDate;
    // Getters, Setters, Constructors, Equals...
}

public class UserDTO {
    private String id;
    private String fullName;
    private Long birthDate;
    // Getters, Setters, Constructors, Equals...
}

Note that the types of the birthDate field are different in the source and destination classes. But using the power of default transformers we can still use auto mapping here.

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(User.class, UserDTO.class)
        .autoMap(AutoMappingStrategy.BY_NAME)
        .build();

We changed the auto mapping strategy to BY_NAME so it will map fields also with different types. Now we need to register a default transformer to the ShapeShift instance in order for it to know how to transform Date to Long.

ShapeShift shapeShift = new ShapeShiftBuilder()
        .withTransformer(
                Date.class, 
                Long.class, 
                new DateToLongMappingTransformer(), 
                true // Default Transformer
        )
        .build();
    }

We can also add manual mapping on top of the auto mapping in order to add/change behavior. The source and destination classes have different names for the name field so we will add manual mapping for it.

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(User.class, UserDTO.class)
        .autoMap(AutoMappingStrategy.BY_NAME)
        .mapField("name", "fullName")
        .build();

Auto mapping is great for use cases that does not require specific mapping. It helps reduce the amount manual boiler-plate code needed to configure mapping and also helps you keep your sanity.

Transformers

Transformers are very useful feature that allows you to transform the type/value of a field to a different type/value when mapping a field.

Some use cases we have been using widely:

Transform date to long and vice versa between server and client objects.
Transform JSON string to it's actual type and vice versa between server and client objects.
Transform comma separated string to list of enums.
Transform another object id to its object or one of its fields from the DB using Spring transformers.

Basic Transformers

We will start with a simple transformer example. Date-to-Long and Long-to-Date transformers:

public class DateToLongMappingTransformer implements MappingTransformer<Date, Long> {
    @Nullable
    @Override
    public Long transform(@NonNull MappingTransformerContext<? extends Date> context) {
        return context.getOriginalValue() != null ? context.getOriginalValue().getTime() : null;
    }
}

public class LongToDateMappingTransformer implements MappingTransformer<Long, Date> {
    @Nullable
    @Override
    public Date transform(@NonNull MappingTransformerContext<? extends Long> context) {
        return context.getOriginalValue() != null ? new Date(context.getOriginalValue()) : null;
    }
}

All we need to do now is to register them.

ShapeShift shapeShift = new ShapeShiftBuilder()
        .withTransformer(Date.class, Long.class, new DateToLongMappingTransformer(), true) // "true" is optional, we are registering the transformers as default transformers, more on that later.
        .withTransformer(Long.class, Date.class, new LongToDateMappingTransformer(), true)
        .build();

That's it! We can now use the transformers when mapping objects.

public class User {
    private String id;
    private String name;
    private Date birthDate;
    // Getters, Setters, Constructors, Equals...
}

public class UserDTO {
    private String id;
    private String name;
    private Long birthDate;
    // Getters, Setters, Constructors, Equals...
}

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(User.class, UserDTO.class)
        .mapField("id", "id")
        .mapField("name", "name")
        .mapField("birthDate", "birthDate").withTransformer(DateToLongMappingTransformer.class) // We don't have to state the transformer here because it is a default transformer
        .build();

Inline Transformers

In some use cases we want to transform the value but we don't need a reusable transformer and we don't want to create a class just for a one time use.

Inline transformers for the rescue! Inline transformers allow to transform the value without the need to create and register and transformer.

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(Source.class, Target.class)
        .mapField("birthDate", "birthYear").withTransformer(context -> context.getOriginalValue() != null ? ((Date) context.getOriginalValue()).getYear() : null)
        .build();

Advanced Transformers

Transformers also allow us to do transformations with the DB or other data sources.

In this example we will use the power of the Spring Boot integration to create transformers with DB access.

We have three models:

Job - DB entity.
User - DB entity.
UserDTO - Client model.

public class Job {
    private String id;
    private String name;
    // Getters, Setters, Constructors, Equals...
}

public class User {
    private String id;
    private String jobId;
    // Getters, Setters, Constructors, Equals...
}

public class UserDTO {
    private String id;
    private String jobName;
    // Getters, Setters, Constructors, Equals...
}

We want to convert the jobId on User to jobName on UserDTO by querying the job from the DB and setting it on the DTO.

In Spring's case, you generally avoid interaction with the application context from static functions or functions on domain objects.

We will use a ShapeShift's Spring integration to create a component as a transformer to access our DAO bean.

@Component
public class JobIdToNameTransformer implements MappingTransformer<String, String> {

    @Autowired
    private JobDao jobDao;

    @Nullable
    @Override
    public String transform(@NonNull MappingTransformerContext<? extends String> context) {
        if (context.getOriginalValue() == null) {
            return null;
        }
        Job job = jobDao.findJobById(context.getOriginalValue());
        return job.getName();
    }
}

All that's left to do is to use this transformer in our mapping.

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(User.class, UserDTO.class)
        .mapField("id", "id")
        .mapField("jobId", "jobName").withTransformer(JobIdToNameTransformer.class)
        .build();

Another bonus of using transformers is their reusability. In some use cases, We could create more generic transformers that will have application-wide usage.

Default Transformers

When registering transformers you can indicate wether a transformer is a default transformer. A default transformer of types <A, B> is used when you map a field of type <A> to field of type <B> without specifying a transformer to be used.

As we already seen, default transformers are useful for recurring transformations and especially for automatic mapping.

Deep Mapping

What if we want to map from/to fields that available inside a field which is an object? We can even do that, easily.

In order to access child classes we can use the full path of a field. Let's look at the following example.

public class From {

    private Child child = new Child();
    // Getters, Setters, Constructors, Equals...

    class Child {
        private String value;
        // Getters, Setters, Constructors, Equals...
    }
}

public class To {
    private String childValue;
    // Getters, Setters, Constructors, Equals...
}

We want to map the value field in Child class inside the From class to the childValue field in the To class. We will use the full path of value which is child.value.

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(From.class, To.class)
        .mapField("child.value", "childValue")
        .build();

The full path is supported in both source and destination fields, it also supports multi level depth (e.g. x.y.z).

Conditional Mapping

Conditions allow us to add a predicate to a specific field mapping to determine whether this field should be mapped.

Using this feature is as easy as creating a condition.

public class NotBlankStringCondition implements MappingCondition<String> {
    @Override
    public boolean isValid(@NonNull MappingConditionContext<String> context) {
        return context.getOriginalValue() != null && !context.getOriginalValue().trim().isEmpty();
    }
}

And adding the condition to the desired field mapping.

public class SimpleEntity {
    private String name;
    // Getters, Setters, Constructors, Equals...
}

public class SimpleEntityDisplay {
    private String name = "";
    // Getters, Setters, Constructors, Equals...
}

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(SimpleEntity.class, SimpleEntityDisplay.class)
        .mapField("name", "name")
        .withCondition(NotBlankStringCondition.class)
        .build();

Inline Conditions

Like transformers, conditions can also be added inline using a function.

MappingDefinition mappingDefinition = new MappingDefinitionBuilder(SimpleEntity.class, SimpleEntityDisplay.class)
        .mapField("name", "name")
        .withCondition(context -> context.getOriginalValue() != null && !((String) context.getOriginalValue()).trim().isEmpty())
        .build();

Annotations Mapping

This specific feature receives lots of hate because it breaks the separation of concerns principle. Agreed, this could be an issue in some applications, but in some use cases where all objects are part of the same application it can also be very useful to configure the mapping logic on top of the object. Check out the documentation and decide for yourself.

Conclusion

Object mapping libraries are not the solution for every application. For small, simple applications using boiler-plate mapping functions are more than enough. But, when developing larger, more complex applications, object mapping libraries can take your code to the next level, saving you development and maintenance time. All of these while reducing the amount of boiler-plate code and overall improving the development experience.

On a personal note, I used to work with manual mapping functions and was ok with it. It was "just" some simple lines of code. After upgrading our applications to use object mapping as part of our "boiler-plate free" framework (We will discuss that framework at a later time), I can't go back. Now we spend more time on what's important and interesting and almost no time on boring boiler-plate code.

Object Mapping advanced features & QoL with Kotlin

Aviv Mor — Tue, 09 Aug 2022 18:33:31 +0000

When working with multi-layered applications, external libraries, a legacy code base or external APIs, we are often required to map between different objects or data structures.

In this tutorial, we will check out some Object Mapping libraries advanced features to simplify this task while saving development and maintenance time.

In our examples we will use the library ShapeShift. It's a light-weight object mapping library for Kotlin/Java with lots of cool features.

Auto Mapping

Simple Mapping

Let's start with a simple example for auto mapping. We have our two objects, imagine they could also have tens, hundreds, or even thousands (for the crazy people here) of fields.

class User {
    var id: String = ""
    var name: String? = null
    var email: String? = null
    var phone: String? = null
}

class UserDTO {
    var id: String = ""
    var name: String? = null
    var email: String? = null
    var phone: String? = null
}

We want to map all the field from User to UserDTO. Using auto mapping we don't need to write any boiler-plate code. The mapper will be defined as follow:

val mapper = mapper<User, UserDTO> {
    autoMap(AutoMappingStrategy.BY_NAME_AND_TYPE)
}

Voila! All the fields will be mapped automatically without any manual boiler-plate code.

Advanced Mapping

In this example we will use the power of default transformers to take auto mapping even further.

class User {
    var id: String = ""
    var name: String? = null
    var birthDate: Date? = null
}

class UserDTO {
    var id: String = ""
    var fullName: String? = null
    var birthDate: Long? = null
}

Note that the types of the birthDate field are different in the source and destination classes. But using the power of default transformers we can still use auto mapping here.

val mapper = mapper<User, UserDTO> {
    autoMap(AutoMappingStrategy.BY_NAME)
}

val shapeShift = ShapeShiftBuilder()
    .withTransformer(DateToLongMappingTransformer(), true)
    .build()

val mapper = mapper<User, UserDTO> {
    autoMap(AutoMappingStrategy.BY_NAME)
    User::name mappedTo UserDTO::fullName
}

Auto mapping is great for use cases that does not require specific mapping. It helps reduce the amount manual boiler-plate code needed to configure mapping and also helps you keep your sanity.

Transformers

Transformers are very useful feature that allows you to transform the type/value of a field to a different type/value when mapping a field.

Some use cases we have been using widely:

Transform date to long and vice versa between server and client objects.
Transform JSON string to it's actual type and vice versa between server and client objects.
Transform comma separated string to list of enums.
Transform another object id to its object or one of its fields from the DB using Spring transformers.

Basic Transformers

We will start with a simple transformer example. Date-to-Long and Long-to-Date transformers:

class DateToLongMappingTransformer : MappingTransformer<Date, Long> {
    override fun transform(context: MappingTransformerContext<out Date>): Long? {
        return context.originalValue?.time
    }
}

class LongToDateMappingTransformer : MappingTransformer<Long, Date> {
    override fun transform(context: MappingTransformerContext<out Long>): Date? {
        context.originalValue ?: return null
        return Date(context.originalValue)
    }
}

All we need to do now is to register them.

val shapeShift = ShapeShiftBuilder()
    .withTransformer(DateToLongMappingTransformer(), true) // "true" is optional, we are registering the transformers as default transformers, more on that later.
    .withTransformer(LongToDateMappingTransformer(), true)
    .build()

That's it! We can now use the transformers when mapping objects.

class User {
    var id: String = ""
    var name: String? = null
    var birthDate: Date? = null
}

class UserDTO {
    var id: String = ""
    var name: String? = null
    var birthDate: Long? = null
}

val mapper = mapper<User, UserDTO> {
    User::id mappedTo UserDTO::id
    User::name mappedTo UserDTO::name
    User::birthDate mappedTo UserDTO::birthDate withTransformer DateToLongMappingTransformer::class // We don't have to state the transformer here because it is a default transformer
}

Inline Transformers

In some use cases we want to transform the value but we don't need a reusable transformer and we don't want to create a class just for a one time use.

Inline transformers for the rescue! Inline transformers allow to transform the value without the need to create and register and transformer.

val shapeShift = ShapeShiftBuilder()
        .withMapping<Source, Target> {
            // Map birthDate to birthYear with a transformation function
            Source::birthDate mappedTo Target::birthYear withTransformer { (originalValue) ->
                originalValue?.year
            }
        }
        .build()

Advanced Transformers

Transformers also allow us to do transformations with the DB or other data sources.

In this example we will use the power of the Spring Boot integration to create transformers with DB access.

We have three models:

Job - DB entity.
User - DB entity.
UserDTO - Client model.

class Job {
    var id: String = ""
    var name: String = ""
}

class User {
    var id: String = ""
    var jobId: String? = null
}

class UserDTO {
    var id: String = ""
    var jobName: String? = null
}

We want to convert the jobId on User to jobName on UserDTO by querying the job from the DB and setting it on the DTO.

In Spring's case, you generally avoid interaction with the application context from static functions or functions on domain objects.

We will use a ShapeShift's Spring integration to create a component as a transformer to access our DAO bean.

@Component
class JobIdToNameTransformer(
    private val jobDao: JobDao
) : MappingTransformer<String, String>() {
    override fun transform(context: MappingTransformerContext<out String>): String? {
        context.originalValue ?: return null
        val job = jobDao.findJobById(context.originalValue!!)
        return job.name 
    }
}

All that's left to do is to use this transformer in our mapping.

val mapper = mapper<User, UserDTO> {
    User::id mappedTo UserDTO::id
    User::jobId mappedTo UserDTO::jobName withTransformer JobIdToNameTransformer::class
}

Another bonus of using transformers is their reusability. In some use cases, We could create more generic transformers that will have application-wide usage.

Default Transformers

As we already seen, default transformers are useful for recurring transformations and especially for automatic mapping.

Deep Mapping

What if we want to map from/to fields that available inside a field which is an object? We can even do that, easily.

In order to access child classes we can use the .. operator. Let's look at the following example.

class From {
    var child: Child = Child()

    class Child {
        var value: String?
    }
}

class To {
    var childValue: String?
}

We want to map the value field in Child class inside the From class to the childValue field in the To class. We will create a mapper with the .. operator.

val mapper = mapper<From, To> {
    From::child..From.Child::value mappedTo To::childValue
}

Let's take it one step further with multi level depth.

class From {
    var grandChildValue: String?
}

class To {
    var child: Child = Child()

    class Child {
        var grandChild: GrandChild = GrandChild()
    }

    class GrandChild {
        var value: String?
    }
}

To access the grand child field we just use the .. operator twice.

val mapper = mapper<From, To> {
    From::grandChildValue mappedTo To::child..To.Child::grandChild..To.GrandChild::value
}

Conditional Mapping

Conditions allow us to add a predicate to a specific field mapping to determine whether this field should be mapped.

Using this feature is as easy as creating a condition.

class NotBlankStringCondition : MappingCondition<String> {
    override fun isValid(context: MappingConditionContext<String>): Boolean {
        return !context.originalValue.isNullOrBlank()
    }
}

And adding the condition to the desired field mapping.

data class SimpleEntity(
    val name: String
)

data class SimpleEntityDisplay(
    val name: String = ""
)

val mapper = mapper<SimpleEntity, SimpleEntityDisplay> {
    SimpleEntity::name mappedTo SimpleEntityDisplay::name withCondition NotBlankStringCondition::class
}

Inline Conditions

Like transformers, conditions can also be added inline using a function.

val mapper = mapper<SimpleEntity, SimpleEntityDisplay> {
    SimpleEntity::name mappedTo SimpleEntityDisplay::name withCondition {
        !it.originalValue.isNullOrBlank()
    }
}

Annotations Mapping

Conclusion

Open source, philosophy, hate & other random words

Aviv Mor — Tue, 02 Aug 2022 12:49:29 +0000

Some time ago our team has released our first open source library to the wild. We finished our first production ready version, posted it on Reddit and waited for the open source community to welcome us with open arms. After all, we are investing our own free time to create a great product to help others, and it's all for FREE.

Oh how naive we were... Of course some truly appreciated our contribution, yet others didn't understand what we are doing, and the crème de la crème just wanted to hate.

I think that in today's world it's hard to put your work out there. When you post your code you feel very vulnerable, a bit naked. It's like your soul is out there for everyone to see and criticize. And don't get me wrong, I think criticism is very important and it's one of the best ways to learn and grow.

On the other hand, it's very easy to completely dismiss someone else's work. It takes almost no time and costs nothing. Also I'm pretty sure some people enjoy it very much.

So when you meet someone like that, how should you react? The first instinct is to ignore or "yell" back, dismiss all criticism completely and move forward. I decided to do otherwise, breathe and count from 1 to 10, slowly, like my mom used to say, read it again, and think where it is coming from.

For example, in one of these scenarios a comment ended with "I would stay away from it" because of a disagreement with the project's coding style. Spoiler: after a few back and forths the conversation ended with "Good luck though!". How about that?

What is crazy and beautiful about programming. We think it is objective, that it is exact science and there is right and wrong. But the truth is, it is also art, and there is a huge subjective component to it.

What I realized is just that my coding philosophy is different. Even though we are still in a disagreement, it was fascinating to learn that there are completely different points of view for doing the exact same thing, and I learned a thing or two in the process.

What is the point of all of this? I think open source is amazing. For some reason we have crazy drive to develop stuff for free just to share it with the world and help others. Nonetheless, I think there is a lot of room for improvement in our discussions and critique. Maybe I'm naive again, however I still believe the community, our community can do better and hope for better communication between us all (and hopefully over a beer).

If you would like to check out our open source library and leave feedback we would appreciate it greatly.

My journey to defeat the evil boiler-plate code

Aviv Mor — Mon, 18 Jul 2022 10:16:00 +0000

A long time ago when I was about to finish university and just above junior level programmer, I joined a new company and received their organized, fresh out of the oven, MVP code.

The code was written by an Ukrainian developer I have never met, but loved in my heart. It wasn't the first time I saw a layered application, but it was the best of times.
She put everything there, clean controllers layer for the API, service layer to handle process logic, handlers layer to tackle fine grained actions, and of course DAO layer to handle all the DB stuff. From then on, all my future projects followed her beautiful layering and everything was better.

Fast forward a couple of years, my partner and I are now managing the R&D team somewhere (not interesting & not important). Like most teams, we are being swamped with feature requests, and other bullshit the management finds "CRITICAL". Our code-base is still quite organized with the layering we know and love but we start noticing some issues (Add dramatic sound...).

Every time we need to add a new CRUD entity to the system, even the most basic entity for some kind of configuration, we need to add A LOT of boiler plate code. We start by copying an existing entity code, then:

Update the controller with the new entity. Clean not relevant code.
Update the service with the new entity, again. Clean not relevant code.
Update the handler with the new entity, again... Clean not relevant code.
Update the DAO with the new entity, again....... Clean not relevant code.

The next image is not for the faint of heart. It contains the boiler-plate code required for one the SIMPLEST use cases. The horror!

Just writing it and remembering the old times made me tired. And more important, adding the new entity is the easy part, now we have more code we need to maintain. Our code base is growing and doing system wide changes becomes impossible.

Then one day, we are on a flight to some conference, disconnected from the world and connected to our inner thoughts (no wifi...). My partner, comes to me and say, "What if we develop a generic CRUD framework without boiler-plate, just add an entity and everything else is available in seconds". At first I was skeptical, but he is the smart one between us so I give it another thought and decides to roll with it.

Fast forward again, my partner and his trusted sidekick have kept their promise and delivered their boiler-plate free CRUD framework, after countless of fights and iterations (to this day). I don't want to bore you with too much code, but I just have to show a simple example to honor everything we lost along the way.

@Entity
@Table(name = "example")
@DefaultMappingTarget(ExampleDisplay::class)
class Example(
    @MappedField
    @Column
    var exampleString: String?,

    @MappedField
    @Column
    var exampleBoolean: Boolean?,

    // ...

) : AbstractJpaEntity()

@DefaultMappingTarget(Example::class)
data class ExampleDisplay(
    @MappedField
    var exampleString: String? = null,

    @MappedField
    var exampleBoolean: Boolean? = null,

    // ...

) : AbstractJpaDisplay()

@RestController
@RequestMapping("example")
class ExampleController : BaseCRUDController<Example, ExampleDisplay>() {
}

That's it! Now I know what you are going to tell me. Where are your layers that you couldn't shut up about?! The beautiful thing is, they are all here. Behind the scenes the framework has all the layers and it allows you to use hooks and other mechanisms to add additional logic/frameworks/...
Since then, the smart guys have added permissions, security and more on top of the CRUD framework, according to the requirements of each project.

So your next thought is probably "Where do I sign?". Hold your horses for a moment, I know your honest current thought is that I'm stupid and I know nothing, fair. Also I would be happy to give you the CRUD framework but it's not truly open source ready. If you want to take a look anyway it's available here.

Because it's a large framework and it will take time to bring it to the level that we want for an open source release, we decided to start small and separate our object mapping capabilities into a separate library. Of course the hardest part was to find a name for this library but in the end we settled for ShapeShift.

If you are not sure what is object mapping or why you need it you can read more about it here.

If you have any thoughts/comments/disses you would like to throw at me I would be more than happy to connect.

Kotlin Object Mapping - Pros & Cons

Aviv Mor — Wed, 01 Jun 2022 13:36:00 +0000

What is Object Mapping?

Multi-layered applications often have similar but different object models, where the data in two models may be similar but the structure and concerns of the models are different.
Writing the mapping code is a tedious and error-prone task. Object mapping makes it easy to convert one model to another.

Simple Example

Let's say we have a REST API application with two models. One for the server and one client facing:

User (Server):

data class User(
    val id: String,
    val name: String,
    val email: String,
    // isBlocked is server side only
    val isBlocked: Boolean
)

UserDTO (Client):

data class UserDTO(
    val id: String,
    val name: String,
    val email: String
)

Conversion

We have a couple of options:

Extension Methods

We can use simple extension methods.

fun User.toUserDTO(): UserDTO {
    return UserDTO(id, name, email)
}

Simple and easy, but requires additional boiler-plate code we need to maintain every time we change the model.

Object Mapping

We will use the open source object mapping library ShapeShift for the examples.

Annotations

The first step is to add the annotations to the fields we want to map.

@DefaultMappingTarget(UserDTO::class)
data class User(
    @MappedField
    var id: String = "",
    @MappedField
    var name: String = "",
    @MappedField
    var email: String = "",
    // isBlocked is server side only and not mapped to client DTO
    var isBlocked: Boolean = false
)

All that's left is to convert.

val shapeShift = ShapeShiftBuilder().build()
val user = User("xyz", "john doe", "john@email.com", false)
val userDTO = shapeShift.map<UserDTO>(user)

DSL

In some cases we can't change the data classes code (or don't want to). For these use cases we create a standalone mapper between the two classes using Kotlin DSL.

val mapper = mapper<User, UserDTO> {
    User::id mappedTo UserDTO::id
    User::name mappedTo UserDTO::name
    User::email mappedTo UserDTO::email
}

And now the conversion. Note that we are registering the mapper to the ShapeShift instance.

val shapeShift = ShapeShiftBuilder().withMapping(mapper).build()
val user = User("xyz", "john doe", "john@email.com", false)
val userDTO = shapeShift.map<UserDTO>(user)

Seems like a lot of work for a simple conversion, right? Maybe... Let's continue to the next example.

Auto Mapping

What if I told you there is a way to remove almost if not all the mapping boiler-plate code? In many use cases we have similar classes we need to map between. This is where automatic mapping comes to the rescue.

Let's continue with the same classes.

data class User(
    val id: String,
    val name: String,
    val email: String,
    val isBlocked: Boolean
)

data class UserDTO(
    val id: String,
    val name: String,
    val email: String
)

Using automatic mapping our mapper will be the following.

val mapper = mapper<User, UserDTO> {
    autoMap(AutoMappingStrategy.BY_NAME_AND_TYPE)
}

Voila! No boiler-plate code to configure fields manually. Auto mapping also comes with advanced features for more complex use cases.

Generic Example

When our projects start to scale, we want to add generic functionality to improve productivity and decrease maintenance. For example:

Generic CRUD controller for entities.
Generic export to excel/pdf/...

In order for us to be able to implement these generic functionality we need to be able to convert our objects back and forth between classes.

We can use the factory method pattern to do it, simple and straightforward, but agin requires more boiler-plate code we need to maintain when we add new models.

Another option is (surprise surprise) to use object mapping.

inline fun <reified ExportModel : Any> export(model: Any) {
    val shapeShift = ShapeShiftBuilder().build()
    val exportModel = shapeShift.map<ExportModel>(model)
    // export logic...
}

val user = User(/*...*/)
export<UserExport>(user)

That's it. Zero boiler-plate code and we got ourselves the generic functionality we know and love.

Type Safety

Let's take it further and add type safety to the export method. For that we will add two interfaces:

interface ExportModel {
}

interface BaseModel<EM: ExportModel> {
}

Now we will update our classes to implement the interfaces.

class UserExport: ExportModel {
    // ...
}

class User: BaseModel<UserExport> {
    // ...
}

And change our generic method respectively.

inline fun <reified EM : ExportModel> export(model: BaseModel<EM>) {
    val shapeShift = ShapeShiftBuilder().build()
    val exportModel = shapeShift.map<EM>(model)
    // export logic...
}

That's it. We got ourselves type safe generic export method.

val user = User(/*...*/)
export(user)

Spring Example

Taking it up a notch to the next level. We have three models.

Job - DB entity.
User - DB entity.
UserDTO - Client model.

@Entity
@Table(name = "jobs")
class Job {
    var id: String = ""
    var name: String = ""
}

@Entity
@Table(name = "users")
class User {
    var id: String = ""
    var jobId: String? = null
}

class UserDTO {
    var id: String = ""
    var jobName: String? = null
}

We need to convert the jobId on User to jobName on UserDTO by querying the job from the DB and setting it on the DTO.

In Spring's case, you generally avoid interaction with the application context from static functions or functions on domain objects and because of that they cannot be invoked from extensions.

Object mapping to the rescue (surprise!). Let's create a custom transformer to do the heavy lifting for us.

@Component
class JobIdToNameTransformer(
    private val jobDao: JobDao
) : MappingTransformer<String, String>() {
    override fun transform(context: MappingTransformerContext<out String>): String? {
        context.originalValue ?: return null
        val job = jobDao.findJobById(context.originalValue!!)
        return job.name 
    }
}

The complicated part is over. Now we just need to add the annotations to the User model.

@Entity
@Table(name = "users")
@DefaultMappingTarget(UserDTO::class)
class User {
    @MappedField
    var id: String = ""
    @MappedField(transformer = JobIdToNameTransformer::class, mapTo = "jobName")
    var jobId: String? = null
}

That's all. The great part is that we can use the same transformer every time we need to convert a job id to job name on any model.

val shapeShift = ShapeShiftBuilder().build()
val user = User(/*...*/)
val userDTO = shapeShift.map<UserDTO>(user)

A full spring example code is available here.

Pros & Cons

Each conversion method has its own pros & cons.

Extension Methods

Pros

Simple implementation.
Clear code - no annotations "magic".

Cons

Lots of boiler plate code.
Limited functionality.
Does not scale well.

Object Mapper

Pros

Little to none boiler-plate code.
Auto mapping.
Generic code.
Advanced features.
Code reuse.

Cons

Requires to learn new library.
Annotations "magic".

Summary

Like most things in development, there is no right answer here. The answer is that it depends on the project. For small simple projects extension methods are more than enough to convert classes, but for large enterprise projects using an object mapper can give the freedom to achieve better architecture and more generic code that can keep moving forward with large codebase and lots of models.