Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Je rebondis de manière semi-digressive sur le sujet de la POO pour dire en complément que la tendance à complexifier inutilement le code tend à être inévitable avec elle, même quand on est rigoureux. Je renvoie les curieux aux vidéos (en anglais… à sous-titrer ?) de Brian Will sur la programmation orientée objet, qu’il dénonce tout en défendant la programmation orientée données (séparation des données et des fonctions). Je pense qu’il a raison sur le fait que cette dernière est bien plus naturelle et claire (cerise sur le gâteau, elle est aussi plus performante !! Cf. le système entité-composant (ECS), notamment proposé par des moteurs de jeux). La conférence de Stoyan Nikolov à CppCon 2018 (en anglais aussi…) illustre cela avec un gros cas pratique (au passage, lui trouve que la POO peut quand même servir dans des cas limités, ce qui se discute). Je laisse chacun se faire son avis !

Pour un petit projet, ça se voit peut-être moins, mais rien qu’avec un simple essai un peu plus gros mais pas tant, j’avais déjà senti que le syndrome « usine à gaz même en concevant de manière logique » commençait à me tomber dessus… La séparation des fonctionnalités en bouts situés à divers emplacements résulte ironiquement en du code spaghetti, ce qui est pile un phénomène que l’on cherche à éviter.

Pour revenir au cas présent : la tendance à créer des « gestionnaires » (managers) abstraits illustre pile le coup de tenter de regrouper des choses dans des abstractions n’ayant pas de sens en elles-mêmes, pour tenter de coller à un schéma d’organisation du code. En vrai, il n’y a rien de mal à programmer en impératif (ou fonctionnel ou autre), il faut se décomplexer. ;) On peut être à la fois simple et générique, alors autant ne pas se gêner !