Étant donné que vous n'êtes pas un programmeur professionnel, je vous recommande de vous en tenir à la simplicité. Il sera BEAUCOUP plus facile pour le programmeur de prendre votre code procédural modulaire et de le rendre OO plus tard, qu'il ne le sera pour eux de réparer un programme OO mal écrit. Si vous n'êtes pas expérimenté, il est possible de créer des programmes OO qui peuvent se transformer en un gâchis impie qui ne vous aidera ni celui qui viendra après vous.
Je pense que votre premier instinct, le code "this thing-that thing" dans le premier exemple est la bonne piste. Il est clair et évident ce que vous voulez faire. Ne vous inquiétez pas trop de l'efficacité du code, la clarté est beaucoup plus importante.
Si un segment de code est trop long, divisez-le en morceaux de la taille d'une bouchée, chacun ayant sa propre fonction. S'il est trop court, envisagez d'utiliser moins de modules et d'en mettre plus en ligne.
---- Post-scriptum: OO Design Traps
Travailler avec succès avec la programmation OO peut être délicat. Il y a même des gens qui considèrent que tout le modèle est défectueux. Il y a un très bon livre que j'ai utilisé lors de mon premier apprentissage de la programmation OO appelé Thinking in Java (maintenant dans sa 4e édition). Le même auteur a un livre correspondant pour C ++. Il y a en fait une autre question sur les programmeurs traitant des pièges courants dans la programmation orientée objet .
Certains pièges sont sophistiqués, mais il existe de nombreuses façons de créer des problèmes de manière très basique. Par exemple, il y a quelques années, un stagiaire de mon entreprise a écrit la première version d'un logiciel dont j'ai hérité et il a créé des interfaces pour tout ce qui pourraitun jour, avoir plusieurs implémentations. Bien sûr, dans 98% des cas, il n'y avait qu'une seule implémentation, le code a donc été chargé avec des interfaces inutilisées, ce qui a rendu le débogage très ennuyeux car vous ne pouvez pas revenir en arrière lors d'un appel d'interface, vous devez donc faire un recherche de texte pour l'implémentation (bien que maintenant j'utilise IntelliJ, il y a une fonctionnalité "Afficher toutes les implémentations", mais à l'époque je ne l'avais pas). La règle ici est la même que pour la programmation procédurale: toujours coder en dur une chose. Seulement lorsque vous avez deux choses ou plus, créez une abstraction.
Un type similaire d'erreur de conception peut être trouvé dans l'API Java Swing. Ils utilisent un modèle de publication-abonnement pour le système de menu Swing. Cela fait de la création et du débogage des menus dans Swing un cauchemar complet. L'ironie est qu'elle est complètement inutile. Il n'y a pratiquement jamais de situation dans laquelle plusieurs fonctions devraient "s'abonner" à un clic de menu. De plus, la publication-abonnement a été un raté complet car un système de menus est normalement toujours utilisé. Ce n'est pas comme si les fonctions s'abonnaient puis se désabonnaient au hasard. Le fait que les développeurs "professionnels" de Sun aient fait une telle erreur montre à quel point il est facile, même pour les pros, de faire des erreurs monumentales dans la conception OO.
Je suis un développeur très expert avec des décennies d'expérience en programmation OO, mais même je serais le premier à admettre qu'il y en a des tonnes que je ne connais pas et même maintenant, je suis très prudent en utilisant beaucoup d'OO. J'avais l'habitude d'écouter de longues conférences d'un collègue qui était un fanatique OO sur la façon de faire des dessins particuliers. Il savait vraiment ce qu'il faisait, mais en toute honnêteté, j'ai eu du mal à comprendre ses programmes parce qu'ils avaient des modèles de conception si sophistiqués.