Pourquoi C # et Java exigent-ils que tout soit dans une classe?

Il semblait que cette question aurait dû être posée auparavant, mais la recherche n’a rien trouvé.

Je me suis toujours demandé quel était le but de nous faire mettre chaque bit de code dans une classe ou une interface. Je pense me souvenir qu’il y avait des avantages à exiger une fonction main() comme C, mais rien pour les classes. Les langages comme Python sont, d’une certaine manière, encore plus orientés object que Java car ils n’ont pas de primitives, mais vous pouvez mettre du code où vous voulez.

Est-ce une sorte de “mauvaise interprétation” de la POO? Après tout, vous pouvez écrire du code procédural comme vous le feriez dans C et le mettre dans une classe, mais il ne sera pas orienté object.

Je pense que le but de demander que tout soit inclus dans les classes est de minimiser le nombre de concepts que vous devez traiter dans la langue. En C # ou Java, il vous suffit de comprendre le modèle object (qui est cependant assez complexe). Cependant, vous n’avez que des classes avec des membres et des instances de classes (objects).

Je pense que c’est un objective très important que la plupart des langues essaient de suivre d’une manière ou d’une autre. Si C # possédait un code global (par exemple pour permettre l’évaluation interactive et la spécification du code de démarrage sans Main méthode Main ), vous auriez un concept supplémentaire à apprendre (code de niveau supérieur). Le choix fait par C # / Java n’est bien sûr qu’un moyen d’obtenir la simplicité.

Bien sûr, la question est de savoir si c’est le bon choix. Par exemple:

Dans les langages fonctionnels, les programmes sont structurés à l’aide de types (déclarations de type) et d’ expressions . Le corps du programme est simplement une expression évaluée, ce qui est beaucoup plus simple qu’une classe avec Main méthode Main et permet également un script interactif (comme en Python).
Dans Erlang (et les langages similaires), le programme est structuré de manière à exécuter simultanément des processus avec un processus principal qui lance d’autres processus. C’est une approche radicalement différente, mais cela convient à certains types d’applications.

En général, chaque langue a une certaine façon de regarder le monde et de le modéliser et utilise ce sharepoint vue pour tout regarder. Cela fonctionne bien dans certains scénarios, mais je pense qu’aucun des modèles n’est totalement universel. C’est peut-être l’une des raisons pour lesquelles les langages qui combinent plusieurs paradigmes sont très populaires aujourd’hui.

En passant, je pense que l’utilisation de Main méthode Main est un choix discutable (héritant probablement des langages C / C ++). Je suppose qu’une solution orientée object plus claire serait de démarrer le programme en créant une instance de certaines classes Main .

C # n’a pas été conçu pour “programmer en petit”. Plutôt, il a été conçu pour la programmation orientée composant . C’est-à-dire pour les scénarios de programmation où des équipes de personnes développent des composants logiciels interdépendants qui vont être publiés dans plusieurs versions au fil du temps.

L’accent mis sur la programmation dans l’ensemble et loin de la programmation dans le plus petit signifie qu’il ya parfois beaucoup de «cérémonies» autour de petits programmes. En utilisant cette classe, le principal bla bla bla, tous pour écrire «Bonjour tout le monde».

La propriété “un programme d’une ligne est une ligne de long” serait bien d’avoir en C #. Nous envisageons d’autoriser le code en dehors des classes dans les petits programmes comme une fonctionnalité possible dans une future version hypothétique de C #; Si vous avez des opinions constructives sur ou contre une telle fonctionnalité, n’hésitez pas à me les envoyer via le lien de contact sur mon blog.

Je pense qu’avec Java, l’idée était qu’une classe de niveau supérieur représenterait une seule unité de code qui serait compilée dans un fichier .class distinct. L’idée était que ces unités de code discrètes et autonomes pouvaient alors être facilement partagées et combinées dans de nombreux projets (tout comme un menuisier peut combiner des éléments de base tels que des écrous, des boulons, des morceaux de bois, etc. ). La classe était considérée comme l’unité atomique la plus petite et la plus élémentaire. Par conséquent, tout devrait faire partie d’une classe afin de faciliter l’assemblage de programmes plus volumineux à partir de ces parties.

On peut dire que la promesse de code facilement composable de la programmation orientée object n’a pas très bien fonctionné, mais à l’époque de la conception de Java, le but de la POO était de créer de petites unités pouvant être combinées pour créer des programmes uniques. .

J’imagine que C # avait les mêmes objectives en tête.