Discussion :

[Matthieu76]

Mon problème est simple :

J'ai 3 classes static A, B et C.

A include B qui include C et j'aimerais que dans le code de A je ne puisse pas appeler C::foo().

Comment faire ?
Est-ce que l'utilisation de namespace est une bonne solution ?

[Bousk]

- 3 classes static ?
- si A inclue B qui inclue C, A inclue C
- si A inclue C, A a accès à C
- les namespace sont là pour délimiter/ranger le code

Ton truc ressemble plus à un foutoir d'architecture.
- pourquoi A inclue B ?
- pourquoi B inclue C ?

- si A manipule un B, il n'en a rien à faire de C
- que B manipule un C en interne, n'intéresse pas A
- que fait C::foo public s'il doit pas être appelé ?
- pourquoi ne pas simplement éviter d'appeler C::foo ?

[Matthieu76]

Bah C::foo() est en public pour que B puisse y accéder.

En gros C c'est ma classe Database, A c'est ma classe Algorithm et B ma class Database_manager.

Avant ma classe Algothim utilisait directement ma Database::write() mais ce n'est pas bon et c'est pour cela que je passe par ma classe Database_manager pour évite les appels à la base de données n'importe comment.
Mais là, vu que Database_manager include Database, je peux toujours directement appeler les fonctions de Database dans la classe Algothim et je voudrais que cela ne soit pas possible.

[bacelar]

Bah C::foo() est en public pour que B puisse y accéder.

Toi, t'as pas vécu les années Dorothée et la "Force de l'amitié".

Déjà, si tout n'était pas statique, t'aurais beaucoup moins problèmes.

Si C n'est pas "statique", et bin A pourrait se brosser pour accéder au membre "C" de la classe "B".

"Database_manager", c'est un nom pourri, ça veut rien dire.
Utilisez des noms corrects, ça simplifiera grandement la maintenance.

Si vous faites une "vraie" DAL, vous faites ça dans une librairie à part, donc avec un seul .h public qui ne déclare que les choses utilisables par le code client de la librairie.

Le problème n'est pas technique, mais c'est un problème de conception/architecture.

[Matthieu76]

Si vous faites une "vraie" DAL,

Tu veux pas plutôt dire DLL ? Et puis de toute façon je vais pas créer plusieurs libraire alors qu'il s'agit du même projet avec du code non-réutilisable.

Déjà, si tout n'était pas statique, t'aurais beaucoup moins problèmes.

J'ai pas besoin de créer d'objet donc pourquoi ne pas même en static ? Je vais pas mettre des singletons partout ! Et puis un singleton ne règlerais pas le problème car je pourrais quand même faire C::instance()->foo()

"Database_manager", c'est un nom pourri, ça veut rien dire.

Il s'agit de ma classe qui s'occupe d'effectuer les requête SQL grâce à la classe Database et de retourné directement les variables ou objets au reste du code. Je savais pas comment la nommé.
Mais partout ou j'ai accès à Database_manager j'ai aussi accès à Database et c'est pas bon.

Bah, je vais créer un namespace private_database que je n'appellerais que dans database_manager et ça sera très bien comme ça

[Bousk]

https://en.wikipedia.org/wiki/Data_access_layer

J'ai pas besoin de créer d'objet donc pourquoi ne pas même en static ? Je vais pas mettre des singletons partout ! Et puis un singleton ne règlerais pas le problème car je pourrais quand même faire C::instance()->foo()


Il s'agit de ma classe qui s'occupe d'effectuer les requête SQL grâce à la classe Database et de retourné directement les variables ou objets au reste du code. Je savais pas comment la nommé.
Mais partout ou j'ai accès à Database_manager j'ai aussi accès à Database et c'est pas bon.

Bah, je vais créer un namespace private_database que je n'appellerais que dans database_manager et ça sera très bien comme ça

Et tu pourras toujours faire private_database::C::foo() donc déplacer le pb te suffit ?

Pas besoin de créer un objet database ? Quid de la connection ? T'en crées une nouvelle pour chaque requête ?

[bacelar]

Tu veux pas plutôt dire DLL ?

Pourquoi pas faire une DAL dans une DLL, cela renforcera le réutilibilité, la facilité d'évolution et de testabilité.
Vous pouvez aussi en faire une simple LIB pour la réutilibilité.

Et puis de toute façon je vais pas créer plusieurs libraire alors qu'il s'agit du même projet avec du code non-réutilisable.

Avec cette attitude, vous ne réutiliserez jamais rien.
Si vous n'êtes pas capable de le faire dans des cas simples, n'essayez même pas dans des "vrais cas".

Vous faites une usine à gaz (des static de classe dans tout les coins) pour faire "comme les vrais" mais quand on dit que c'est pas comme ça, vous dite, "je vais pas me prendre la tête, je garde mon usine à gaz", c'est débile, supprimez directement cette usine à gaz.

J'ai pas besoin de créer d'objet donc pourquoi ne pas même en static ?

Pas besoin de faire des statiques/globales déguisées, quand un simple champ dans une classe fait largement l'affaire.

Je vais pas mettre des singletons partout ! Et puis un singleton ne règlerais pas le problème car je pourrais quand même faire C::instance()->foo()

Les singletons, c'est pas pour faire des globales déguisées à la con, si pas besoin, on n'utilise pas. Et on en a rarement "juste besoin", c'est toute une architecture (IoC, mocking, etc...) qui peuvent ÉVENTUELLEMENT en avoir besoin.
C'est un argumentaire "homme de paille", faudrait pas nous prendre pour des perdreaux de l'année.

Il s'agit de ma classe qui s'occupe d'effectuer les requête SQL grâce à la classe Database et de retourné directement les variables ou objets au reste du code.

C'est pas clair, et ça n'a rien à voir avec une "gestion" de base de données.
Quand une classe n'a pas de rôle PRÉCIS, elle dégage.

Je savais pas comment la nommé.

Preuve que vous n'avez pas assez réfléchi votre conception.

Mais partout ou j'ai accès à Database_manager j'ai aussi accès à Database et c'est pas bon.

Vous avez accès à "Database" parce que "Database" est publiquement déclarer dans un .h, c'est pas arrivé par hasard, bordel.
Si vous n'en voulez pas, comment se fait-il que vous avez sciemment foutu cette classe dans un .h qui est là pour ne donner que le strict nécessaire.
C'est ubuesque !!!

Bah, je vais créer un namespace private_database que je n'appellerais que dans database_manager et ça sera très bien comme ça

C'est bien, les namespaces sont là pour structurer le code, mais faudrait quand même réfléchir 2 minutes à l'ensemble des namespaces, à leur fonction, et donc à leur noms.
Parce que "private_database", comme nom, c'est tout pourri.

Si vos classes ne servent qu'à rendre votre code imbitable, SUPPRIMEZ-LES !!!