Single Level of Abstraction Principle (SLAP) in Golang - example

Hello fellows,

I have this method that:

  • opens a file F
  • reads its context
  • parses some useful numbers and words from each line L
  • creates a complex data structure S
  • adds each parsed data L into S
  • creates an instance of a database
  • writes the complex data structure into the database
  • returns the datastructure and a database connection

In my opinion, this method breaks the single responsibility principle, as it does too many things at once. It should be refactored so that this is a controller method: it personally does not know how to do any of those things, but simply calls other smaller methods doing each of them.

So I am willing to refactor it so that it only knows what other methods to call, the correct order, and does error handling.

But there is still more I do not like about this method (in its original form, not the refactored one): a method who builds a data structure should not know how each line of a file must be parsed, or how to create a given database. Parsing a line of text (string) should be done at another layer, reading and writing to a DB should be done at another layer, etc.

How can I arrange this layer structure ? Any advice on how can I structure the code (all these small methods) called by my code into layers ?

My original method, which knows how to do low level stuff as well as high level stuff, is breaking the Single Level of Abstraction Principle (SLAP). Where can I find more details (and ideally examples or exercises) about SLAP in Golang ?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.