Pourquoi la méthode finalize() en java.lang.Objet “protégés”?

• "Se cacher" autant d'informations que possible est l'essence même de l'abstraction.
• Pourquoi pas? Je peux appeler méthode finalize() d'une instance à partir d'une autre instance de droit? Soit le cas, mon intention est la même. Alors, pourquoi ne peux-je faire?
• c'est l'un de ces cas où la plate-forme peut protéger le programmeur de lui-même 😉
• Lorsque vous déclarez un champ, vous rendre privé? Pourquoi? Si vous avez accédé à une autre classe, l'intention serait également identiques.
• Oh, c'est bizarre. Personnellement je trouve un point faible de java que des méthodes abstraites ne peuvent apparemment être privé. Quelqu'un connaît la raison? A-t-elle quelque chose à voir avec le caractère fragile de la classe de base problème?
• Parce qu'une méthode abstraite doit être remplacée par une sous-classe, et vous ne pouvez pas remplacer les méthodes privées. Par conséquent, private abstract serait une contradiction dans les termes.
• Je ne vois pas pourquoi vous le souhaitez. La classe de déclarer la méthode privée est la seule classe qui peut l'utiliser. Quel serait le but d'utilisation privée méthode abstraite? Voulez-vous votre sous-classes pour mettre en œuvre une méthode uniquement votre super-classe peut invoquer? Ne vous voulez vous assurer que votre sous-classes sont de déclarer certaines méthode privée? Les deux n'ont pas de sens pour moi.
• qui pousse juste le problème d'une étape vers le haut. Pourquoi ne peut-on pas remplacer (ou à mettre en œuvre) les méthodes privées? Ressemble à un valide en cas d'utilisation pour le modèle de la méthode de motif.
• De quoi parles-tu? C'est exactement ce que les méthodes protected sont pour. Privée, c'est pour des choses qui ne devraient pas être remplacées.
• J'ai été dans l'impression que les méthodes protected sont pour les cas où les sous-classes doivent être en mesure d'appeler la méthode protégée, mais pas d'autres. Mais si nous voulons seulement mettre en œuvre, mais pas d'appeler un baseclass méthode, pourquoi ne devrions-nous pas être autorisés à restreindre l'accès à des privés? Au moins en C++, de prise de fonctions virtuelles privé est un bon style, selon certaines personnes connues. Je me demande quelle est la raison de la diversité des opinions de ces deux camps.
• Je pense que ce que vous décrivez est essentiellement la façon dont C# traite avec des membres protégés. Vous pouvez accéder à un membre protégé dans une classe seulement par des variables qui sont statiquement typés pour quelque chose qui n'est pas plus élevé dans la hiérarchie d'héritage. new BaseType().ProtectedMethod() ne fonctionne pas dans DerivedClass en C#. Cela rend protected membres sont bien private à d'autres "branches" de l'arbre d'héritage.
• Hmm... je suppose que j'ai pu voir quelque chose comme étant utile, mais elle est également utile pour les sous-classes pour ne pas connaître ou être en mesure de remplacer les méthodes privées des classes parentes. En général, je ne pense pas que cela pose un problème majeur que les sous-classes peuvent appeler protégé méthodes de parents eux-mêmes.
• - Lorsque votre préoccupation est ["pour garder les choses aussi bien privé que possible"] alors pourquoi beaucoup de méthode equals(),toString(),wait(),notify() sont là le public.ils peuvent être protégés, et qu'ils conservent encore leur comportement existant.lorsque la protection de la provoquer des problèmes?
• syntex protected void finalize() throws Throwable { }

Tous les commentaires

• Je soupçonne que les concepteurs de Java ont été largement plus optimistes quant à l'utilité de Finalize; n'avaient-ils pas été, quelque chose ressemblant à AutoCloseable aurait été une partie de Java 1.0. Si la langue est un moyen de distinguer entre les références qui encapsulent la propriété des ressources et ceux qui ne sont qu'à identifier les ressources détenues par quelqu'un d'autre, je ferais l'hypothèse que 99% des ressources de nettoyage pourraient être automatisées de manière déterministe, parce que 99% des entités nécessitant nettoyage, à tous les moments de leur vie, ont exactement la même propriétaire. Pas toujours le même propriétaire, mais jamais de zéro et de ne jamais les deux.
• Bien qu'il existe quelques cas où il fait sens pour les entités d'exiger un nettoyage mais pas propriétaire, la plupart des objets qui encapsulent mutable état doit définir clairement la propriété (si oui ou non ils exigent de nettoyage) et la plupart des objets qui nécessite de nettoyage encapsuler mutable état. Sachant que lorsque la dernière référence à un objet est mis hors de portée est dur, de savoir quand le seul et unique propriétaire d'un objet se fait avec c'est facile. Le dernier point, c'est quand l'objet doit être nettoyé, peu importe ce que les autres références peuvent exister.

• Cela dit, quelle serait la réponse à ma deuxième question. Si je l'appelle finalize() deux fois, ce qui va arriver?
• Si la méthode finalize est mise en œuvre correctement, il ne cause aucun préjudice à l'appeler deux fois. Objet.finaliser ne fait rien,nada,zip par défaut, sauf si vous avez remplacé ou dérivent d'une classe qui ne le remplacer. Si vous faites appel à finaliser sur quelque chose qui ne le remplacer, vous pourriez libérer ses ressources avant de vous doit, et les opérations ultérieures de cet objet peut échouer dans diverses manières.
• "Si j'appelle finalize() deux fois, ce qui va arriver?" Pourquoi voudriez-vous faire cela? Vous n'êtes pas censé l'appeler encore une fois. La question ne se pose pas.