J'examine l'application C # Console C # de Co-travailleur, et je vois cet extrait:
class Program
{
static void Main(string[] args)
{
Program p = new Program();
p.RealMain();
}
... non-static RealMain function
}
8 Réponses :
jamais vu auparavant. Si vous souhaitez aller avec ce modèle, créez un programme Pourquoi avez-vous besoin de champs de niveau d'instance? Les champs statiques ne suffisent pas?
Il pourrait y avoir un avantage si vous souhaitez instancier de nombreux Je ne vois rien de particulièrement mal avec cette approche, je ne l'ai tout simplement pas vu auparavant. distinct2 -Class avec REALMAIN et instaniez cela à la place.
Programme CLASSES.
"Pourquoi avez-vous besoin de champs de niveau d'instance? Les champs statiques ne suffisent-ils pas?" -- Bonne question. Je suppose que je devrai demander au développeur, mais il est difficile pour moi d'imaginer une situation qui mériterait de multiples instances de programme avec leurs propres champs non statiques. C'est juste une application de console.
Le point d'entrée d'application est toujours défini comme vide statique principal (...) .
Vous pouvez décider d'écrire votre code dans Main () ou d'utiliser cette méthode pour exécuter quelque chose d'autre situé ailleurs ... c'est à vous de décider ...
Si vous voulez obtenir des fonctions non statiques , vous devez faire comme ça.
Il y a une école de pensée qui dit que la fonction principale () du code orienté objet devrait faire le moins possible. Principal () est un retour "laid" à la conception de code procédurale, où des programmes ont été écrits dans une seule fonction, appelant les sous-routines uniquement si nécessaire. Dans OOP, tout le code doit être encapsulé dans des objets qui font leurs emplois lorsqu'ils sont racontés.
Donc, en faisant cela, vous réduisez le LOC dans le point d'entrée principal () à deux lignes et la logique réelle du programme est structurée et exécutée à une mode plus O-O.
Alors, lorsque vous écrivez vous-même des applications de console, est-ce ce que vous faites?
Non, je n'ai pas dit que je a souscrit à cette école de pensée :)
Si c'était une autre classe mais "Programme", la question n'aurait pas été montée. Cette conception vous donne la possibilité d'instancier plusieurs instances de "programme", peut-être enfiler à l'avenir, alors pourquoi pas. Je suis avec Keiths ici: aussi peu que possible dans le vide statique principal.
La pratique acceptée consiste à créer une instance d'une classe distincte qui peut contenir tout ce dont vous avez besoin. L'extrait ci-dessus a l'air étrange au moins :).
Accepté par qui, exactement? Des références?
@Jon Skeet par "Accepté" Je voulais dire que cette pratique est utilisée presque partout, la méthode principale sert généralement de point d'entrée à une application elle-même, par exemple dans les applications Windows où un formulaire est instancié d'abord, puis un "vrai" point d'entrée Méthode - Montrer - est appelé.
@Centro: Cela dépend vraiment de ce que vous faites. Pour les petits outils, je n'aurai généralement qu'un seul cours - que ce soit instancié ou non. Je ne pense pas qu'il y ait bénéficié d'avoir deux classes plutôt que d'une, juste pour éviter d'avoir principal dans la même classe.
@Jon Skeet pour petites applications peut-être que cela a du sens, mais pour les applications du monde réel, la méthode principale doit être aussi claire que possible.
@Centro: Qu'est-ce qui vous fait penser que les applications du monde réel ne peuvent pas être petites? J'ai écrit des charges de petits outils qui sont très utilisées dans le monde réel. Bien entendu, une proportion importante d'applications n'a pas de méthode , ce sont des applications Web ou des services Web ou autre.
@Jon Skeet lors d'une demande réelle, il doit avoir des cours avec leurs responsabilités pour faire ce travail. La responsabilité de la classe de programme est juste d'initier d'autres responsabilités. Bien sûr, pour des applications simples, cela n'a pas d'importance et que vous pouvez avoir toute la logique dans la méthode principale uniquement.
@Centro: Cela ne fait pas grand chose pour la qualification, n'est-ce pas? La portée des outils qui ne couvrent que quelques classes, mais où vous voulez pouvoir les tester (et que vous voulez donc des exemples plutôt que des méthodes statiques, de garder l'état distinct entre les tests) est assez large OMI.
@Jon Skeet sûrement, il vaut mieux utiliser des instances pour tester plutôt que des méthodes statiques si c'est ce que vous vouliez dire.
@Centro: Oui. Plutôt que d'utiliser un tas de méthodes statiques dans une seule classe, utilisez un tas de méthodes instance dans une seule classe et faites principale simplement créer une instance de cette classe (passant dans toute configuration appropriée, etc.). Maintenant, cette classe pourrait être une distincte, mais je ne vois pas beaucoup d'avantages de la mise en place de principale dans une classe seul si le seul but est de s'instalier un autre et dire "aller".
Cela a du sens pour moi.
En particulier, vous voudrez peut-être ajouter juste suffisamment de logique dans albin a demandé pourquoi cela serait nécessaire. En un mot: Testabilité. Dans certains cas, il est entièrement possible de au moins tester certains aspects d'un programme de niveau supérieur avec des tests d'unités ou éventuellement des tests d'intégration. Utiliser des champs d'instance au lieu de champs statiques (etc.) améliore la testabilité ici, car vous n'avez pas à vous soucier de vous inquiéter des tests précédents qui gâchent l'état. Main pour analyser les arguments de la ligne de commande - éventuellement à l'aide d'un analyseur d'argument généralisé - puis passez ces options dans le constructeur de manière fortement typée appropriée pour le programme en question.
Alors, lorsque vous écrivez vous-même des applications de console, est-ce ce que vous faites?
@Anonymous: Parfois, oui. Tout dépend de la situation, mais je pense certainement que cela a du sens, en particulier s'il continue à tester le nettoyant. Plus le projet est petit, plus il est logique, si votre projet ne contient que quelques classes, en avoir un extra pour principal est un encombrement inutile imo.
Je vois beaucoup cela, en particulier pour les programmes de console rapides assommés pour essayer quelque chose ou tester quelque chose.
Visual Studio l'encourage pratiquement - si vous demandez un nouveau programme de console, il génère un fichier unique, avec une classe contenant uniquement une méthode principale.
sauf si vous faites quelque chose de compliqué, qui nécessite plus d'une classe, ou quelque chose de très simple, ce qui ne nécessite pas de classe du tout (c'est-à-dire toutes les méthodes et variables statiques) Pourquoi ne feriez-vous pas cela de cette façon?
Quel est le problème avec ça? Qu'est-ce que vous avez contre des variables d'instance? Ne les utilisez-vous jamais?
Cela me semble bizarre, mais je ne peux pas vous dire avec autorité si c'est commun ou bon.
@David Heffernan - Je n'ai aucun argument solide pour ou contre cela (tout comme @Thatmatthew). C'est juste que les champs statiques sont tout aussi faciles à utiliser et vous n'auriez pas besoin d'instancier la classe extérieure.
@David Heffernan, il n'a pas de problème avec des variables d'instance en général. Il a un problème d'instanciation d'une classe qui est normalement utilisée pour appeler une méthode statique.