Ja, in der Tat ein interessanter und sehr empfehlenswerter Artikel. Der Inhalt ist mir persönlich allerdings nicht neu, sondern Teil meiner alltäglichen Praxis
Warum Getter und Setter keine so tolle Idee sind, wird ja in dem Artikel auch schon angerissen. Und genau da seh ich eben ein großes Problem mit der draw Funktion. Damit die freie Funktion dein Paddle zeichnen kann, benötigt sie den getImage() Getter. Damit wird nicht nur die Tatsache, dass das Paddle intern ein einzelnes ALLEGRO_BITMAP hält nach außen propagiert, obwohl es eigentlich ein Implementierungsdetail ist, sondern auch sämtlicher Zeichencode von dieser Tatsache abhängig (und wer weiß was noch alles, immerhin gibt es ja diesen bequemen Getter und ich will ja doch nur schnell mal ...). Wenn du nun plötzlich gerne zwei ALLEGRO_BITMAPs hättest, z.B. weil der Paddle eine magnetische Aura bekommen soll, wirds haarig. Mit den anderen Gettern, die die Position liefern, verhält sich das nicht anders. Getter und Setter sollte man imo so gut es geht vermeiden. Methoden sollten dazu dienen, mit den Daten der Klasse zu arbeiten und nicht dazu, die Daten an dritte weiterzureichen. Ich seh jedenfalls nicht, wo genau die Vorteile der freien draw Funktion liegen. Im Gegenteil, anstatt die Kapselung zu erhöhen, musstest du, um draw() als freie Funktion implementieren zu können, das Interface der Klasse um Getter erweitern, durch die nun jedermann Zugriff auf Teile des internen State des Objektes hat. Wenn du dir das Beispiel mit dem Wombat im von dir verlinkten Artikel genau anschaust, wird dir auffallen, dass dort keine Getter zum Einsatz kommen. Das ist kein Zufall