Si vous écrivez quelque chose par vous-même, que vous soyez pratiquez, résolvez un problème personnel, ou juste pour le divertissement, c'est bien, de temps en temps, d'avoir un domaine public? Peut-être?
9 Réponses :
Je pense que c'est raisonnable si vous lançez consciemment le code après. En particulier, si vous expérimentez quelque chose de complètement différent, prendre des raccourcis a du sens. Il suffit de ne pas laisser conduire à des habitudes qui se croisent dans le code «réel».
Pourquoi tout le monde oublie-t-il le modèle DTO?
Peut-être que tout le monde ne connaît pas le schéma DTO.
violation des principes généraux est toujours "OK"! Ce n'est pas une erreur de violer un principe mais c'est un compromis. Le coût de l'écriture de code de nettoyage ne sera plus élevé que votre logiciel plus longtemps survivra. Ma prise sur ceci est: En cas de doute, faites-la propre!
Bien sûr que ça va bien. C'est votre code , vous pouvez faire ce que vous voulez avec elle. Personnellement, j'essaie de rester de bonnes pratiques également dans mon code privé, juste pour en faire une habitude naturelle, donc je n'ai pas à y penser.
La réponse courte est oui, si vous croyez que vous gagnez beaucoup en faisant des choses en public au lieu de privées avec des accesseurs, vous êtes invités à le faire. La cohérence, je pense, est la plus grande chose à garder à l'esprit. Par exemple, ne faites pas de variables répétées, et d'autres non. Faites la même chose à travers la planche si vous cassez avec les meilleures pratiques. Cela revient à un compromis. Presque personne ne suit pas de nombreuses spécifications IEEE pour la manière dont l'ingénierie logicielle doit être exécutée et documentée car les frais généraux sont beaucoup trop grands, et cela peut devenir ingérable. Il en va de même pour la programmation personnelle et légère. C'est bon de faire quelque chose de rapide et de sale, il suffit de ne pas m'y habituer.
Permettez-moi de vous donner une analogie. Je pense que cela s'applique parfaitement à cette situation.
pense, essayer et interroger meilleures pratiques dans votre aire de jeux. Vous réaliserez bientôt ce qui est le meilleur pour quoi. Pourquoi les propriétés sont nécessaires en premier lieu. Pourquoi cela devrait-il être public? Pourquoi devrais-je ne pas appeler un membre virtuel du constructeur? Permettez-moi d'essayer d'utiliser un «nouveau» modificateur pour un appel de méthode. Que se passe-t-il lorsque j'écris 10 niveaux imbriqués de si Et essayez de le lire après 10 jours . Pourquoi devrais-je utiliser un modèle d'usine pour un projet simple. Etc.
Et puis vous allez réaliser sans tirer sur votre pied , pourquoi les motifs de conception sont des modèles ...
Je viens d'une partie du monde où l'anglais n'est pas la langue principale. Mais c'est nécessaire pour toutes choses de la vie.
Pendant l'un de ces jours habituels pendant mes années de pré-adolescence, j'ai dit quelque chose de très drôle en anglais. Puis mon père a dit: " fils, pense en anglais. Ensuite, vous obtiendrez couramment "
N'oubliez pas qu'il existe des modèles de conception qui appellent des membres publics, tels que DTO.
Les membres du public sont acceptables dans le Data Transfer Objet Design Patter :
Typiquement, les membres de l'objet de transfert sont définis comme public, éliminant ainsi la nécessité d'obtenir et de définir des méthodes.
L'un des principaux avantages de OOP est pour la mise à l'échelle et la maintenabilité. En encapsulant du code, on peut cacher la mise en œuvre. Cela signifie que d'autres programmeurs n'ont pas à connaître la mise en œuvre et ne peuvent pas modifier l'état interne de votre objet. Si votre langue ne prend pas en charge les propriétés, vous vous retrouvez avec beaucoup de code qui obscurcent et gonfle votre projet. Si le code n'a pas besoin d'être travaillé par plusieurs programmeurs, vous ne produisez pas de composant réutilisable, et vous êtes le programmeur de maintenance, puis le code de la manière de vous permettre de Une femme de chambre a-t-elle besoin de faire son propre lit le matin afin de pratiquer un lit correctement?
Note latérale: Cela dépend également de la langue:
dans Scala garde les noms de champ et de méthode dans la même espace de noms. La vraie question est la suivante:
Quel service expose (ici en disposant d'un domaine public) ?.
Si le service (obtenez / définir une valeur de type donnée) a du sens pour votre API, le "raccourci" est légitime.
De nombreuses langues, telles que Java, gardent les noms de champ et de méthode dans des espaces de noms séparés.
Cependant, ces langues ne peuvent pas appuyer le principe d'accès uniforme en conséquence, à moins qu'ils ne puissent s'appuyer dans un soutien ad hoc dans leurs grammaires ou leurs compilateurs.
Tant que vous encapsulez ce champ éventuellement, est-ce correct, car vous avez fait le raccourci pour la "API" (API et exposition du service), par rapport à la "mauvaise" raison (accès rapide ad-hoc).
Un bon test d'unité (pensant que l'utilisateur de votre API) peut vous aider à vérifier si ce champ doit être consulté directement ou s'il n'est utile que pour le développement interne d'autres classes de votre programme.
D'accord. En Python, il n'y a pas d'application réelle des publics / privés, c'est plutôt une confiance que vous n'aurez pas accès __ ou _ Attributs préfixés, ou que vous savez qu'ils peuvent se casser. De même, vous pouvez remplacer un accès .Property avec une propriété réelle, plus tard, lorsque la complexité de la classe l'exige. Faites-le quand il est requis, pas auparavant.
Voici mon prise sur elle:
Je conseillerais d'éviter les champs publics. Ils ont une mauvaise habitude de vous mordre plus tard, car vous ne pouvez pas les contrôler. (Le mot que vous recherchez ici est volatilité. ) En outre, si vous décidez de modifier leur mise en œuvre interne, vous devez toucher beaucoup plus de code.
Encore une fois, c'est ce que sont les outils de refactoring. Si vous avez un outil de refactoring décent, ce n'est pas presque si difficile.
Il n'y a pas de balle d'argent. Je ne peux pas répéter ça assez. Si vous avez du travail à faire et que vous devez le faire passer rapidement, écrivez une ligne de code au lieu de huit (comme c'est le cas dans Visual Basic) est certainement plus rapide.
Les règles étaient censées être cassées. Si une règle ne s'applique pas nécessairement dans votre cas, ne l'utilisez pas. Les modèles de conception, les directives de codage, les lois et les meilleures pratiques ne doivent pas être traitées comme un droit de lecture qui vous oblige à compliquer inutilement votre code au point où il est énormément complexe et difficile à comprendre et à entretenir. Ne laissez pas quelqu'un vous forcer dans une pratique simplement parce qu'il est populaire ou «standard» quand il ne correspond pas à vos exigences.
Encore une fois, il s'agit d'une opinion subjective et votre kilométrage peut varier.