Conception de classe OOP, Cette conception est-elle intrinsèquement «anti» OOP? Je me souviens

Question

en arrière quand MS a publié un exemple d'application de forum, la conception de l'application était comme ceci:

/Classes/User.cs /Classes/Post.cs ... /Users.cs /Posts.cs

Ainsi, le dossier classes n'avait que la classe ie les propriétés et les getters/setters. Les Users.cs, Post.cs, etc. ont les méthodes réelles qui ont accès à la couche d'accès aux données, afin Posts.cs pourrait ressembler à:

public class Posts 
{ 
    public static Post GetPostByID(int postID) 
    { 
      SqlDataProvider dp = new SqlDataProvider(); 
      return dp.GetPostByID(postID); 
    } 
} 

Une autre voie plus traditionnelle serait de mettre toutes les méthodes dans Posts.cs dans la définition de classe aussi (Post.cs). Diviser les choses en 2 fichiers le rend beaucoup plus procédural n'est-ce pas? Est-ce que ce n'est pas la casse de la POO, puisqu'elle enlève le comportement de la classe et le place dans une autre définition de classe? Etes-vous sûr que les classes ne sont pas des classes partielles?

Answer 1

Si chaque méthode est juste un appel statique directement à la source de données, la classe "Posts" est vraiment une usine. Vous pouvez certainement mettre les méthodes statiques dans "Posts" dans la classe "Post" (c'est comme ça que fonctionne CSLA), mais ce sont toujours des méthodes d'usine. Je dirais qu'un nom plus moderne et précis pour la classe "Posts" serait "PostFactory" (en supposant que tout ce qu'il a est des méthodes statiques). Je suppose que je ne dirais pas que c'est une approche "procédurale" nécessairement - c'est juste un nom trompeur, vous supposeriez dans le monde OO moderne qu'un objet "Posts" serait dynamique et fournirait des méthodes pour manipuler et gérer un ensemble d'objets "Post".

Answer 2

Dans ce cas, ils ne sont pas vraiment deux classes, juste une seule classe répartie sur plusieurs fichiers pour une meilleure lisibilité.

Answer 3

Basé sur votre extrait de code, Les postes sont principalement une classe de méthodes auxiliaires statiques. Postes n'est pas le même objet que Post. Au lieu de postes, un meilleur nom pourrait être PostManager ou PostHelper. Si vous y pensez de cette façon, cela peut vous aider à comprendre pourquoi ils l'ont fait de cette façon.

Answer 4

Ceci est également une étape importante pour un découplage (ou un couplage lâche) de vos applications.

Answer 5

Ce qui est anti-POO ou pro-POO dépend entièrement de la fonctionnalité du logiciel et de ce qui est nécessaire pour le faire fonctionner.

Answer 6

Eh bien, cela dépend où et comment vous définissez votre séparation des préoccupations. Si vous placez le code pour remplir la publication dans la classe Publier, votre couche d'entreprise est intercédée avec le code d'accès aux données et vice versa.

Pour moi, il est logique de faire la collecte de données et de remplir en dehors de l'objet de domaine réel, et laisser l'objet de domaine être responsable de l'utilisation des données.