Xavier Nayrac

Rubyiste accro au TDD, serial blogger, apprenti data scientist, heureux utilisateur de Vim, accordéoniste.
Si vous vous sentez particulièrement généreux, suivez moi sur Twitter.

Ruby - Et si on écrivait un ORM ? - partie 6

| Comments

Niveau : intermédiaire

Hier je m’étais arrêté sur cette implémentation de SORM.save:

1
2
3
4
5
6
7
8
9
  def self.save(parameters)
    table = self.to_s.downcase
    columns = parameters.keys.join(',')
    values = parameters.values.map do |item|
      item.class == String ? "'#{item}'" : item
    end.join(',')
    query = "INSERT INTO #{table} (#{columns}) VALUES(#{values});"
    @@db.execute(query)
  end

Cette méthode est déja bien trop longue selon mes critères, et si on ne fait pas quelque chose tout de suite on va vite se retrouver avec un tas de méthodes de classe impossibles à remanier.

Une première partie du refactoring va consister à extraire une classe que je vais nommer Recorder:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  def self.save(parameters)
    recorder = Recorder.new(@@db, self.to_s.downcase, parameters)
    recorder.save
  end

  class Recorder
    def initialize(connection, table, parameters)
      @connection = connection
      @table = table
      @parameters = parameters
    end

    def save
      @connection.execute(query)
    end

    def query
      "INSERT INTO #@table (#{columns}) VALUES(#{values});"
    end

    def columns
      @parameters.keys.join(',')
    end

    def values
      @parameters.values.map do |item|
        item.class == String ? "'#{item}'" : item
      end.join(',')
    end
  end

Ça permet d’avoir des méthodes simples, faciles à comprendre.

Une seconde partie du refactoring consistera à namespacer correctement les différentes parties de SORM. Pour ça il faudra aussi modifier les tests.

To be continued

À demain.

Articles connexes

Commentaires