Dependency Injection
Less abstract! Expressing Ruby OOP in pictures

Summarized using AI

Less abstract! Expressing Ruby OOP in pictures

Ivan Nemytchenko • September 16, 2020 • online

This talk, delivered by Ivan Nemytchenko at Ruby Day 2020, addresses the challenges of understanding and communicating abstract concepts in programming, particularly in Ruby Object-Oriented Programming (OOP).

Main Topic

The central theme is about reducing abstraction in programming through visual representation, which can aid in teaching, explaining complex concepts, refactoring code, and tracking changes in a codebase.

Key Points discussed throughout the video:

  • Abstraction in Programming: Abstraction is essential in software development but can hinder understanding when layers of abstraction accumulate. Understanding and simplifying these layers allows for clearer communication among developers.
  • Visual Language for OOP: Ivan proposes a visual language to illustrate OOP concepts like dependency injection and polymorphism, making them more accessible to learners.
  • Art Soldiers Method: This method uses an analogy of soldiers and their roles to explain OOP concepts, helping students visualize classes and methods. For instance, each soldier represents a class with assigned roles comparable to methods they can execute.
  • Illustrative Techniques: Ivan discusses using drawings to convey relationships between classes, methods, and objects, showing how arguments flow between them, and illustrating private methods and exception handling visually.
  • Handling Complexity: The visual language can demonstrate how code complexity evolves over time and help identify anti-patterns. For example, having the same argument across multiple methods signals a pattern needing review.
  • Refactoring Visualization: Illustrations show how code transitions from complex to simpler forms, reinforcing principles of good design practices and clearer understanding of changes over iterations.
  • Real-World Application: Ivan discusses applying these techniques to real-world scenarios, like tracking codebase changes and enhancing team communication.
  • Automating Visual Tools: He introduces a library that can help generate these visual illustrations, promoting the interaction and usability of complex programming concepts in the community.

Conclusions and Takeaways

  • Visual representations can bridge gaps in understanding, especially for junior developers transitioning to OOP.
  • These tools facilitate knowledge sharing within teams and provide a new dimension for explaining complex code.
  • The audience is encouraged to experiment with visual techniques and consider their implications for improving software development practices.

Less abstract! Expressing Ruby OOP in pictures
Ivan Nemytchenko • September 16, 2020 • online

Abstractions are both our blessing and our curse. Because of them, we're so powerful. But also we so often fall into the trap of miscommunication :( Abstract rules, operating with abstract terms, built on top of other abstract ideas. Ugh... In this talk, we're going to build a visual language to make things LESS ABSTRACT.
I'll show you how it helps in:
1. teaching others
2. explaining non-obvious concepts
3. refactoring messy code 4. tracking codebase changes

rubyday 2020 - Virtual edition, September 16th 2020. https://2020.rubyday.it/

Next edition: https://2021.rubyday.it/

rubyday 2020

00:00:48.000 The first talk we will listen to is about abstractions. Ruby, like many other languages, abstracts a lot.
00:00:55.120 Abstraction is the bread and butter of software development, but sometimes you need to peel off those layers to better understand and explain to others what is really happening.
00:01:10.159 This understanding can help you refactor and get a clearer view of the code you are writing or working with.
00:01:24.560 Therefore, I'm going to leave the stage to Ivan, whose talks have always been amazing. I'm definitely looking forward to this one. Welcome, Ivan! It's super nice to see you again.
00:01:37.040 Good morning, everyone! I actually thought you were hosting every Ruby Day event because at all the ones I attended, you were hosting.
00:01:44.159 Well, as I said, it’s my way to give back to the Ruby community. As I'm not a particularly focused person, I often find myself getting distracted. So, being here with deadlines and meeting awesome people helps me to stay consistent in my deliveries. Thank you so much for being here.
00:02:26.160 Oh yeah, thank you! My talk is actually pre-recorded, so I'll be answering questions in the chat.
00:02:42.000 For those in the chat, please write your questions there, and I'll ask them after the talk.
00:03:07.360 Good morning, Ruby Day! I'm Ivan Nemytchenko, and this morning we're going to make things a little bit less abstract by expressing Ruby OOP through pictures.
00:03:21.360 So, let's start. I've been doing Ruby since 2006, mostly freelancing and consulting these days. I used to call myself a complexity fighter but now prefer the term complexity organizer.
00:03:37.120 I'm also a GitLab fan, having worked for GitLab, and I'm the person behind two websites, railshurts.com and painlessrails.com. I hail from Omsk, which is in Siberia.
00:03:56.400 To clarify, Omsk may sound strange for many, but imagine being on a long flight and seeing Omsk as the only dot on your flight monitor — that’s where I'm from.
00:04:14.799 These days, I live in Serbia, and it’s important to clarify that Serbia is not Siberia. Before moving, I didn't really understand the difference between these two places, but I do now.
00:04:32.000 Today, we are going to talk about a different problem: although we might be talking about the same concepts, our understanding can differ significantly.
00:04:54.560 We are discussing abstractions in programming; almost everything we work with is an abstraction built on top of other abstractions. This complexity can sometimes make it hard for us to understand each other.
00:05:06.400 Another issue is seeing the big picture of our code, especially when projects are huge. When all we have is the code, it can be hard to discern the underlying ideas without deep diving into it.
00:05:16.639 There have been a few attempts to address this issue, like CRC cards, which have been suggested to help, but they're not widely adopted or known.
00:05:39.360 Then there’s UML, which can be useful but often causes eyes to glaze over. While it can help in theory, it's not liked by many.
00:05:58.800 This was the problem statement, and now let's talk about what you can expect from this talk.
00:06:09.480 First of all, I promise it will be fun! You will hopefully become better at learning, teaching, and explaining complicated concepts. The techniques you learn today might help you visualize the big picture in your projects.
00:06:29.120 My talk has three parts: first, we will build a foundation; second, we will use this foundation to explain some advanced programming concepts; and finally, we will experiment with these techniques to see how they can be useful.
00:06:54.640 This whole idea originated from a conversation at a conference in Russia where several educators were discussing how to teach junior developers.
00:07:15.200 I presented a rhetorical question: Wouldn't it be great if we could illustrate concepts like dependency injection in a single picture that everyone could understand in the same way?
00:07:32.480 Months later, while working with students on their OOP assignment to develop a smart kettle that boils water correctly and safely, I found that many students struggled to think in object-oriented terms.
00:07:54.720 For students with procedural programming backgrounds, shifting to OOP can be challenging. To help these students, I used a method called the Art Soldiers method.
00:08:10.959 Imagine you are a captain and you have a dozen soldiers at your command, each assigned a role. These soldiers are highly skilled, no matter what role you give them.
00:08:27.520 An important constraint in this analogy is that the only way to interact with the soldier is to ask him to do something relevant to his role.
00:08:39.360 Using this analogy, students gradually begin to understand the principles of OOP. They realize that the roles represent classes, and the requests made to the soldiers are methods.
00:08:53.680 I often illustrate concepts with drawings, and when explaining, I create pictures representing the roles and methods to convey these ideas.
00:09:08.720 For example, one of the classes could represent a heater while another might represent a temperature sensor.
00:09:18.560 I thought about further enhancing these drawings by illustrating methods and arguments through arms and fingers. The fingers could represent arguments that the methods accept.
00:09:36.800 I further refined this idea, visualizing how the arms could store arguments in the 'brain' as instance variables, which can later be reused in other methods.
00:09:57.760 The results could also be visualized, where arguments enter fingers, processes happen inside, and results emerge.
00:10:14.480 Private methods became an illustration of arms that couldn’t be shaken from the outside, highlighting that they can only be accessed internally.
00:10:29.280 We can also illustrate exception handling processes, resulting in a comprehensive visual language that allows us to express basic anti-patterns.
00:10:43.760 For example, too many arguments or methods can be represented through swollen arms, which can clearly highlight complex situations in our code.
00:10:58.560 Through this method, we can effectively explain polymorphism; specifically, parametric polymorphism using our visual language.
00:11:13.440 With the drawing, we can determine if objects exhibit polymorphism by checking if they have the same number of limbs and fingers, thus ensuring a consistent interface.
00:11:27.360 Classes can be visualized as spawning platforms; when a lever is pulled, an object is instantiated.
00:11:46.320 This analogy reveals that classes and objects have the same topology and structures represent how objects are instantiated.
00:12:03.920 In addition, we can visually express execution flow, indicating that the sections of an arm or the steps in the arm icon represent methods being executed.
00:12:22.400 The execution flow might resemble a Rube Goldberg machine where the alignment of all components depends on the argument interactions.
00:12:45.040 Another concept we can discuss is dependencies; these are typically globally available classes reused in various places.
00:13:01.440 These dependencies can be illustrated in the flow, and if they have side effects, it becomes important to visualize how those side effects interact.
00:13:20.000 Dependency Injection can also be represented visually, emphasizing that dependencies should be passed as arguments instead of being hard-coded.
00:13:42.320 In summary, this illustrated language helps to convey the ideas of dependency injection more effectively.
00:14:00.080 Thanks to this visual approach, it becomes clearer how side effects can be isolated.
00:14:19.640 We'll now look at how this visual language can be practically applied to a talk from Sandy Mats in 2018.
00:14:37.120 While the exact nature of her talk isn't important, the main point is how the code evolves in complexity with new iterations.
00:15:00.320 We illustrate the original version of the code and then highlight how new requirements continue to grow the complexity.
00:15:14.480 As changes are made, we can depict how the complexity builds up visually so that you can see which iterations introduce excessive complexity.
00:15:30.560 After the illustrations, we can show how Sandy refactors the code, allowing us to visualize the transition from complex to simpler constructs.
00:15:42.560 This visual approach reveals the evolving state of the code and significantly aids in recognizing how complexity can build up through iterations.
00:15:56.880 As a result, one can see the improvements that occur as the code is refactored, solidifying the understanding of underlying design principles.
00:16:09.440 Now let’s discuss dynamic anti-patterns and how the visual approach helps identify these patterns as they emerge in your coding practices.
00:16:19.680 For example, when you find yourself adding the same argument to multiple methods across various classes, that’s a sign of a pattern that needs addressing.
00:16:37.680 Similarly, adding the same condition to different methods could signify a deeper problem, and this visual language points that out quickly.
00:16:53.760 The resulting code post-refactoring showcases how those original complexities were transformed into simpler and more manageable constructs.
00:17:06.160 What I find particularly interesting is that this should highlight essential complexities within your domain; it's about organizing rather than eliminating complexity.
00:17:20.720 Thus, as we work through these models, we build annotations to represent code complexity, making it easier for documentation and communication.
00:17:31.760 However, it's essential to remember that while models can be useful, they are simplifications and shouldn't be taken too literally.
00:17:48.760 These visual tools help to share knowledge across teams and articulate complex concepts with clarity.
00:18:03.440 So, if you have any questions, I’d be happy to jump in and answer them. You can also learn more about my work on my website, inm.a.t.
00:18:16.560 You can find additional resources on how I approach coding with Ruby and making it simpler at painlessrail.com.
00:18:33.760 Thank you, and I hope you have a good day at the conference.
00:18:50.560 Bye, welcome back everyone! Ivan, this was amazing.
00:19:15.280 I see that everyone has the same question: is there a way to generate these illustrations automatically?
00:19:29.760 Well, let me share my screen and show you a few more slides.
00:19:41.760 I actually have the same challenge with maintaining focus. The only reason a library exists that can generate these drawings is that an intern of mine took the initiative to implement it.
00:19:58.960 There are links available where you can try playing with this code, and even though the drawings are basic, they can effectively highlight differences in code changes.
00:20:15.840 You can even deploy a Rails app that you can connect to your repository to comment on pull requests with these illustrations.
00:20:31.760 This visual representation is drawn from a method of showing multi-dimensional data through human-like mimics, which makes understanding easier.
00:20:46.720 Our brains naturally gravitate towards human-like concepts, making it simpler to grasp the ideas behind the code when they are presented visually.
00:21:02.320 Thank you so much! I believe you'll have a lot of new downloads for this tool.
00:21:16.000 There’s a question in the chat about whether you've considered using this visual paradigm as a metric for software development.
00:21:29.600 Good question! I’ve thought about various ways this idea can be applied, including mapping metrics to visualize development.
00:21:42.800 For example, we could collect metrics from various existing Ruby gems and visualize them using this approach.
00:22:05.520 The intent of this visualization is to allow comparison over time and see if your design is becoming simpler or more elegant.
00:22:19.600 This visual representation can highlight design flaws or potential issues in your code.
00:22:32.720 I encourage you to experiment with these illustrations and tools manually first and then explore any automated solutions later.
00:22:47.840 Thank you so much for your time! I hope you enjoy the rest of the conference.
Explore all talks recorded at rubyday 2020
+2