DEV Community: Lomig

Monads explained to my team — Part 4: The Maybe Monad

Lomig — Thu, 07 Jul 2022 21:04:48 +0000

So, in the last article we created a monad, but there's room for improvement — let's pimp it a little then!

For reference, here is the code from the last article:

class Box
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value

  def map
    return self unless value

    Box.new(yield(value))
  end

  def flat_map(&block)
    map(&block).flatten
  end

  def flatten
    return self unless value

    value
  end
end

Make it readable!

Let's rename the Box into something more abstract: it's full or empty, it wraps maybe something, maybe nothing — let's call it a Maybe object.

I'll also throw in a helper to ease initialization, and I'll override the default #inspect. (If you are not well versed into Ruby, it allows for the sweet examples below the class definition)

def Maybe(x) = Maybe.new(x)

class Maybe
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value

  def map
    return self unless value

    Maybe.new(yield(value))
  end

  def flat_map(&block)
    map(&block).flatten
  end

  def flatten
    return self unless value

    value
  end

  def to_s = "Maybe(#{value.inspect})"
  alias_method :inspect, :to_s
end

Maybe(nil).map { |x| x + 4 } #=> Maybe(nil)
Maybe(130).map { |x| x + 4 } #=> Maybe(134)

Thanks to inheritance, we also can make the difference between a Maybe_but_in_fact_no and a Maybe_but_in_fact_yes nicer: when a Maybe has a value, it's a Some, and if not, it's a None.

def Maybe(x) = Maybe.new(x).coerce

class Maybe
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value

  def map(&block) = coerce.map(&block)

  def flat_map(&block) = map(&block).flatten

  def flatten
    return self unless value

    value
  end

  def coerce
    return None.new unless value

    Some.new(value)
  end
end

class Some < Maybe
  def initialize(value)
    raise ArgumentError if value.nil?

    super
  end

  def map = Maybe.new(yield(value)).coerce

  def to_s = "Some(#{value.inspect})"
  alias_method :inspect, :to_s
end

class None < Maybe
  def initialize; end

  def map = self

  def to_s = "None"
  alias_method :inspect, :to_s
end

Maybe(nil).map { |x| x + 4 } #=> None
Maybe(130).map { |x| x + 4 } #=> Some(134)

Make it dry-like

The main gem providing monads to Ruby and Rails is called dry-monads. Of course, my implementation is quite naive compared to theirs, but let's rename our two mapping methods to follow their convention — even if some choices seem strange enough.

I'll change the code a last time as such:

rename #map as #fmap
rename #flat_map as #bind
add #none? and #some? methods

def Maybe(x) = Maybe.new(x).coerce

class Maybe
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value

  def fmap(&block) = coerce.fmap(&block)

  def bind(&block) = fmap(&block).flatten

  def flatten
    return self unless value

    value
  end

  def coerce
    return None.new unless value

    Some.new(value)
  end

  def none? = false
  def some? = false
end

class Some < Maybe
  def initialize(value)
    raise ArgumentError if value.nil?

    super
  end

  def fmap = Maybe.new(yield(value)).coerce

  def some? = true

  def to_s = "Some(#{value.inspect})"
  alias_method :inspect, :to_s
end

class None < Maybe
  def initialize; end

  def fmap = self

  def none? = true

  def to_s = "None"
  alias_method :inspect, :to_s
end

Maybe(nil).fmap { |x| x + 4 } #=> None
Maybe(130).fmap { |x| x + 4 } #=> Some(134)
Maybe(130).bind { |x| Maybe(x + 4) } #=> Some(134)

As a Rubyist, why do I care?

Ruby handles itself quite nicely regarding the Maybe monad, thanks to the safe navigation operator (&.).
Still, imagine a method that would be used to show the weather for the county of the user. In this example, there are special rules to get the county from the user's zipcode. It could go like that:

def regional_weather(user_id)
  return :unavailable unless user_id

  user = User.find(user_id)
  zipcode = user&.addresses&.first&.zipcode
  return :unavailable unless zipcode

  county = county_from_zipcode(zipcode)
  return :unavailable unless county

  WeatherAPI.call(county) || :unavailable
end

def county_from_zipcode(zipcode)
  return zipcode unless zipcode.match?(/^\d+$/)

  zip = zipcode[..1].to_i

  # Paris!
  return 75 if [77, 78, 91, 92, 93, 94, 95].include?(zip)

  zip
end

Let's use our Maybe monad:

def regional_weather(user_id)
  Maybe(user_id)
    .fmap { |user_id| User.find(user_id) }
    .fmap(&:addresses)
    .fmap(&:first)
    .fmap(&:zipcode)
    .fmap { |zipcode| county_from_zipcode(zipcode) }
    .fmap { |county| WeatherAPI.call(county) }
    .then { |result| return result.value! if result.some? }

  :unavailable
end

def county_from_zipcode(zipcode)
  return zipcode unless zipcode.match?(/^\d+$/)

  zip = zipcode[..1].to_i

  # Paris!
  return 75 if [77, 78, 91, 92, 93, 94, 95].include?(zip)

  zip
end

Arguably a simpler way of handling nil values, isn't it?

Going further

Dry-Monads

I hope that I have been able to explain what is a monad in a simple way as well as explaining the usual meme-prone face-palming definition.

But moreover, with this last article I hope that I have been able to show how monads can help a developer maintaining an healthy and clear codebase.

dry-monads is a wonderful gem which implements lots of monad patterns and a DSL to use them in a very efficient way in an existing codebase.

There are also a ton of useful mapping methods built-in in their monads, for example to unwrap results, letting you do things like:

def regional_weather(user_id)
  Maybe(user_id)
    .fmap { |user_id| User.find(user_id) }
    .fmap { |user| user&.addresses&.first&.zipcode }
    .fmap { |zipcode| county_from_zipcode(zipcode) }
    .fmap { |county| WeatherAPI.call(county) }
    .value_or { :unavailable }
end

That's brilliant!

Other Noteworthy Monads

You may find this video interesting when it comes to the Result monad which is used to handle failures and errors:

There is a wonderful article here by @baweaver — don't miss it.

Another common use case that you already heard of is Promise — but unfortunately JS Promises are not monads (it could have been, but unfortunately…)

A logger is also a classic use case of monads.

In any case, thanks for you attention, and merry functional programming!

Monads explained to my team — Part 3: Creating a monad

Lomig — Thu, 07 Jul 2022 20:52:35 +0000

Monoid, Endofunctors… Lots of theoretical pieces have been exposed in the 2 previous parts, but it's time to try and practice with Monads.

Once upon a time, there were boxes

Let's create a box, to store things like numbers.

The initializer puts the value inside the box
Box#value! unbox the value and gives it back.

class Box
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value
end

This box does not belong to Schrödinger

That looks utterly useless! So let's add a concept: these boxes can be full (with a value), or empty (value being nil).

So, what if we want to add 2 to such a boxed number?

The box is a container
We have to take its elements (even though there is only one here) and apply our function to add 2
We put back the element in the box, and then we return it

… and what if the box is empty? Well, we return an empty Box, then!

class Box
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value

  def add(x)
    return self unless value

    Box.new(value + x)
  end
end

Box.new(nil).add(4) #=> #<Box:0x0000000 @value=nil>
Box.new(130).add(4) #=> #<Box:0x0000000 @value=134>

Making the box content operation-agnostic

The code above is fine, but if we want to do something else than adding numbers, we would have to add methods all over for each operation. We can do better.

Is there a way to extract something from a container, apply a function to it, and put it back? It was the subject of the previous article: let's make it a functor!

class Box
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value

  def map
    return self unless value

    Box.new(yield(value))
  end
end

Box.new(nil).map { |x| x + 4 } #=> #<Box:0x0000000 @value=nil>
Box.new(130).map { |x| x + 4 } #=> #<Box:0x0000000 @value=134>

Nested boxes are the worst…

So, with a Box, we can perform actions on the content without any need to trouble ourselves checking for nil values where we are not in control!

def double(x) = 2 * x

user_count = Box.new(UserCountAPI.call)
#=> #<Box:0x0000000 @value=25>

shoes_count = user_count.map { |x| double(x) }
#=> #<Box:0x0000000 @value=50>

It's cool enough for us to use the Box at some different places in the code. But sometimes, it could create unforeseen problems; for an example, when we are unaware that a method already uses a Box:

def double(x) = Box.new(2 * x)

user_count = Box.new(UserCountAPI.call)
#=> #<Box:0x0000000 @value=25>

shoes_count = user_count.map { |x| double(x) }
#=> #<Box:0x0000000 @value=#<Box:0x0000000 @value=50>>

… a box inside a box? That's a problem!

To avoid such an issue, we would needs to implement a different #map method that would flatten the result: #flat_map

class Box
  private attr_reader :value

  def initialize(value)
    @value = value
  end

  def value! = value

  def map
    return self unless value

    Box.new(yield(value))
  end

  def flat_map(&block)
    map(&block).flatten
  end

  def flatten
    return self unless value

    value
  end
end

Box.new(nil).map { |x| x + 4 } #=> #<Box:0x0000000 @value=nil>
Box.new(130).map { |x| x + 4 } #=> #<Box:0x0000000 @value=134>
Box.new(130).flat_map { |x| Box.new(x + 4) } #=> #<Box:0x0000000 @value=134>

And there we have it! A monad is just that:

a mappable Box,
a method (Box.new) to put something in the Box,
a flat_map method as an extension of the map method.

That's a lot of fuss for something quite simple, right?

Useless bit of information

Monads are indeed monoids!

All Box instances (that are endofunctors) represent the monoid set
#flat_map is a closure. As per the first article:

Box.new(4).flat_map { |x| Box.new(2 * x) } #=> #<Box:0x0000000 @value=8>

# A_THING  COMBINED_WITH  ANOTHER_THING     => ANOTHER_THING

Box.new is the identity element

def double(x) = Box.new(2 * x)
content = 4

# == equality assuming we made Box be comparable
Box.new(content).flat_map { |x| double(x) } == double(content)

Box.new(content).flat_map { |x| Box.new(x) } == Box.new(content)

#flat_map is associative

def double(x) = Box.new(2 * x)
def triple(x) = Box.new(3 * x)
content = 4

a = Box.new(content).flat_map { |x| double(x) }
                    .flat_map { |x| triple(x) }

b = Box.new(content).flat_map do |x|
  double(x).flat_map { |y| triple(y) }
end

# == equality assuming we made Box be comparable
a == b

So what's next?

You can see that a monad is not that complicated a concept, even though its usefulness may not be clear right at once.

Don't worry, we'll develop real-ish example in the next article!

Monads explained to my team — Part 2: Endofunctors

Lomig — Thu, 07 Jul 2022 20:33:51 +0000

After talking about what monoids are in Part 1, and discovering that it was just a smart word for very simple things, let's discover the marvellous world of functors in this second part!

Fancy words for simple concepts

Developers uses functors everyday unknowingly, so let's figure out what this is all about.

`#map`

We all know #map, a method that we use and love as Rubyists.
It allows us to take a structure of any kind (in terms of Ruby, an Enumerable), and from within this structure, apply the same function to each of its elements.

savings_in_€ = [24.30, 350.90, -105.00]

#Brexit!
savings_in_£ = savings_in_€.map { |amount| (amount * 0.85).round(2) }
#=> [20.66, 298.27, -89.25]

savings_in_£.map { |amount| "£#{amount}" }
#=> ["£20.66", "£298.27", "£-89.25"]

The rules of `#map`

Of course, #map could be called anything else — the important part of this method is not its name, but the fact that it must follow some rules to be considered a real map!

Those are the two rules:

Rule of identity

any_array.map { |x| x } == any_array

Rule of composition

def multiply_by_two(x) = 2 * x
def add_three(x) = x + 3

a = [2, 5, 7].map { |x| multiply_by_two(add_three(x)) }
b = [2, 5, 7].map { |x| add_three(x) }
             .map { |x| multiply_by_two(x) }

a == b # [10, 16, 20]

So, what about Functors?

A functor is:

a structure that is mapable
that is polymorphic (ie that can contain any type)

In Ruby, it means that:

Arrays are functors
- ✅ can map internal elements
- ✅ respect map rules from above
Hashes are not functors
- ✅ can map internal elements
- ❌ does not respect map rules

And Endofunctors, then?

An endofunctor is a functor whose #map function will return a structure with the same type.

In Ruby, it means that Arrays are endofunctors
* ✅ takes an Array, and returns an Array

As a Rubyist, why do I care?

Functors, and more particularly endofunctors, allow for function composition and make it safe to chain any number of mapping:

Array.map { |x| x * 17 }
     .map { |x| x / 3 }
     .map(&:round)
     .map(&:to_s)

Ok, but for God's sake, what's the relevance with Monads?

Well, obviously, it's the definition of a monad!

But that's for the next article!

Monads explained to my team — Part 1: Monoids

Lomig — Thu, 07 Jul 2022 20:26:04 +0000

“Hey, for our next talk about growing and discovering new ways of thinking about programming, I wondered if you would be interested in learning about Monads?”, I asked on our Slack Channel.

“Sure, don't hesitate to share an article before we can discuss it together!” my CTO answered.

Problem is: for every batch of 20 developers trying to learn about monads, 15 will abandon because of awful tutorials, 3 will succeed quietly, hurt by awful tutorials, and 2 will succeed but will decide they could do better than the awful and confusing tutorials they found — to write even worse tutorials of their own.

Guess what kind of people I am?

So, sure. Let's do that: an article, or rather a series of articles taking us from the basic theory to a Ruby implementation of the concept.

The first two articles are not mandatory: it's tradition to explain monads through a diabolical mathematical description, and I feel I also have to make this explanation accessible, but it surely will be one of the reason why my own tutorial will be even worse than the cursed ones before me!

In any case, fasten your seatbelts, we will talk about Monoids!

Fancy words for simple concepts

Developers uses Monoids everyday unknowingly, so let's figure out what this is all about.

A little bit of Math

Composition

Let's look at this piece of code:

42 + 58 #=> 100

What do we see? Two things of the same kind combined together by an operator produce another thing of the same kind.

When combining two Int with the + operator, we will get an Int.

11 * 25 #=> 275

Again! A thing, combined with another thing of the same kind gives us a thing of the same kind.

There are a lot of examples built-in in Ruby:

"my " + "string" #=> "my string"
[1, 3] + [2, 8] #=> [1, 3, 2, 8]
{ a: :foo, b: :bar }.merge({ fizz: :buzz }) #=> { a: :foo, b: :bar, fizz: :buzz }
4 - 16 #=> -12

It does not work for every operation though: dividing an integer by another one can result in a non-integer number.

Useless bit of information

In Mathematics, when an operation between two things give the same thing, we call this operation a closed dyadic/binary operation for those things. + is a closed dyadic operation for integers.

Association

We can see that some types and operations have another interesting property:

"a"              # is a String ("a")
"a"  + "b"       # is a String ("ab")
"ab" + "c"       # is a String ("abc")
"a"  + "bc"      # is a String ("abc")
"a"  + "b" + "c" # is a String too! ("abc")
# [...]
("a" + "b") + "c" == "a" + ("b" + "c") #=> true

1 + 2 + 3 + 4 == (1 + 2) + (3 + 4)
              == 1 + (2 + 3) + 4
              == ((1 + 2) + 3) + 4

Here again, it does not work for every types/operations — integers and subtraction for example:

(1 - 2) - 3 #=> -1 - 3 == -4
1 - (2 - 3) #=> 1 - -1 == 2

(1 - 2) - 3 != 1 - (2 - 3)

Useless bit of information

In Mathematics, when rearranging the parentheses in an expression of things and an operation will not change the result, we call this operation an associative operation for those things. + is an associative operation for integers.

Special elements

There is a very special String that has a very interesting property : it changes nothing in a concatenation.

"" + "my string" == "my string" #=> true
"my string" + "" == "my string" #=> true

In the same way, we can find the same kind of special elements for other types and operations:

0 + 4 == 4                           #=> true
215 * 1 == 215                       #=> true
[:foo, :bar] + [] == [:foo, :bar]    #=> true
{ a: :foo }.merge({}) == { a: :foo } #=> true

Useless bit of information

In Mathematics, an element that leaves every element of a set unchanged through an operation is called the identity element. 0 is the identity element of + for integers.

So, what about Monoids?

And that's it, we have all what we need to define a monoid!

A monoid is a set and an operation where the operation is a closed dyadic operation, where the operation is associative, and where an identity element exists.

(Integer, +) is a monoid
(Float, +) is a monoid
(Array, #concat) is a monoid
…

As a Rubyist, why do I care?

The first rule of a monoid (we call it closure in computer science instead of closed dyadic operation) is linked to another functional concept already implemented in Ruby: monoids are reducible:

["c", "o", "o", "l"].reduce(&:+)    #=> "cool"
[2, 5, 7].reduce(&:*)               #=> 70
[[1, 2], [3], [4]].reduce(&:concat) #=> [1, 2, 3, 4]

The second rule, associativity makes those chained operations optimization-ready: Divide & Conquer strategies, parallel threads, incremental accumulation…
The third rule, the identity, gives you an initial value when the data is empty or does not exist yet.

But then, Monads?

Well, monads are a special kind of monoids — but we'll discuss that in another article!

A Walk Through the Gilded Rose Kata — Pt 5: Open to extension, closed to modification

Lomig — Mon, 12 Apr 2021 19:55:58 +0000

Consider the shape of our GildedRose application now, after 4 long and painful posts with me as your guest.

We traveled far, and now we have a factory using some CommonItem instances through polymorphism. Now we can concentrate on what Allison really wanted us to do: Add the possibility to deal with conjured items.

I can now implement such a functionality... nearly without editing the current codebase.

Adding Conjured Items

I do not like this task that much, because it breaks the nice symmetry we had: We don't want to apply the rule to an exact item name, but to a match.

If it was a complete string, I would not have to change the code at all, but hey, when life gives you lemons, you squeeze them in the eyes of those stupid else keywords.

Let us start with the said rules: A conjured item is similar to a common item with twice as much a decay. Fine.

class ConjuredItem < CommonItem
  def update
    item.sell_in -= 1

    item.quality -= 2
    item.quality -= 2 if item.sell_in < 0

    limit_quality
    self
  end
end

Now, we need our factory (GildedRose, that is to say) to create this ConjuredItem when needed.

def class_from(name:)
  return ConjuredItem if name.downcase.start_with?("conjured ")

  ITEM_CLASSES[name] || CommonItem
end

Done.

Yup, done. How cool and how simple is that?
This is the meaning of "Open to extension, closed to modification": We can add new behaviour without changing the existing code.

Quality of life: How I like to see Ruby code

We will complete the refactoring with my personal touch over this code. I like to handle concepts more than data.

What is item.sell_in -= 1? Right now, I kind of remember, but in two weeks, I am not so sure. Well, the concept is ages_one_day, and in 2 years, I will still understand what that means.

I do not like those item.quality +=1 neither, especially when afterwards I have to limit them.
I would prefer to increase_quality_up_to_fifty that would do both.

As soon as I stumble upon a concept, I shall extract it. Our AgedBrie will soon look like this:

class AgedBrie < CommonItem
  def update
    ages_one_day
    increase_quality_up_to_fifty
    increase_quality_up_to_fifty if expired?

    self
  end
end

And that's my last trick: This increase_quality repeated twice is quite strange. But we live in a wonderful world, the Ruby world: alias increase_quality_up_to_fifty increase_quality_up_to_fifty_again will allow me to write something more elegant as:

class AgedBrie < CommonItem
  def update
    ages_one_day
    increase_quality_up_to_fifty
    increase_quality_up_to_fifty_again if expired?

    self
  end
end

Final Code

I do not have a conclusion: as I said, I do consider that my approach has value, but there may be other interesting ways of solving this kata 😊

In any case, here is the final code (every class being in its own file):

require_relative("item")
require_relative("common_item")
require_relative("aged_brie")
require_relative("backstage")
require_relative("sulfuras")
require_relative("conjured_item")

class GildedRose
  ITEM_CLASSES = {
    "Aged Brie"                                 => AgedBrie,
    "Sulfuras, Hand of Ragnaros"                => Sulfuras,
    "Backstage passes to a TAFKAL80ETC concert" => Backstage
  }

  def initialize(items)
    @items = items.map { |item| class_from(name: item.name).new(item) }
  end

  def update_quality
    @items.each { |item| item.update }

    self
  end

  private

  def class_from(name:)
    return ConjuredItem if name.downcase.start_with?("conjured ")

    ITEM_CLASSES[name] || CommonItem
  end
end

class Item
  attr_accessor :name, :sell_in, :quality

  def initialize(name, sell_in, quality)
    @name = name
    @sell_in = sell_in
    @quality = quality
  end

  def to_s()
    "#{@name}, #{@sell_in}, #{@quality}"
  end
end

class CommonItem
  attr_reader :item

  def initialize(item)
    @item = item
  end

  def update
    ages_one_day
    decrease_quality_down_to_zero
    decrease_quality_down_to_zero_again if expired?

    self
  end

  private

  def ages_one_day
    item.sell_in -= 1
  end

  def expired?
    item.sell_in < 0
  end

  def decrease_quality_down_to_zero(time: 1)
    time.times { item.quality -= 1 if item.quality > 0 }
  end
  alias decrease_quality_down_to_zero_again decrease_quality_down_to_zero

  def increase_quality_up_to_fifty
    item.quality += 1 if item.quality < 50
  end
  alias increase_quality_up_to_fifty_again increase_quality_up_to_fifty
end

require_relative("common_item")

class AgedBrie < CommonItem
  def update
    ages_one_day
    increase_quality_up_to_fifty
    increase_quality_up_to_fifty_again if expired?

    self
  end
end

require_relative("common_item")

class Backstage < CommonItem
  def update
    ages_one_day
    item.quality = 0 and return self if expired?

    increase_quality_up_to_fifty
    increase_quality_up_to_fifty_again if item.sell_in < 10
    increase_quality_up_to_fifty_again if item.sell_in < 5

    self
  end
end

require_relative("common_item")

class Sulfuras < CommonItem
  def update
    self
  end
end

require_relative("common_item")

class ConjuredItem < CommonItem
  def update
    ages_one_day
    decrease_quality_down_to_zero(time: 2)
    decrease_quality_down_to_zero_again(time: 2) if expired?

    self
  end
end

A Walk Through the Gilded Rose Kata — Pt 4: Discovering what GildedRose really is

Lomig — Mon, 12 Apr 2021 11:08:16 +0000

In the last part, we left GildedRose in a very awkward position.

It is not a huge mess anymore (Good!)
It is not a huge conditional mess anymore (Even better!)
It is not a huge procedural conditional mess anymore...

... or is it?
It looks more OO, but in reality, is a mimicry: I just camouflaged bits of procedural code in objects.

Unfortunately, in my real life:

lots of the OO code I see looks like what we had in part 1;
most of the OO code I see looks like what we first created with smaller methods in part 2;
some well-behaved kids try OO and get to those small objects we created in part 3;
... and we are still in the middle of Faux-O. Oh, we did a HUGE step forward, it is just that we are not there yet.

But before continuing our Journey, a quite unrelated side-step, for you to understand why I did a part of what you will see in future code samples.

Good OO looks like Functional Programming

This is a little exaggerated, but not by much. Chaining messages, when done properly, can feel like composing functions.

You may have been told rules like "No more than 2 dots on a line".
I feel this rule stupid. The functional developper inside of my stomach shifts uneasily when hearing such sayings.
The heart is at the right place, I understand what the people mean, but I am not sure it means the same thing for them as it does for me.

When the returned object of each message is different, we should not go above 2. It would mean that we send messages to objects we should not be aware of in the first place.

But what about something like:

str = "a STRING is like a spring!"
str.downcase
   .gsub(/(s.ring)/, 'beautiful \1')
   .capitalize

# => A beautiful string is like a beautiful spring!

Each method is called on the same object; it does not count as "three dots"!

I want all my classes to behave like String and allow me to chain calls as I see fit.

To that avail, a simple rule: "A public method which does not return a meaningful result should return self"

So you will see some self coming in the mix soon enough 😊

But let us go back to our main subject. What does GildedRose? It responds to 1 message, and that is it.

def update_quality
  @items.each do |item|
    case item.name
    when "Aged Brie"
      AgedBrie.new(item).update
    when "Backstage passes to a TAFKAL80ETC concert"
      Backstage.new(item).update
    when "Sulfuras, Hand of Ragnaros"
      Sulfuras.new(item).update
    else
      CommonItem.new(item).update
    end
  end

  self
end

Let us see it from another angle: GildedRose creates some classes and propagates a message to those classes.

Oh. God. I fear GildedRose is in reality... a kind of Factory.

No, not the gross factories from the Java world: The pure, aesthetic factories promoted by Object Oriented Programming.

Now that we considered GildedRose that way, impossible to go back: we need to refine it and shape it like the factory it is.

From a standard class to a factory

@items is an Array of Item instances. I would prefer it to be an Array of CommonItem. My problem is: which child of CommonItem?
Well, it depends on the item name.

Let just code some helper for that!
(In reality, the code is already there, can you see it?)

private

def class_from(name:)
  case name
  when "Aged Brie"
    AgedBrie
  when "Backstage passes to a TAFKAL80ETC concert"
    Backstage
  when "Sulfuras, Hand of Ragnaros"
    Sulfuras
  else
    CommonItem
  end
end

Given an Item, I can now instantiate the right object with a simple class_from(name: item.name).new!

We just can now refactor our code around this idea.

class GildedRose
  def initialize(items)
    # I do not store Item instances anymore, but instances of CommonItem
    @items = items.map { |item| class_from(name: item.name).new(item) }
  end

  def update_quality
    # item is now an instance of CommonItem.
    # it can just be sent the "update" message!
    @items.each { |item| item.update }

    self
  end

private

  def class_from(name:)
    case name
    when "Aged Brie"
      AgedBrie
    when "Backstage passes to a TAFKAL80ETC concert"
      Backstage
    when "Sulfuras, Hand of Ragnaros"
      Sulfuras
    else
      CommonItem
    end
  end
end

I do not know for you, but for me, it starts to look really elegant. And simple.

But let us go a little further. The content of #class_from is a real pain. Come on, you know me by now: it is a dreaded conditional! Even worse: it's a configuration conditional 🤢

Luckily for us, we know perfectly well a data structure that can handle a simple key/value configuration: we shall use an Hash.

And here is what the (final?) code looks like:

class CommonItem
  attr_reader :item

  def initialize(item)
    @item = item
  end


  def update
    item.sell_in -= 1

    item.quality -= 1
    item.quality -= 1 if item.sell_in < 0

    limit_quality
    self
  end

  private

  def limit_quality
    return item.quality = 0 if item.quality < 0

    item.quality = 50 if item.quality > 50
  end
end

class AgedBrie < CommonItem
  def update
    item.sell_in -= 1

    item.quality +=1
    item.quality +=1 if item.sell_in < 0

    limit_quality
    self
  end
end

class Backstage < CommonItem
  def update
    item.sell_in -= 1
    item.quality = 0 and return self if item.sell_in < 0

    item.quality += 1
    item.quality += 1 if item.sell_in < 10
    item.quality += 1 if item.sell_in < 5

    limit_quality
    self
  end
end

class Sulfuras < CommonItem
  def update
    self
  end
end

class GildedRose
  ITEM_CLASSES = {
    "Aged Brie"                                 => AgedBrie,
    "Sulfuras, Hand of Ragnaros"                => Sulfuras,
    "Backstage passes to a TAFKAL80ETC concert" => Backstage
  }

  def initialize(items)
    @items = items.map { |item| class_from(name: item.name).new(item) }
  end

  def update_quality
    @items.each { |item| item.update }

    self
  end

private

  def class_from(name:)
    ITEM_CLASSES[name] || CommonItem
  end
end

class Item
  attr_accessor :name, :sell_in, :quality

  def initialize(name, sell_in, quality)
    @name = name
    @sell_in = sell_in
    @quality = quality
  end

  def to_s()
    "#{@name}, #{@sell_in}, #{@quality}"
  end
end

Technically speaking, the refactoring is now finished.

We have a very lean class
Its responsibility is well defined
We can add a functionality very easily

The last part will deal with this new functionality, and a sprinkle of refactoring: this time, we will try to accommodate my tiny brain with quality of life changes.

Bye for now :)

A Walk Through the Gilded Rose Kata — Pt 3: From Faux-O to OO

Lomig — Sun, 11 Apr 2021 23:50:20 +0000

I left you in the last post with a GildedRose class which I find — arguably — in a much healthier state than when we first met. But I still feel that something can be done.

The same way I recognized a pattern calling for case ... when ... end, there is another one that screams at us right here.

Where there is a message...

An old teacher of mine had a saying (well I imagine that any real OO expert has a saying of the sort, but let me imagine my old teacher as a wise hermit sharing his knowledge to the worthy in a cryptic way, please): "Prefix means message".
Well, I am French, so it's a little awkward as we tend not to order words as others; here in English we should say "Suffix means message".

Let's simplify our code to see the obvious:

def aged_brie_update(item)
end

def backstage_update(item)
end

def sulfuras_update(item)
end

def common_update(item)
end

_update is a message; a message asks for an object to be called upon.

...there is a class!

People tend to think about classes as those well-thought pieces of creativity which require time, crafting, and the right model.

It's true for some of them, but not all of them. We should prefer small objects exchanging messages compared to a big class that indeed mimics a Real Life Object, but does too many things and knows too many things; those small objects often just emerge from your code and your design.

#update is a message, sent to a class, I will let this class design itself.

I will go from:

def aged_brie_update(item)
  item.sell_in -= 1

  item.quality +=1
  item.quality +=1 if item.sell_in < 0
  item.quality = 50 if item.quality > 50
end

to:

class AgedBrie
  attr_reader :item

  def initialize(item)
    @item = item
  end

  def update
    item.sell_in -= 1

    item.quality +=1
    item.quality +=1 if item.sell_in < 0
    item.quality = 50 if item.quality > 50
  end
end

Nothing fancy, now that we can see it.
Obviously, I shall change its call in our #update_quality method

from: aged_brie_update(item)
to: AgedBrie.new(item).update

Applying the same recipe everywhere

This should be trivial, now.
There is a special case, though: Sulfuras and its empty method. You may have asked yourself why I kept it for so long.

I do not care if a method is empty. Empty is good. Doing nothing is good. I did not follow a typical journey as a developer; in college, my first approach to coding was through math and functional languages. There, we have things like "identity functions" that returns what is passed to them without any change. Isolated, it is profoundly useless, but thrown in other concepts, it becomes one of the most powerful concept there is.

Nothing is something. I like nothing. If I can suffer the case ... when in this code, I am sure you can bear empty methods. Especially as now it sort of pays off: I am creating classes representing types of items. As I kept the method, I kept the concept of sending a message to Sulfuras, and I can see now that it's a type of items as any of the others. Throwing the method as useless earlier would have kept this knowledge from me.

Refactoring tips

Don't be too keen on removing duplication of code, empty methods, silly things... too early. You may miss the right abstraction for your algorithm, and create unnecessary pain for your future self.

In any case, oops, I did it again: I am making my class longer and more complex that before my refactoring. As before, I will not care that much. I respect what my old professor said from his grotto.

Here is the code in its current state:

class GildedRose

  def initialize(items)
    @items = items
  end

  def update_quality
    @items.each do |item|
      case item.name
      when "Aged Brie"
        AgedBrie.new(item).update
      when "Backstage passes to a TAFKAL80ETC concert"
        Backstage.new(item).update
      when "Sulfuras, Hand of Ragnaros"
        Sulfuras.new(item).update
      else
        Common.new(item).update
      end
    end
  end

  class Common
    attr_reader :item

    def initialize(item)
      @item = item
    end

    def update
      item.sell_in -= 1

      item.quality -= 1
      item.quality -= 1 if item.sell_in < 0
      item.quality = 0 if item.quality < 0
    end
  end

  class AgedBrie
    attr_reader :item

    def initialize(item)
      @item = item
    end

    def update
      item.sell_in -= 1

      item.quality +=1
      item.quality +=1 if item.sell_in < 0
      item.quality = 50 if item.quality > 50
    end
  end

  class Backstage
    attr_reader :item

    def initialize(item)
      @item = item
    end

    def update
      item.sell_in -= 1

      item.quality += 1
      item.quality += 1 if item.sell_in < 10
      item.quality += 1 if item.sell_in < 5
      item.quality = 0 if item.sell_in < 0
      item.quality = 50 if item.quality > 50
    end
  end

  class Sulfuras
    attr_reader :item

    def initialize(item)
      @item = item
    end

    def update; end
  end
end

class Item
  attr_accessor :name, :sell_in, :quality

  def initialize(name, sell_in, quality)
    @name = name
    @sell_in = sell_in
    @quality = quality
  end

  def to_s()
    "#{@name}, #{@sell_in}, #{@quality}"
  end
end

We can see some repeating patterns though as our newly created classes cover:

the same concept (a kind of trade good)
with the same signature (accept an Item, respond to #update)
that can be substituted without causing an error

You guessed it, it is time for inheritance!

And the not so special case becomes a parent

To keep my sanity, I decided that the parent object should be my CommonItem. In reality, any of those new classes could fit. That is exactly the reason why I am not that weary to use such a dangerous (and hated, it seems) concept as inheritance — please refer to my bullet points above.

I also decided that if all those objects should be siblings, they should try and behave the same way as much as possible.

An item, it cannot have a negative quality, nor have a quality above 50. I had special cases for that when required, but never cared to streamline the process.

AgedBrie sees its quality go up, so I never cared it could not go below 0. But it's true anyway. It's true for every items.
In the same way, I did not care that a CommonItem could never have its quality above 50, but it's a limit for every items nonetheless.

I implemented a simple bound helper function on which every of those items can rely:

def limit_quality
  return item.quality = 0 if item.quality < 0

  item.quality = 50 if item.quality > 50
end

A few moments later, once everything inherits from its rightful parent, we get this magnificent result:

class GildedRose

  def initialize(items)
    @items = items
  end

  def update_quality
    @items.each do |item|
      case item.name
      when "Aged Brie"
        AgedBrie.new(item).update
      when "Backstage passes to a TAFKAL80ETC concert"
        Backstage.new(item).update
      when "Sulfuras, Hand of Ragnaros"
        Sulfuras.new(item).update
      else
        CommonItem.new(item).update
      end
    end
  end

  class CommonItem
    attr_reader :item

    def initialize(item)
      @item = item
    end


    def update
      item.sell_in -= 1

      item.quality -= 1
      item.quality -= 1 if item.sell_in < 0

      limit_quality
    end

    private

    def limit_quality
      return item.quality = 0 if item.quality < 0

      item.quality = 50 if item.quality > 50
    end
  end

  class AgedBrie < CommonItem
    def update
      item.sell_in -= 1

      item.quality +=1
      item.quality +=1 if item.sell_in < 0

      limit_quality
    end
  end

  class Backstage < CommonItem
    def update
      item.sell_in -= 1
      return item.quality = 0 if item.sell_in < 0

      item.quality += 1
      item.quality += 1 if item.sell_in < 10
      item.quality += 1 if item.sell_in < 5

      limit_quality
    end
  end

  class Sulfuras < CommonItem
    def update; end
  end
end

class Item
  attr_accessor :name, :sell_in, :quality

  def initialize(name, sell_in, quality)
    @name = name
    @sell_in = sell_in
    @quality = quality
  end

  def to_s()
    "#{@name}, #{@sell_in}, #{@quality}"
  end
end

We are nearly down the road, and tomorrow, we will see how to finally use those classes to our advantage, and justify their existence in our grand refactoring scheme.

Because, yup, we had a goal, and it is still on the radar: make this GildedRose class easier to understand and maintain, and let us add a functionality.

Have a nice day!

A Walk Through the Gilded Rose Kata — Pt 2: Duplication is your friend (at first)

Lomig — Sun, 11 Apr 2021 22:30:04 +0000

So, we left our kata at the end of the last post with some tests, but still no clue about how to handle the entanglement in the gross conditional that is at the core of the GildedRose app.

If you tried this kata yourself, or if you try to relate with some difficult pieces of code you encountered, you perhaps tried to understand a bit of what happens, and tiny fragment by tiny fragment, patiently untangle the code.

As I said, I will not; I cannot. It is a conditional! Yuck!
What I understand and like, though, are guard clauses.
Guard clauses are simple, they are nice, and most importantly to me, they are flat.

A guard clause?

For people unfamiliar with the concept, a guard clause is a pattern that would require to leave a method very early and return easy results, or special cases results, for the method to focus on its main algorithm.

Everything is better and clearer with an example! Imagine a method that would divide an integer by another one.

def divide(dividend:, divisor:)
  dividend.to_f / divisor
end

That is splendid, but if divisor is 0, there will be an issue. We want to return the string "error" when a user tries such a calculus.

# Conditional
def divide(dividend:, divisor:)
  if !divisor.zero?
    dividend.to_f / divisor
  else
    "error"
  end
end

# Guard clause
def divide(dividend:, divisor:)
  return "error" if divisor.zero?

  dividend.to_f / divisor
end

It works because return stops the execution of the method, making any else useless.

But how can we apply this concept to my messy method at hand?

Excluding a first special case from the execution

Instead of trying to untangle what I have, I will exclude something. Anything. Let us take a look at the code:

def update_quality()
    @items.each do |item|
      if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
        # <Moar code here!>
      end
    end
  end

There seem to be a case where item.name equals Aged Brie; I decide (at random, any other would work, it was just the first to appear here) it will be my special case.

I just want to return something in that case. What do I want to return? I don't know yet, but is it a problem? Unit Tests have my back in any case!

⚠️ In the Guard Clause example above, I used return to stop the execution of the method. Here, I will want to stop the execution of a block. Unlike some other languages, Ruby is nice enough to provide a substitute for return in blocks: next.

def aged_brie_update(item)
  # Here will be what we want to do with our Aged Brie!
end

def update_quality()
    @items.each do |item|
      next aged_brie_update(item) if item.name == "Aged Brie"

      if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
        # <Moar code here!>
      end
    end
  end

Again, you can see I do not try to untangle the conditional. If the item is the Aged Brie, I will be able to deal with it outside of the conditional. If it is not, the conditional will take over. That way, the only tests that should fail are the one related to the Aged Brie: obviously, we do not do anything with it 😊

So, test by test, I work towards green. I do not really care about special refactoring, even though we can argue I have my coding style. It seems simple enough, far away from the problems of our #update_quality method.

What do we want?

Each time, it ages;
Each time, it gains 1 quality;
If item.sell_in is overdue, each time it gains an extra quality;
It cannot go above 50 quality.

def aged_brie_update(item)
  item.sell_in -= 1

  item.quality +=1
  item.quality +=1 if item.sell_in < 0
  item.quality = 50 if item.quality > 50
end

My tests being green again, I can take for granted that I did not break anything.

You may think that I made the execution path even more complicated, and the GildedRose class even longer, but bear with me: do not forget I am a stupid man, and I would do anything to punch an else in the guts.

Repeat...

I take my code:

def aged_brie_update(item)
  item.sell_in -= 1

  item.quality +=1
  item.quality +=1 if item.sell_in < 0
  item.quality = 50 if item.quality > 50
end

def update_quality()
  @items.each do |item|
    next aged_brie_update(item) if item.name == "Aged Brie"

    if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
      # <Moar code here!>
    end
  end
end

I extract a special case:

def aged_brie_update(item)
  item.sell_in -= 1

  item.quality +=1
  item.quality +=1 if item.sell_in < 0
  item.quality = 50 if item.quality > 50
end

def backstage_update(item)
  #What should we do with the backstage pass?
end

def update_quality()
  @items.each do |item|
    next aged_brie_update(item) if item.name == "Aged Brie"
    next backstage_update(item) if item.name == "Backstage passes to a TAFKAL80ETC concert"

    if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
      # <Moar code here!>
    end
  end
end

My tests are red for the Backstage passes, and I make them green:

def aged_brie_update(item)
  item.sell_in -= 1

  item.quality +=1
  item.quality +=1 if item.sell_in < 0
  item.quality = 50 if item.quality > 50
end

def backstage_update(item)
  item.sell_in -= 1
  return item.quality = 0 if item.sell_in < 0

  item.quality += 1
  item.quality += 1 if item.sell_in < 10
  item.quality += 1 if item.sell_in < 5
  item.quality = 50 if item.quality > 50
end

def update_quality()
  @items.each do |item|
    next aged_brie_update(item) if item.name == "Aged Brie"
    next backstage_update(item) if item.name == "Backstage passes to a TAFKAL80ETC concert"

    if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
      # <Moar code here!>
    end
  end
end

And rinse!

Extraction by extraction, guard clause by guard clause, I work toward a state where I cannot find any special case anymore.

At this stage, my code looks like this (notice the Sulfuras method that is empty 😀 — as soon as I extracted this special case, the tests were already green!):

def aged_brie_update(item)
  item.sell_in -= 1

  item.quality +=1
  item.quality +=1 if item.sell_in < 0
  item.quality = 50 if item.quality > 50
end

def backstage_update(item)
  item.sell_in -= 1
  return item.quality = 0 if item.sell_in < 0

  item.quality += 1
  item.quality += 1 if item.sell_in < 10
  item.quality += 1 if item.sell_in < 5
  item.quality = 50 if item.quality > 50
end

def sulfuras_update(item)
end

def update_quality()
  @items.each do |item|
    next aged_brie_update(item) if item.name == "Aged Brie"
    next backstage_update(item) if item.name == "Backstage passes to a TAFKAL80ETC concert"
    next sulfuras_update(item)  if item.name == "Sulfuras, Hand of Ragnaros"

    if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
      # <Moar code here!>
    end
  end
end

As I do not have any special case anymore, what does the conditional do?
Well, in fact we did not deal with all the special cases: We also need to deal with the "not special case", when my product is neither cheese, concert ticket, nor Sulfuras.

I think this is something humans tend to forget: whenever we talk about X special cases, in reality we speak about X + 1 special cases, counting "not special".

Final extraction

We remove the now useless conditional at last, then make the tests for any "Normal item" green, and this is the result — the complete code, this time:

class GildedRose

  def initialize(items)
    @items = items
  end

  def aged_brie_update(item)
    item.sell_in -= 1

    item.quality +=1
    item.quality +=1 if item.sell_in < 0
    item.quality = 50 if item.quality > 50
  end

  def backstage_update(item)
    item.sell_in -= 1
    return item.quality = 0 if item.sell_in < 0

    item.quality += 1
    item.quality += 1 if item.sell_in < 10
    item.quality += 1 if item.sell_in < 5
    item.quality = 50 if item.quality > 50
  end

  def sulfuras_update(item)
  end

  def common_update(item)
    item.sell_in -= 1

    item.quality -= 1
    item.quality -= 1 if item.sell_in < 0
    item.quality = 0 if item.quality < 0
  end

  def update_quality()
    @items.each do |item|
      next aged_brie_update(item) if item.name == "Aged Brie"
      next backstage_update(item) if item.name == "Backstage passes to a TAFKAL80ETC concert"
      next sulfuras_update(item)  if item.name == "Sulfuras, Hand of Ragnaros"

      common_update(item)
    end
  end
end

class Item
  attr_accessor :name, :sell_in, :quality

  def initialize(name, sell_in, quality)
    @name = name
    @sell_in = sell_in
    @quality = quality
  end

  def to_s()
    "#{@name}, #{@sell_in}, #{@quality}"
  end
end

Do I see the light?

Well, do not worry, I have more tricks in my bag. This being said, we could argue that already it looks better, and it would be easier to add our "Conjured items" new product.

Before ending this second part (there will be more), we can at least remove our guard clauses here. The signal is this pattern:

def update_quality()
  @items.each do |item|
    case item.name
    when "Aged Brie"
      aged_brie_update(item)
    when "Backstage passes to a TAFKAL80ETC concert"
      backstage_update(item)
    when "Sulfuras, Hand of Ragnaros"
      sulfuras_update(item)
    else
      common_update(item)
    end
  end
end

And I will let you ponder this change (I said I hated conditionals, right?) until part 3!

Thanks for reading 😊

A Walk Through the Gilded Rose Kata — Pt 1: Do not break anything

Lomig — Sun, 11 Apr 2021 19:22:23 +0000

A few days ago, I have been made aware of the Gilded Rose Kata, with quite a promising introduction — well, promising to me: a few years back it aroused Sandi Metz' interest.

I love Sandi Metz. I just love her. She is one of the smartest people around when it comes to coding, especially when dealing with what OO should be like; her books and talks are always an absolute blast, and I can only hope that one day I will be able to see programming as she does.

That could only mean that it was an interesting problem, and I wondered if I would be able to tackle it in an elegant way... or perhaps better, in a way Sandi would endorse. (Spoiler: I have been told our solutions and even our thought processes were quite similar, which is a great honor. This being said, I read her books often enough not to have any merits: monkey sees, monkey does.)

Aside from being a full-grownup developer, I teach to baby ones at Le Wagon, a high-quality product-oriented ruby-on-rails-based bootcamp, and I have learned a few things doing so: to understand a concept, result is quite meaningless, it is the thought process which has value. I can teach how to test a codebase, I can show good tests which will be understood by students, if they don't understand why we test and how we choose which test to write and when, not a lot is gained: people will know how to theoretically create a testing suite, but will not be able to do so in real life.

This got me to this idea: what about explaining how I solved this kata, step by step? I am no wise man and I am sure there are a lot of people with a better solution, or a simpler, or with different ways of seing the matter at hand, but I think that there may be things to get and to be inspired by when looking into someone else's mind. And maybe other people than my students may find interest in what I did.

The Kata

If you want to try it for yourself, you may find it here.

Allison, proud owner of the "Gilded Rose Inn" in Stormwind, meets lots of wannabe adventurers with whom she trades.
There are a lot of products to inventory, and so she has used for the past few months a software to keep track of her goods, with great success.

Every item ages 1 day each day
An item loses 1 quality each day (but cannot be below 0)
Every item has a use-by-date and may spoil faster after it

Of course, this is a very basic set of rules, and there are exceptions. You can read the full criteria list, but it implies products like cheese which obviously gains quality each passing day, or concert tickets whose demand would go higher and higher each day up until the concert is over, and then their quality would be non existent.

The objective is to add a new kind of product: Conjured items, with their new special set of rules. They are magical, you see, created by spell from thin air, and they spoil way faster.

The Code

The code is a frightening 40-something long conditional, here below:

class GildedRose

  def initialize(items)
    @items = items
  end

  def update_quality()
    @items.each do |item|
      if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
        if item.quality > 0
          if item.name != "Sulfuras, Hand of Ragnaros"
            item.quality = item.quality - 1
          end
        end
      else
        if item.quality < 50
          item.quality = item.quality + 1
          if item.name == "Backstage passes to a TAFKAL80ETC concert"
            if item.sell_in < 11
              if item.quality < 50
                item.quality = item.quality + 1
              end
            end
            if item.sell_in < 6
              if item.quality < 50
                item.quality = item.quality + 1
              end
            end
          end
        end
      end
      if item.name != "Sulfuras, Hand of Ragnaros"
        item.sell_in = item.sell_in - 1
      end
      if item.sell_in < 0
        if item.name != "Aged Brie"
          if item.name != "Backstage passes to a TAFKAL80ETC concert"
            if item.quality > 0
              if item.name != "Sulfuras, Hand of Ragnaros"
                item.quality = item.quality - 1
              end
            end
          else
            item.quality = item.quality - item.quality
          end
        else
          if item.quality < 50
            item.quality = item.quality + 1
          end
        end
      end
    end
  end
end

class Item
  attr_accessor :name, :sell_in, :quality

  def initialize(name, sell_in, quality)
    @name = name
    @sell_in = sell_in
    @quality = quality
  end

  def to_s()
    "#{@name}, #{@sell_in}, #{@quality}"
  end
end

I have a confession to make: I hate conditionals. I use them in guard clauses fine enough, I use an if if I cannot do otherwise, but each time I see an else, I want to punch it in the face. I will do whatever in my power to get rid of it. I hate them. They look stupid.
...and so you can imagine what I felt in front of this piece of code! It was like opening the door of the restroom and meeting face to face a sick-to-his-stomach Beelzebub doing his business.

But... it works. It just does what it is supposed to. I do not need to change it, not even to look at it, I could just add an encapsulating if checking for my sweet conjured items, else the abomination above, and it would work. That would defeat the point, though. I feel I am urged to do more, and to be honest... I want to do more. I want to punch those conditionals in the face.

I'll have to refactor this method. It does make sense in a business point of view: we cannot keep accumulating conditionals on conditionals if we are asked to add more new items. I checked swiftly if I could integrate my conjured items "inside" the mess, but I could not grasp the extend of it.

And so I bailed out. Maybe it was the way to go though — maybe there was a pattern to be seen — but with my tiny mind, I was not able to grasp it. Don't hesitate to poke me if there was a way, if you feel my approach is flawed.

It does not mean I was defeated by the kata though! Oh, no. If I cannot understand the pattern, I shall change it for a pattern I can understand. But first, I need to be sure I will not break anything.

Do not break anything

People tend to mean "it should still return the same result" by that. Of course it plays a huge part of "not breaking anything", but in reality, the rule is a little broader.

I do not know what is interconnected with the piece of code I am working on and so I do not feel free to change everything as I see fit. I have to keep the interface as it is whether I find it relevant or not. Later would be the time to propose some change if needed, but now, I have to be sure I do not break anything, inside, but also outside of my code.

First design decision: the scope

I will not change the Item class;
The GildedRose class has to keep accepting an array of those Item objects, and respond to the #update_quality message.

Everything else, I feel at liberty to change. The problem is that liberty is not what stops us to do drastic changes; fear is. Fear that we tampered with the expected results once our refactoring took place.

Here come the tests

Beginners often ask why TDD is used, or even, is effective. One of the answers is: "because it allows for refactoring without any fear of messing up". Well, that is, if you did not screw your tests.

When you refactor existing code, it is even more vital if you feel you need to extensively change the codebase. I will not, I shall not change a single line before being sure I covered every use case with tests. I fear regressions more than initial bugs.

Fortunately, this kata is provided with a simple script which displays the evolution of some items over the course of days.

I just have to run this script before any code modification on a sufficient amount of days, save the result, and then compare it to any run once I changed my code!

I have what I need: a source of truth.

describe GildedRose do
  before(:all) { `ruby spec/texttest_fixture.rb 100 > test.txt` }
  after(:all)  { `rm test.txt` }

  describe "#update_quality" do
    it "has no regression" do
      expected = "spec/100_updates_expected_results.txt"
      actual = "test.txt"

      expect(IO.read(actual)).to eq IO.read(expected)
    end
  end
end

This being said, it is not as handy as nice unit tests I can solve one by one with readable error message, so I will need to create tests anyway — This source of truth (I arbitrarily chose 100 days, because why not?) will only be here to confirm other tests.

I ended with a very long test file, with lots of cases:

Some inferred from the written rules provided by Allison
Some provided by different attempts with the source of truth

They are not pretty tests, in a sense that there sure are duplicates and useless ones; I would take a more thoughtful approach to testing if it was TDD with my own code, but as I handle legacy entangled code, I prefer to be safe than sorry.

For the sake of those articles, the only thing to remember is: if ever I break something, a test will catch it.

And now, we can try and find where to start to untangle this mess... In a second article, in order to be kind on your eyes and your attention.

See you soon :)

DEV Community: Lomig

Monads explained to my team — Part 4: The Maybe Monad

Make it readable!

Make it dry-like

As a Rubyist, why do I care?

Going further

Dry-Monads

Other Noteworthy Monads

Monads explained to my team — Part 3: Creating a monad

Once upon a time, there were boxes

This box does not belong to Schrödinger

Making the box content operation-agnostic

Nested boxes are the worst…

Useless bit of information

So what's next?

Monads explained to my team — Part 2: Endofunctors

Fancy words for simple concepts

#map

The rules of #map

So, what about Functors?

And Endofunctors, then?

As a Rubyist, why do I care?

Ok, but for God's sake, what's the relevance with Monads?

Monads explained to my team — Part 1: Monoids

Fancy words for simple concepts

A little bit of Math

Composition

Useless bit of information

Association

Useless bit of information

Special elements

Useless bit of information

So, what about Monoids?

As a Rubyist, why do I care?

But then, Monads?

A Walk Through the Gilded Rose Kata — Pt 5: Open to extension, closed to modification

Adding Conjured Items

Quality of life: How I like to see Ruby code

Final Code

A Walk Through the Gilded Rose Kata — Pt 4: Discovering what GildedRose really is

Good OO looks like Functional Programming

From a standard class to a factory

A Walk Through the Gilded Rose Kata — Pt 3: From Faux-O to OO

Where there is a message...

...there is a class!

Applying the same recipe everywhere

Refactoring tips

And the not so special case becomes a parent

A Walk Through the Gilded Rose Kata — Pt 2: Duplication is your friend (at first)

A guard clause?

Excluding a first special case from the execution

Repeat...

And rinse!

Final extraction

Do I see the light?

A Walk Through the Gilded Rose Kata — Pt 1: Do not break anything

The Kata

The Code

Do not break anything

First design decision: the scope

Here come the tests

`#map`

The rules of `#map`