Abstraction is a concept that I have been thinking quite a lot about lately. It is a concept that has largely been foreign to me, and it is slowly dawning on me that abstraction lies all around us.
The Webster Dictionary defines abstraction as a “general idea or quality rather than an actual person, object, or event.” If we took the literal translation of the root abstractus (past participle of abstrahere), we would get “to draw away; to detach or divert.” This term was first used by Oswald Herzog to describe the artistic attitudes and implementations of the Dadaists (in 1519, ‘Der Abstrakte Expressionismus’). He wrote, “it is pure creation. It does not borrow objects from the real world; it creates its own objects … the abstract reveals the will of the artist; it becomes expression.” Abstraction, in the general sense of the word, is the process by which we generate semantic meaning with a concept.
In Ruby, abstraction is key to making your code achieve two things: more readable and reusable. At this point, we’ve learned to make our code more abstract via many concepts, such as MVC, ReST (Representational State Transfer), migrations, database abstraction via ActiveRecord, and routing.
A major component of Ruby on Rails has really nailed down the abstract aspect of coding for me: ActiveRecord and its corresponding ActionPacks. ActiveRecord serves as the “Model” component relational database for Rails. It comes with a set of query methods used for creating, retrieving, updating, or destroying data in the database. The model also is used for establishing association between classes. For example, a king could have a “has_many” relationship with his subjects, while a subject has a “belongs_to” relationship with his king.
1 2 3 4 5 6 7 8 9 10
ActionController serves as the “Controller” engine of Rails. By definition, a controller acts as the intermediary between the views and the models, and shuttles along HTTP responses, view renders, and redirects between the two. The controller logic is encapsulated into each individual method, and each method should really have only one action in order to simplify the logic behind the controller. The controller is designed to encapsulate the logic behind the app into specific CRUD methods, as shown below.
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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
ActionDispatch serves as a routing engine. It is responsible for recognizing a path as specified in the model logic and dispatching it according to that route’s specific action. A route action should do only one thing, while keeping in convention via the “fat model, skinny controller” paradigm. ActionDispatch takes care of the majority of your routes through resource routing. With Rails, we can declare our
index, show, new, edit, create, update, and destroy routes with one single line of code. For example, if we wanted to have a resource for our king, subject, and lord classes, you’d simply do the following:
1 2 3 4 5 6 7
ActionView is the Rails engine responsible for maintaining the HTML views that are rendered to the browser. For each controller that’s present in the app, there is a corresponding
app/views directory that stores ERB templates used for HTML browser rendering.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Being able to effectively encapsulate your logic into separate logic categories is such a necessary skill-set to understand in order to become a proficient Ruby on Rails developer. I’m still in the process of learning how to whittle down my logic into singular methods and actions. Ruby is a language that was built for abstraction. It is meant to simplify logic in your code, and as Matz said once, “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy.”