Sans vouloir être suffisant ou quoi que ce soit, il faut reconnaître l'existence de plusieurs approches. Le C en a une, le C++ une autre (même pas très éloignée).
Les protected et private, ça empêche les programmeurs qui utilisent la librairie de faire ce qu'ils veulent avec l'objet. Je suis pour la liberté de programmation, et le C++ permet de restreindre cette liberté, je trouve que c'est contraire à la philosophie du Libre.
La philosophie du libre implique ça ? Je ne le savais pas. En tout cas, poser des droits d'accès à des variables dans un code à plusieurs avantages. Si tu fais une librairie, les variables qui doivent pouvoir être manipulées par l'utilisateur seront en public, le reste en privé. Ça évitera que les utilisateurs de la lib ne touche quelque chose d'interne et de sensible sans le vouloir.
Ou alors, ces concepts de private et protected sont pour les débutants et les programmeurs qui ont du mal à gérer les objets ? Parceque lire et écrire une variable d'un objet avec des méthodes du type GetVariable() et SetVariable(), ce n'est certainement pas pour faire un programme efficace, ça fait des appels de fonction inutiles. Et c'est contraire à la philosophie du Libre qui veut que l'on fasse le programme le plus efficace possible.
Encore une fois, la philosophie du libre implique ça ?
Pour l'histoire des setter / getter, ça a l'air bête, mais ça permet par exemple de tracer plus simplement un programme, ou d'instrumentaliser le set. On peut par exemple vouloir limiter les valeur assignées dans le setter. Imaginons une variable int qui ne doivent jamais dépasser 25, je me pose dans mon setter et j'ajoute une condition.
Sans le setter je dois faire ce test à chaque assignation d’où une duplication du code.
De plus je ne pense pas me tromper en disant que le compilo optimisera les getter et setter à la compilation.
Tu semble regretter de ne pas pouvoir faire certaines chose en C++ par rapport au C, mais en vrai, si t'aime pas les setter n'en utilise pas. Met tout en public, ou ne créé même pas d'objets. En gros fait du C.
Maintenant si tu as envie d'essayer autre chose, tu verra que ça peut avoir de l’intérêt.
D'une manière générale, ce n'est pas parce qu'un langage se montre permissif qu'il sera bon, dans beaucoup de cas, se retrouver contraint permet de produire plus facilement un code avec moins de bugs ou d'erreurs. Le rust par exemple brille dans ce domaine je trouve, j'ai l'impression d'écrire du code plus idiomatique, justement parce que je suis très contraint.
Quand tu as une fonction avec une variable en const tu te limites dans ce que tu fera avec cette variable, tu aura l'assurance qu'elle n'est pas modifiée. Tu évites ainsi tout un tas d'erreurs bêtes. C'est la même idée avec public, private, protected. Pareil pour l'utilisateur de la fonction, il saura que ce qu'il envoie ne sera pas modifié, sans même à avoir à lire la fonction.
[^] # Re: Pas le même paradigme
Posté par Aldebaran (site web personnel) . En réponse au message Avantages du C++ sur le C ?. Évalué à 1.
J'ai beaucoup rit ;)
Sans vouloir être suffisant ou quoi que ce soit, il faut reconnaître l'existence de plusieurs approches. Le C en a une, le C++ une autre (même pas très éloignée).
La philosophie du libre implique ça ? Je ne le savais pas. En tout cas, poser des droits d'accès à des variables dans un code à plusieurs avantages. Si tu fais une librairie, les variables qui doivent pouvoir être manipulées par l'utilisateur seront en public, le reste en privé. Ça évitera que les utilisateurs de la lib ne touche quelque chose d'interne et de sensible sans le vouloir.
Encore une fois, la philosophie du libre implique ça ?
Pour l'histoire des setter / getter, ça a l'air bête, mais ça permet par exemple de tracer plus simplement un programme, ou d'instrumentaliser le set. On peut par exemple vouloir limiter les valeur assignées dans le setter. Imaginons une variable int qui ne doivent jamais dépasser 25, je me pose dans mon setter et j'ajoute une condition.
Sans le setter je dois faire ce test à chaque assignation d’où une duplication du code.
De plus je ne pense pas me tromper en disant que le compilo optimisera les getter et setter à la compilation.
Tu semble regretter de ne pas pouvoir faire certaines chose en C++ par rapport au C, mais en vrai, si t'aime pas les setter n'en utilise pas. Met tout en public, ou ne créé même pas d'objets. En gros fait du C.
Maintenant si tu as envie d'essayer autre chose, tu verra que ça peut avoir de l’intérêt.
D'une manière générale, ce n'est pas parce qu'un langage se montre permissif qu'il sera bon, dans beaucoup de cas, se retrouver contraint permet de produire plus facilement un code avec moins de bugs ou d'erreurs. Le rust par exemple brille dans ce domaine je trouve, j'ai l'impression d'écrire du code plus idiomatique, justement parce que je suis très contraint.
Quand tu as une fonction avec une variable en const tu te limites dans ce que tu fera avec cette variable, tu aura l'assurance qu'elle n'est pas modifiée. Tu évites ainsi tout un tas d'erreurs bêtes. C'est la même idée avec public, private, protected. Pareil pour l'utilisateur de la fonction, il saura que ce qu'il envoie ne sera pas modifié, sans même à avoir à lire la fonction.