Clojure Is Awesome!!! [PART 14]

Exploring the Property Pattern: From C# to Clojure with a Functional Perspective

Continuing our series, today we’ll dive into an interesting concept that has recently gained prominence in C#: the Property Pattern. Originally conceived in the context of object-oriented programming, our challenge will be to translate it into our world, using Clojure, of course.
We’ll explore what this pattern is, why it was created, its importance, and how we can implement it in Clojure, bringing practical examples and use cases that highlight its advantages.

What is the Property Pattern and What Problem Does It Solve?

The Property Pattern is an addition to C#’s pattern matching system, introduced to make checking an object’s properties more expressive and concise. Before it, in object-oriented languages like C#, it was common to write verbose code with multiple conditionals (if) to verify property values, often resulting in:

• Repetitive Code: Nested conditionals or multiple manual checks.
• Lack of Readability: Scattered logic made it hard to understand at a glance.
• Complicated Maintenance: Changes to a data structure required adjustments in multiple parts of the code.

Imagine a scenario where you need to check if a user has a "premium" profile based on properties like subscriptionActive and planType. In C#, without the Property Pattern, you might have something like this:

if (user.SubscriptionActive && user.PlanType == "Premium") {
    // Logic for premium users
}

With the Property Pattern in C# (starting from C# 8.0), it becomes more elegant:

if (user is { SubscriptionActive: true, PlanType: "Premium" }) {
    // Logic for premium users
}

The problem it solves is clear: it reduces verbosity and centralizes property validation logic, making the code more declarative. But why does this matter? In complex systems, where objects have many properties and business rules, this approach improves readability, reduces errors, and makes code evolution easier.

Why Does the Property Pattern Matter?

The Property Pattern isn’t just about aesthetics. It brings real benefits:

1. Expressiveness: It says what you want to check, not how to check it.
2. Safety: It avoids manual errors in multiple comparisons.
3. Maintenance: It centralizes validation logic, making refactoring simpler.
4. Scalability: It works well with objects that have many properties or conditional rules.

Now, let’s bring this into the functional world with Clojure. How can we adapt this pattern in a language that prioritizes immutability and avoids mutable state?

Implementing the Property Pattern in Clojure

In Clojure, we don’t have objects with mutable properties like in C#. Instead, we work with immutable maps (hash-maps), which are perfect for representing structured data. The Property Pattern can be reinterpreted as a way to concisely check patterns in maps, using pure functions and functional composition.

Let’s create a functional implementation that mirrors the spirit of the Property Pattern. Here’s the code:

(ns devto.property-pattern
  (:require [clojure.spec.alpha :as s]))

(s/def ::subscription-active boolean?)
(s/def ::plan-type #{"Basic" "Premium" "Enterprise"})
(s/def ::user (s/keys :req-un [::subscription-active ::plan-type]))

(defn matches-properties?
  "Checks if a map satisfies a set of expected properties.
   Args:
     data - Input map to be checked.
     expected - Map with the expected properties.
   Returns:
     Boolean indicating if all properties match."
  [data expected]
  (every? (fn [[k v]]
            (= (get data k) v))
          expected))

(defn process-user
  "Processes a user based on their properties, applying the corresponding logic.
   Args:
     user - Map representing the user.
   Returns:
     String with the processing result or an error message if the user data is invalid"
  [user]
  (if (s/valid? ::user user)
    (cond
      (matches-properties? user {:subscription-active true :plan-type "Premium"})
      "Welcome, Premium user!"

      (matches-properties? user {:subscription-active true :plan-type "Enterprise"})
      "Welcome, Enterprise user with exclusive benefits!"

      :else
      "Inactive subscription or basic plan. Consider upgrading!")
    (str "Invalid user data: " (s/explain-data ::user user))))

Explaining the Code

• matches-properties?: A pure function that checks if a map (data) contains the expected properties (expected). It uses every? to ensure all keys and values match, keeping the logic simple and reusable.
• process-user: Uses the functional Property Pattern to match patterns and apply specific logic. The cond here works like C#’s pattern matching, but in an idiomatic Clojure way.

Let’s test it:

;; Usage examples
(def user-premium {:subscription-active true :plan-type "Premium"})
(def user-basic {:subscription-active false :plan-type "Basic"})
(def user-enterprise {:subscription-active true :plan-type "Enterprise"})

(println (process-user user-premium))      ;; "Welcome, Premium user!"
(println (process-user user-basic))        ;; "Inactive subscription or basic plan. Consider upgrading!"
(println (process-user user-enterprise))   ;; "Welcome, Enterprise user with exclusive benefits!"

Practical Use Cases and Efficiency

Case 1: Configuration Validation
Imagine a system that needs to verify a server’s configuration:

(def server-config {:active true :mode "production" :port 8080})

(when (matches-properties? server-config {:active true :mode "production"})
  (println "Server ready for production!"))

Here, the functional Property Pattern lets us quickly check if the server is in the right mode, without unnecessary conditionals.

Case 2: Data Filtering

Suppose we have a list of users and want to filter only active premium ones:

(def users [{:id 1 :subscription-active true :plan-type "Premium"}
            {:id 2 :subscription-active false :plan-type "Basic"}
            {:id 3 :subscription-active true :plan-type "Premium"}])

(def premium-users
  (filter #(matches-properties? % {:subscription-active true :plan-type "Premium"}) users))

(println premium-users)
;; ({:id 1, :subscription-active true, :plan-type "Premium"}
;;  {:id 3, :subscription-active true, :plan-type "Premium"})

The matches-properties? function is composed with filter, showing how the pattern integrates into functional workflows.

Improvements with the Property Pattern in Clojure

Adopting this functional approach brings clear advantages:

• Composition: We can combine matches-properties? with other functions like map, filter, or reduce, leveraging the power of functional programming.
• Readability: The logic becomes declarative ("what I want") rather than imperative ("how to do it").
• Reusability: The function is generic and can be used with any map, not just "users."
• Testability: Pure functions are easy to test since the output depends only on the input.

Conclusion

The Property Pattern, originally designed for the object-oriented world of C#, finds a natural home in Clojure when reinterpreted as a functional pattern matching tool. It solves real problems of readability and maintenance, offering an elegant approach to validating and processing structured data. Whether filtering users, validating configurations, or applying business rules, this technique can transform your code into something more expressive and robust.

What about you—have you used something similar in Clojure or another functional language? Share your experiences in the comments!