DEV Community: Manu

Single responsibility methods in javascript

Manu — Wed, 21 Oct 2020 11:26:20 +0000

When working with a single file module which exports many methods, it becomes a pretty complex issue to maintain it in the long run as well as add tests. You can never know how the file is gonna grow, how many methods are going to get added eventually and how are we going to add tests for each of this with it's own stubs and mocks.

Example for the type of situation I am talking about

// app/services/order-service.js

const orderService = {};

orderService.serviceMethodA = () => {};
orderService.serviceMethodB = () => {};
orderService.serviceMethodC = () => {};
orderService.serviceMethodD = () => {};
...
...

module.exports = orderService;

I have actually stumbled upon such handles critical code and grew up to thousands of number of lines.

Now, even for a method of ten lines, you may end up writing three test cases considering the edge cases involved. Now, imagine a file with tens of such methods. It can also happen that they may come with their own dependencies and external calls. So even if we want to write a test for serviceMethodC, we will have to end up making sure the stubs and mocks are all in place for every other one so that the whole test doesn't fail.

To counter this, a pattern that I recently started following was something of a sort of "Single Responsibilty Methods". Like the name suggests I started breaking down this file into multiple files, one for each method. All of them then imported into a single entry point file.

Folder structure before change

app
└── services
   └── order-service.js

Now, after splitting up the methods into seperate files and adding an entry point file, the structure would look like below

app
└── services
   └── order-service
      ├── index.js
      ├── service-method-a.js
      ├── service-method-b.js
      ├── service-method-c.js
      └── service-method-d.js

The index.js file looks like below

const orderService = {};

orderService.serviceMethodA = require('./service-method-a.js');
orderService.serviceMethodB = require('./service-method-b.js');
orderService.serviceMethodC = require('./service-method-c.js');
orderService.serviceMethodD = require('./service-method-d.js');

module.exports = orderService;

Now, to add tests, we can go ahead and add tests individually for each method, abstracted for it's own and not worried about the dependencies of other methods

tests
└── services
   └── order-service
      ├── index.js
      ├── service-method-a-test.js
      ├── service-method-b-test.js
      ├── service-method-c-test.js
      └── service-method-d-test.js

Whole thing is much more clean, no more single large files and all mixed up dependencies etc. Also, collaboration is easier as if tasks are split each concerned person can work on their tests individually, no more merge conflicts!

NOTE:
One thing that I have personally noticed was that, when we write any service object, a repository object or a controller object, we append the object type to the end of the file name.
Eg: order-service, order-repository, orders-controller
Advantage being it clearly denotes what the file is and also aids in fuzzy searching it.
With the current approach, we are breaking down such a file. It reduces the search-ability and it also could happen that there can be two similarly named methods under different contexts. Such breaking down also could prevent editors to navigate via "intellisense" to the method definition.
Although, these are not big issues and can also be solved if we just be extra careful and look at the file path. In my case I could trade if for the advantages that I received.

Dynamic parameters in Go

Manu — Sun, 23 Feb 2020 05:45:24 +0000

Coming from a dynamic programming background it was a bit of getting used to, to the typed ecosystem of go especially with function signatures.

One of the things that was boggling me was how to pass dynamic parameters to a function.
In ruby we could

def someFunc(arg1, *moreArgs)
  puts moreArgs
end

Now we could call somefunc("hello", "george", "joseph")

It was all simple there, but coming to go, it wasn't that straightforward, although go provides a way to do this. Look at the below snippet

func someFunc(arg1 string, a ...string) {
    fmt.Println(arg1)
    fmt.Println(arg1, a)
    fmt.Println()
}

Observing the snippet line by line, notice the last parameter of someFunc, it is called variadic parameter. From the go docs

 If f is variadic with a final parameter p of type ...T, then within f the type of p is equivalent to type []T. If f is invoked with no actual arguments for p, the value passed to p is nil. Otherwise, the value passed is a new slice of type []T with a new underlying array whose successive elements are the actual arguments, which all must be assignable to T. The length and capacity of the slice is therefore the number of arguments bound to p and may differ for each call site.

Okay, what it means is that if the final parameter of a method is of type ...T, then it is considered as type []T inside that method. What this means is that it works similar to *moreArgs in ruby. If we need to pass multiple arguments of type T, we can and they all will be available in the slice []T.

We could call the function as below:

    someFunc("hello")
    someFunc("hello", "apple")
    someFunc("hello", "apple", "orange")

Functional ruby

Manu — Thu, 20 Feb 2020 10:32:36 +0000

Having written elixir for a while I got curious to see what all can be done in
ruby, in a functinoal way mostly in comparison to Elixir. Below are some of the
ruby methodologies that I found. I am skipping lambdas and procs for now since
they are widely discussed at many places. The snippets are self explanatory.

Splat `*` and destructuring a list

Never knew I could deconstruct an array like this.

  first, *rest = [1,2,3]
  # => first == 1
  # => rest == [2,3]

The above led me to reimagine #map in a functional way.

arr = [1,2,3]
fn = ->(x) { |x| x*2 }

def remap(arr, fn)
  return if arr == []

  first, *rest = [1,2,3]

  first, *rest = arr
  [].push(fn.(first)).push(remap(rest, fn))
end

Shorthand proc invocation

Ruby has procs and lambdas, for this post we are not digging on those two topics
much.

Creating a proc

double = Proc.new { |x| x*2 }

Creating a lambda

double = ->(x) { x*2 }
lambda = lambda { "Lambda" }

Back to the current section, you would know this:

def main
  [1,2,3].map(&:+)
end

The above snippet retruns the sum of the elements.

Let's decrypt (&:+)

& is shorthand for to_proc

def to_proc
  proc { |obj, *args| obj.send(self, *args) }
end

: is just a symbol notation (Read on ruby symbols)
+ the operator

Now essnetially, you could look at it as & :+, so a symbol :+ is passed.
Now, as per the definition of to_proc the symbol is called upon the object
itself.

So if you pass a symbol, it is turned into a proc.

Symbol#to_proc was added to address this common pattern

arr.map do { |x| x.upcase }

This then becomes:

arr.map(&:upcase)

Now in order to create a custom functions that we can pass to map we should use
a lambda. Lambdas are essentially anonymous functions.

If you are familiar with javascript, you would have used lot of anonymous
functions for defining callbacks. On a similar anology we can proceed with a
squaring function.

irb(main):004:0> [1,2,3].map(&(->(x) { x*x}))
=> [1, 4, 9]

Looks cryptic but you can see that we created an anonymous function and passed
it in with &.

We could take it out and define the function somewhere else giving

irb(main):005:0> fn = ->(x) { x*x }
=> #<Proc:0x00007f89f19b3cf0@(irb):5 (lambda)>
irb(main):006:0> [1,2,3].map(&fn)
=> [1, 4, 9]

Let's take a step back now, we just discussed & essentially calls #to_proc
on it.

Another important thing to remember, if we use a symbol the corresponding method
is called on the object itself i.e

irb(main):009:0> [1,2,3].map(&:fn)
Traceback (most recent call last):
        5: from /Users/manu/.rbenv/versions/2.6.3/bin/irb:23:in `<main>'
        4: from /Users/manu/.rbenv/versions/2.6.3/bin/irb:23:in `load'
        3: from /Users/manu/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
        2: from (irb):9
        1: from (irb):9:in `map'
NoMethodError (undefined method `fn' for 1:Integer)

Since Integer doesn't have a method fn, it failed.

Hence,

irb(main):011:0> [1,2,3].map(&:odd?)
=> [true, false, true]
irb(main):012:0>

That's it!

Formatting error messages in Go

Manu — Wed, 18 Sep 2019 05:14:46 +0000

In go errors are values, and hence error management is an explicit process. There is no exception handling or bubbling them up, you get an error and you decide what do with it often leading to verbose scenarios as below

value, err := someFunc()
if err != nil {
  log.Fatal(err)
}

While writing a tool recently, one of my use cases had a method invoking some system functions. This led me to a scenario to return back formatted error messages, and to do that I ended up with fmt.Errorf()[1]

It allows us to return formatted errors like below

result, err := externalFunc()
if err != nil {
  return fmt.Errorf("Calling external function failed: %s", err)
}

errors.New() doesn't allow us to format text, but only pass a string. Otherwise we would have to use Sprintf or equivalent to create a formatted string and then pass to errors.New(). Although, guess what, that's what the method internally does.

References:
[1] https://godoc.org/fmt#Errorf