Il semble qu'il y ait beaucoup de gens qui disent que Java est vieux et pas cool du point de vue du langage "Imadoki". D'un autre côté, mon affirmation [^ 1] de Heisei selon laquelle "Non, Java vise un excellent média en premier lieu, donc c'est bien" est "la conception C ++. Et l'évolution »est la base de la poésie libre.
[^ 1]: Je pense juste que oui
Il va sans dire que Java est influencé par C ++. Et, bien sûr, Java a quelques choix à partir de C ++ et d'autres non. En lisant "Design and Evolution of C ++", qui raconte dans ses propres mots comment Strausstrap a fait du C ++, je pense qu'il sera également possible de voir comment Java a choisi le chemin actuel. pense. En dehors de cela, "Design and Evolution of C ++" devrait être lu par tout programmeur qui aime les langages de programmation après avoir surmonté la barrière de la conscience que "n'importe quel langage peut bouger" indépendamment du fait que C ++ puisse être fait. Je pense que c'est un bon livre.
Le problème est que les nouveaux produits ne sont plus disponibles. En écrivant cet article, je l'ai emprunté à la bibliothèque pour la première fois depuis longtemps et je l'ai lu ...
Ainsi, sauf indication contraire, les citations suivantes sont tirées de "C ++ Design and Evolution".
Comme vous le savez tous, Java a des classes, des classes abstraites et des interfaces, mais je suis sûr que certains d'entre vous peuvent s'inquiéter de la façon d'utiliser chacune, en particulier la classe abstraite et l'interface.
Les définitions de fonction sont généralement spécifiées "en dehors" (en dehors de la déclaration de classe). C'est faire la déclaration de classe (...) purement comme une spécification d'interface.
En Java, c'est la classe et l'interface, n'est-ce pas? On peut dire que l'interface a été préparée juste "pour qu'elle ressemble aux spécifications de l'interface".
N'a pas expliqué correctement aux utilisateurs C ++ que les classes dérivées sont utilisées pour séparer l'interface de l'implémentation. J'ai essayé de l'expliquer, mais cela ne semblait pas indiquer le but. Peut-être que la raison principale de cet échec est que de nombreux (la plupart?) Programmeurs C ++ et autres programmeurs intéressés par C ++ s'expriment dans des déclarations de classe qui spécifient des interfaces, l'une des implémentations d'objets. Je n'ai jamais rêvé que je pourrais écrire un club, ce qui est à la hauteur de ce que j'avais à faire. Si can est mal compris et que l'expression «toujours» (implémentation) est écrite dans la déclaration de classe, les avantages de la classe dérivée que j'ai essayé d'expliquer disparaissent. Naturellement.
Oui, vous pouvez également écrire l'implémentation dans l'interface, c'est une classe abstraite.
Je ne sais pas si le système de classes Java a été réellement conçu conformément à l'idée de Strawstrap, mais si tel est le cas, il serait préférable de concevoir avec une interface et de l'implémenter avec une classe, une classe abstraite. Je pense qu'il est possible de penser qu'il n'y avait pas de besoin particulier. Cependant, Java semble avoir choisi d'avoir comme classe abstraite la partie que C ++ avait comme résultat, "l'expression - une partie de l'implémentation de l'objet - peut être écrite dans la déclaration de classe qui spécifie l'interface". Semble être. Je pense qu'il y avait une option pour ne pas avoir de classe abstraite, mais Java a osé le faire.
Il y a plusieurs raisons pour lesquelles nous n'avons pas fait une grande différence avec C. L'intégration de l'aptitude de C pour la programmation de systèmes à la capacité de Simula à organiser des programmes était un défi majeur. L'ajout de fonctionnalités importantes d'autres langues l'une après l'autre se serait transformé en une langue de «liste de courses», créant une langue non ciblée.
C avec Classes et C ++ auraient mis plus de temps à mûrir s'ils avaient ignoré les technologies implémentées par C et Simula depuis le début.
Je pense que ce sont probablement des histoires d'implémentation de langage, mais même en termes de spécifications de langage, il aurait été d'une grande importance pour la diffusion de ne pas changer ce qui existe déjà.
La syntaxe C que je déteste le plus est la syntaxe de déclaration. Beaucoup de gens sont confus car il existe à la fois des opérateurs de préfixe et de suffixe pour la déclaration.
La réaction négative des utilisateurs à cette partie du changement a été très forte.
Même en Java, par exemple, la déclaration d'un tableau
String[] values = null;
Bien que cette notation soit recommandée
String values[] = null;
Vous pouvez ajouter «[]» à la variable Et qu'est-ce qui se passerait si
//Même sans blancs
String[]values = null;
//Même s'il reste au début de la variable
String []values = null;
//Même si c'est effrayant
String [] values = null;
//Même si tu casse une ligne
String values
[] = null;
Tous ces éléments sont également acceptés. Encore une fois, je suis sûr qu'il y avait un choix pour n'autoriser que la première notation, mais Java ne l'a pas fait. Java a également choisi de ne pas apporter de modifications de syntaxe que Straustrap ne pouvait pas faire en C ++.
D'ailleurs, pourquoi y a-t-il un type primitif et il n'est pas pur comme OOPL? Je suis sûr qu'il y a de nombreuses parties qui me donnent envie de dire, mais je suis sûr que Java sait tout et le choisit. Pour rester franc et modéré pour toujours et à jamais.
J'adore Java comme ça.
Recommended Posts