Notes are reusable content pages that encapsulate a policy, recommendation, or tip. A Note knows what content pages it has been applied to (and vice-versa). Notes help promote the Don't Repeat Yourself (DRY Principle) principle.
Notes are especially used here to record Webel's guidelines for UML modelling of reverse-engineered PHP for Drupal and the tutorial module OOE = Object Oriented Examples = One Of Each, as applies to using PEAR PHP UML imported into MagicDraw UML via XMI2.
In order to demonstrate the Webel recipe for PHP the database interactions for the demo modules on this site are made deliberately very simple. This is in part to simplify the representation of those parts of the module involving the database interaction, but largely because I have not yet reverse engineered the Drupal7 core entity/field system of the Entity API system into the Webel UML recipe for UML.
Note however that an element that has not yet been reversed from PHP into a UML "design(ed)" model element must NOT yet be represented by a «!wrapper» @Component, because there is no "design(ed)" element to wrap.
Detailed answer: Because this is part of the migration process from a non-OO Drupal7 project to a more OO one using the Webel process. As a first step, flat functions from Drupal7-style include files are encapsulated - along with relevant data constants - into static public class methods. This is just UML-friendly enough to enable the 1st stage of reverse engineering into graphical UML with PEAR:PHP_UML !
By a get() method is not meant a property getter, it means literally 'get()' with no arguments and only 3 letters in the method name ! The get() methods are how OOE talks to Drupal core, they assemble everything to return a valid Drupal array (or string).
The only exception is the CurrentPosts example, which deliberately extends only AbstractProject and uses an explicit page callback function in the .module file to show you the "old" non-OO way of doing it.
This policy is immutable, to work with the OOE = Object Oriented Examples = One Of Each tutorial module and reap all the advantages one must use this naming convention. It is NOT a Drupal7 convention, it is a Webel OOE convention !
Please when working with OOE = Object Oriented Examples = One Of Each code like this, with explicit private Interface variables that are "lazily" (as needed) assigned implementations and configured in protected lazy creation/configuration methods. And please only then access the Interfaces via their matching lazy methods:
Case: one has a Property variable typed by an Interface in a managing Class and one wishes to indicate (when a factory is not used) which implementation Class is assigned to the variable (say on lazy instantiation).
IMPORTANT: this matter is only of concern when a managing class has knowledge of concrete implementation Classes assigned to its Interface variables (such as for a demonstration class choosing demonstration items), it does not apply when factories are used !
This is necessary because the XMI generated by PEAR PHP UML does not integrate with the MagicDraw UML code engineering sets system, one can however import the XMI (into the design packages).
It is best not to put a single element, not a diagram, no relationships, nothing, that changes the design(ed) packages ! Instead, you use analysis diagrams, under the '@' analysis package root, to pull in design elements where appropriate.
This is because in my current combination of MagicDraw UML with PEAR PHP UML the only way I have found to consistently include coding changes to the PHP classes in the MD UML model is to Import From > Another Project .. where the other project is the reverse engineered XMI2 file generated by PHP UML.
This educational site is brought to you by Webel IT Australia, experts in database-driven web technology for industry, engineering, education and science. Webel is one of Australia's most experienced Drupal CMS web site specialists.