Créer une structure logique

a marqué ce sujet comme résolu.

Bonjour,

voila mon programme à besoin de lire un fichier de configuration (rien de compliqué la dedans) dans lequel est stocké des CVars (pour configuration variable). J'essaye d'avoir l'approche la plus logique possible et je me suis dit que la meilleurs façon était de créer une structure CVars qui contiendrait le nom, la valeur et trois méthodes (GetBool, GetInt, GetString) et un class CVar_Manager qui aurait plusieurs méthodes (Get_CVar, Set_CVar, Read et Clean) et qui stockerais des variables de type CVars dans un vecteur.

Mon approche est-elle la bonne d'un point de vu POO ?

C'est la façon la plus naturel que j'ai trouvé étant donné que CVar est un objet qui a des propriétés qui lui sont propre ce n'est pas à lui de lire le fichier ou de retourner son contenu si il lui est demander non ?

De plus je trouve plus facile au niveau de la lecture de faire:

1
2
3
CVarsManager->GetCVar("name")->GetString()
// Que 
CVar["name"]->GetString()

Vous en pensez quoi ?

J'ai tendance à considérer que les agrégations de données et assimilé n'ont pas grand chose d'OO dans le principe.

Si tu veux savoir si tu es OO, poses-toi la question: quel est le service ?

Autre question: est-il si important que ça que la philo derrière ta lib soit complètement OO ?

Parenthèse, ce n'est pas la syntaxe qui fait qu'une approche sera OO ou pas. Que tu écrive x.f(y);, f(x, y);, [x f: y];, |x f: y|, (f x y), ou autre, c'est pareil. C'est juste du sucre syntaxique. Et certains sucres empêchent le multi-dispatch.

Perso, pour les fichiers de conf (et autres paramètres), je préfère des bindings automatiques. Genre j'associe une variable (prè-existante) à une option (GetLongOpt de perl a ça, depuis, ils s'y sont un peu tous mis). Quand l'option est lue, la variable est automatiquement mise à jour.
Pour les cas plus complexes, on retourne à l'approche donnée. Ton service est en fait une base de données => tu dois pouvoir faire des requêtes pour extraire les config à partir d'un nom et pouvoir ensuite les transformer dans le bon type qui va bien.

Au sujet du bon type qui va bien, dans les langages vraiment génériques, un as<T>() qui convertit vers le type T est bien plus appréciable que 50 surcharges qui ne sont pas utilisables de façon générique à cause de l'explosion du nombre de noms.

PS: je pourrais encore discuté sur l'anti-pattern des managers, mais on s'éloigne du sujet.

Si tu veux savoir si tu es OO, poses-toi la question: quel est le service ?

J'ai toujours des problèmes de vocabulaire, je comprend pas très bien ce que représente un service. A moins que ça soit simplement "A quoi ça sert".

Autre question: est-il si important que ça que la philo derrière ta lib soit complètement OO ? Aucunement.

Parenthèse, ce n'est pas la syntaxe qui fait qu'une approche sera OO ou pas.
Je sais, je disais simplement que la première ligne est plus parlante à la lecture que la seconde

Au sujet du bon type qui va bien, dans les langages vraiment génériques, un as<T>() qui convertit vers le type T est bien plus appréciable que 50 surcharges qui ne sont pas utilisables de façon générique à cause de l'explosion du nombre de noms.

J'utilise les templates dès que possible mais ici je trouve plus clair de faire plusieurs méthodes (encore une fois pour simplifié la lecture sur cette classe en particulier)

PS: je pourrais encore discuté sur l'anti-pattern des managers, mais on s'éloigne du sujet.

Je veux bien avoir plus d'information par contre :)

Mes quelques liens en désordre (avec de la redondance), sur ma vision de l'OO.

Il me semblait avoir plus développé mon analogie du pressing, mais c'est paumé dans des liens à n'en plus finir.

J'ai une idée d'analogie pour l'encapsulation depuis. Mais je ne l'ai pas encore mise au propre.

Pour le manager j'ai vu d'autres liens plus faciles à exploiter, mais je ne les a pas gardés: http://c2.com/cgi/wiki?DontNameClassesObjectManagerHandlerOrData

PS: si tu as en C++, alors fonce pour les templates, et oubli cette surcharge à l'infini.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte