apitome ruby 3 compatibility

 https://github.com/jejacks0n/apitome/issues/121

Based on some local testing, the apitome gem works fine on ruby 3.

PR merged: https://github.com/jejacks0n/apitome/pull/122

Action Oriented vs Object Oriented

• Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.
• Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem.
• Beware of classes that have many accessor methods defined in their public interface. Having many implies that related data and behavior are not being kept in one place.
• Beware of classes that have too much noncommunicating behavior, that is, methods that operate on a proper subset of the data members of a class. God classes often exhibit a great deal of noncommunicating behavior.
• In applications that consist of an object-oriented model interacting with a user interface, the model should never be dependent on the interface. The interface should be dependent on the model.
• Model the real world whenever possible. (This heuristic is often violated for reasons of system intelligence distribution, avoidance of god classes, and the keeping of related data and behavior in one place.)
• Eliminate irrelevant classes from your design. Heuristic 3.8 Eliminate classes that are outside the system.
• Do not turn an operation into a class. Be suspicious of any class whose name is a verb or is derived from a verb, especially those that have only one piece of meaningful behavior (i.e., do not count sets, gets, and prints). Ask if that piece of meaningful behavior needs to be migrated to some existing or undiscovered class.
• Agent classes are often placed in the analysis model of an application. During design time, many agents are found to be irrelevant and should be removed.

The Building Blocks of Object Oriented Paradigm

• All data should be hidden within its class.
• Users of a class must be dependent on its public interface, but a class
• should not be dependent on its users.
• Minimize the number of messages in the protocol of a class.
• Implement a minimal public interface that all classes understand [e.g., operations such as copy (deep versus shallow), equality testing, pretty printing, parsing from an ASCII description, etc.].
• Do not put implementation details such as common-code private functions into the public interface of a class.
• Do not clutter the public interface of a class with things that users of that class are not able to use or are not interested in using.
• Classes should only exhibit nil or export coupling with other classes, that is, a class should only use operations in the public interface of another class or have nothing to do with that class.
• A class should capture one and only one key abstraction. Heuristic 2.9 Keep related data and behavior in one place.
• Spin off non-related information into another class (i.e., noncommunicating behavior).
• Be sure the abstractions that you model are classes and not simply the roles objects play.

Ruby Links for Sep 1, 2022

 1. Callback Nightmare