Smalltalk Best Practice Patterns by Kent Beck. In my opinion, it's his best book. It's a great book on the nitty gritty of coding.. great for all programmers. It's easy to read even if you're not a Smalltalker; all you have to do is google for a Smalltalk cheatsheet.

I also like Working Effectively with Legacy Code. It's about the sort of code that most of us confront daily: how to deal with its problems, and get it under test so that you can refactor it or add to it without gumming it up.

I'd focus on identifying where problems are in code, more than trying to fix them. I really believe fixing them is the easy part, with learning how to fix them in really tiny, incremental steps slightly harder. Appreciating what good code looks like and why lesser code can and should be improved.

SOLID is a great set of rules to start with, if you haven't ready incorporated that into your thought process. I'd also recommend a really old book by Kent Beck as a great resource about thinking at the level of coding idioms. It's called Smalltalk Best Practice Patterns (https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X) and oops, I had no idea it was so expensive! I bought it years ago, and have read it over and over. Kent has a way of talking you through what good code should look like. It's in smalltalk, but his ideas are still great.

There are some SUPER valuable insights in the replies of this thread that took me YEARS of programming to fully understand. So you did yourself a great service asking this question here :)

 

These insights are:

by u/cmd-t
> think in OOP in terms of passing messages from object to object. Every function call is actually sending a message to an object: a request for it to do something.

by u/saturnflyer
> Don't model the real world. Create the world you need.

by u/tom_dalling
> It's a common misconception that classes model real-world things. Classes model data, or behavior, or responsibilities.

 

To answer your question, yes, OOP is hard to master. As a result, there are many books written on the subject. And for a complicated system, even senior developers will have trouble getting the design right on a first try.

 

If you feel lost, it's not because you are not good at this. It's because the subject you are learning does require lots of time and practice.

IMHO, the best way to learn this is by actually working alongside with senior engineers in a real production project. So you can see some existing designs and also bounce ideas with other engineers.

While that might not be possible at the moment, you can

• look at existing designs of open source projects
  
• read books: Practical Object-Oriented Design in Ruby by Sandi Metz, Smalltalk Best Practice Patterns by Kent Beck These two might be a bit too advanced. I couldn't think of any good OOP introductory books of the top of my head, maybe Head First Object-Oriented Analysis and Design?
  
• practice and bounce your design ideas with other engineers
  
   
  
  Happy coding and I hope to see you posting more questions here! :D
  
  

The correct placement style of curly brackets is whichever one is already in place, or whichever one you can stick to. The two main contenders are the K&R style (brackets start on the same line as as the declaration, but end on their own line), and the Allman style (brackets always start and end on their own lines).

As far as actual code structuring, I would recommend breaking your code into the smallest possible pieces as methods to enable code re-usability, portability, and general ease of understanding for anyone that has to read it. My basic rule of thumb is no more than 10 lines per method if I can avoid it, any more than that and either you haven't broken it down enough, or you can probably refactor your code to simplify it.

A book that I saw recommended and am reading through at the moment is Smalltalk Best Pattern Practices which goes over this quite thoroughly but uses only the Smalltalk language for examples, so that may or may not confuse matters.

First, a superficial note: the Ruby way is to indent 2 spaces, not 4. This is the first thing that sticks out about your code as "strange" ruby.

Second, name the method by the thing that it returns. So, instead of the procedural create_array, the method name would be thingies_array since it returns an array of "thingies". Or, better yet, the method name should just be thingies, as the plural already signals that the method returns a list. Recommended reading is Smalltalk Best Practice Patterns. But first read this to get some context of how the ideas in this book apply to Ruby.

Third, get to know the methods provided by the Enumerable module and the Array class well. You will find that idiomatic Ruby leans heavily on the Enumerable methods.

Finally, here is my take on your example in what I feel is more idiomatic Ruby (remember, in the end, this is all subjective, there is no one right way):

def thingies_from_json(json)
json['thingies'].map do |t|
thingy = Thingy.new
thingy.id = t['id']
thingy.desc = t['desc']

........ code ......

    thingy<br />
  end<br />
end<br />

• practical object oriented design in ruby
  
• smalltalk best practice patterns
  
• refactoring to patterns
  
• object oriented software construction