Discussion :

[Alexino2]

Salut tout le monde,

Je me demandais s'il existait un typage d'accès empêchant de modifier une variable dans d'autres classe ?

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Toto {
     access int nombre = 0;
     public Toto() {
          this.nombre = 10; // == OK !
     }
}
 
class Titi {
     public Titi() {
         Toto toto = new Toto();
         System.out.println(toto.nombre); // == OK !
         toto.nombre = -1; // == Error !
     }
}

Le problème étant que je n'en ai un peu marre de mettre des get() partout dans mon code sur du private....

[Alexino2]

Bon je vous avoue que de passer de Javascript à Java après des années, c'est dur ! J'étais tellement habitué à nommer mes variables "spot.light.blue" que Java est devenu un casse tête lorsque j'ai voulu faire la même chose.

Je me rend compte que ce sont des langages bien différents, et qu'un simple un simple Inner ou access devient un enfer...

D'un autre côté la logique est plus forte du côté de java, ça permet de réfléchir plus et d'accélérer la compile ^^

J'ai l'impression de vivre dans deux monde différents, mais je regarde la rapidité de nos pages web, je me dis que javascript ferait mieux de s'inspirer de Java avant même d'être une usine à gaz à la Angular.js ou autres frameworks qui ralentissent les pages, lorsqu'on ne comprend pas la logique même d'un objet...

[thelvin]

Pour ta première question, si la variable n'est jamais censée changer après qu'on lui ait donné une valeur, on peut toujours utiliser final. C'est util pour les variables public static, par exemple, ce sont des genres de constantes.

Mais sinon, non. Que ça te plaise ou pas, Java est fondamentalement organisé pour utiliser les getters et setters, point final.
Du coup, les outils se sont adaptés et ils le font pour nous.

[helron1977]

les variables d'instances ont une visibilité private.
Puisqu'elles ne servent qu'à instancier , nul besoin que leur visibilité soient publics.

mais j'écris pour poser une question de convention. Pour savoir ce qui se fait en programmation Java.

J'ai vu plusieurs tutos et j'ai déjà vu plusieurs façon de procéder.

J'ai vu un tutoriel qui initialiser les variables tout de suite.
J'ai vu un tuto qui initialise les variables dans un constructeur par defaut ( sans arguments) et qui déclare un deuxième constructeur avec arguments ( génération automatique) et un this.variableInstance.
J'ai vu un tuto qui déclare deux constructeurs, un defaut et un avec arguments et des "property/getters-Setters/..." et qui initialise et définit les variables d'instances par l'appel des méthodes set.

Laquelle dois je utiliser pour écrire correctement, puisque toutes fonctionnent ? Y a t il une convention ou une bonne pratique ? Mon Ide genere des this... mais je comprends l'appel de methode...

[thelvin]

Hello,

Tout ça est correct et également utilisable. Tu fais ce que tu veux.

Tu peux préférer initialiser les variables dès la construction, lorsque cela est possible et pragmatique. Cela permet de ne jamais avoir l'objet dans un état incomplet, et aussi, éventuellement de rendre la classe immutable, ce qui la rend thread-safe. Mais ce n'est pas forcément possible et pragmatique. Par exemple quand il y a beaucoup de variables on ne veut pas faire un constructeur avec 15 paramètres. Et les constructeurs avec paramètres, c'est pas le plus simple pour faire des beans compatibles avec Spring, la sérialisation automatique JSON/XML, ou Hibernate.

Concernant l'utilisation de this.truc, ou bien de setTruc() dans le constructeur... Ça se vaut. Il y a une certaine tendance à écrire les constructeurs avant les setters et donc à utiliser this.truc. A l'inverse, dans le cas très improbable mais imaginable où les setters seraient modifiés pour faire plus que juste assigner la variable, mais aussi de la validation ou du logging par exemple, il vaut mieux toujours passer par le setter, d'où l'idée de setTruc() même dans le constructeur. C'est rarement nécessaire, mais ce n'est pas un mal non plus.

[Alexino2]

Mais sinon, non. Que ça te plaise ou pas, Java est fondamentalement organisé pour utiliser les getters et setters, point final.
Du coup, les outils se sont adaptés et ils le font pour nous.

Du coup, je me demandais si on pouvait conventionnellement écrire le code de cette manière ? Pour libérer les lignes de codes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public int getId() { return this.id; } 
public String getName() { return this.name; } 
 
public void setId(int id) { this.id = id; }
public void setName(String name) { this.name = name; }

Petite note : j'ai finis par retirer tous les constructeurs de mon code. Ainsi, je laisse ma Data gérer toutes les instanciations de manière indépendante et c'est mon contrôleur qui se charge de setter les liaisons.

[OButterlin]

Ce n'est pas conforme au formatage usuel en java mais ça reste juste.
Comme tu es à l'économie, tu peux aussi te passer de this dans les getter, ça ne sert à rien (c'est utile dans le setter parce que le paramètre a le même nom que l'attribut et du coup, il faut savoir de "qui" on parle... si le paramètre avait un autre nom, ce serait également inutile)

[Alexino2]

Oui, du coup, j'ai inversé un peu :

public int id() { return this.id; }
public void setId(int id) { this.id = id; }

public String name() { return this.name; }
public void setName(String name) { this.name = name; }

Le "this" est plus pour la lisibilité du code. Dans ce dernier exemple, j'ai viré le getId() par id(). mais en gardant le set en dessous.

Par exemple, je préfère un calcul dans la même classe avec this.id() == id plutôt que que getId() == id ou id == paramId

Dans une classe externe je préfère aussi un toto.id() == id plutôt qu'un toto.getId() == id, vu que l'id est implicitement lié à toto.

Java ne s'est pas ennuyé à faire des list.getMapt(Toto).getStream("") partout....

[OButterlin]

C'est un choix, cependant, il faut être conscient que beaucoup d'outils auraient des problèmes avec une classe ne respectant pas les règles d'un java bean...

[Alexino2]

J'ai encore du mal à cerner les java beans, c'ést bien les Serializable ?

J'utilise Notepad++, je commence tout juste à les implémenter. Dans ma tête JavaBeans = SQL = Table = DataBase

J'ai encore du mal à leur faire confiance car je ne les connais pas bien et ne vois pas les règles dans notepad ni dans le fichier sauvegardé :/ Je m'aperçois déjà qu'une simple modification dans l'implémentation du Serializable m'apporte des erreurs. Je supprime juste le fichier ".ser" dans mon bin pour régler le problème.

Du coup, j'ai mis des contrôleurs un peu partout et le minimum de chose dans ma classe qui implémente Serializable en suivant le principe MVC + Table Seriazable. Toutes mes variables dans mes Tables sont publiques, ce qui m'évite de sauvegarder de la logique ou des get/set que j'ai mis dans des contrôleurs à part.

Je voulais surtout pas m'ennuyer à gérer des XML, textes ou implémenter un server SQL tout en faisant la même chose : sauvegarder de la data !

[OButterlin]

Ce que tu décris est plus de l'ordre de l'Entity, lui représente une classe liée à un enregistrement de base de données, utilisé par exemple avec JPA dans le monde EE.

Le JavaBean est une classe simple (pojo) avec certaines conventions :

• la classe doit être « Serializable » pour pouvoir sauvegarder et restaurer l'état d'instances de cette classe ;
• la classe doit posséder un constructeur sans paramètre (constructeur par défaut) ;
• les attributs privés de la classe (variables d'instances) doivent être accessibles publiquement via des méthodes accesseurs construit avec get ou set suivi du nom de l'attribut avec la première lettre capitalisée. Le couple d’accesseurs est appelé Propriété ;
• la classe ne doit pas être déclarée final.

Une classe Serializable n'a pas besoin d'être un JavaBean, on indique juste qu'elle peut être convertie en flux binaire pour être (entre autres) transférée sur une jvm distante ou sauvegarder sur un support.

[Alexino2]

Les premiers tutoriels sur les Jpa me donnent mal au crâne :/

Effectivement, j'ai un peu dévié le seriazable pour en faire une sorte de "XML" binaire grâce aux OutPutStream :

Table.java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class TablePlayer implements Serializable {
	public String[] names = {/*0*/ "Infiltrator", /*1*/ "Cleric", /*2*/ "Minstrel", /*3*/ "Cabalist",
					/*4 */ "Necromancer", /*5*/ "Mercenary", /*6*/ "Reaver", /*7*/ "Paladin",  /*8*/ "Friar"};
}

User.java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class User implements Serializable {
	public TablePlayer tabPlayer = new TablePlayer();
}

Control.java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class Control {
	private User user;
 
	public Control (User user) { this.user = user; }
 
	public TablePlayer player() { return user.tabPlayer; }
        public void setPlayerName(int index, String name) { user.tabPlayer[index] = name; }
}

Storage.java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class Storage {
 
	private ArrayList<User> users = new ArrayList<User>();
 
	 // Control will manage all methods that doesn't need to be stored
	public User create() {
		User user = new User();
		this.users.add(user);
		this.save();
		return user;
	}
 
	public void save()  {
		File f = new File("Save.ser");
		if (f.isFile() && f.canRead()) f.delete(); // clean the file
		 try (OutputStream file = new FileOutputStream("Save.ser");
			ObjectOutputStream writer = new ObjectOutputStream(file) ) {
			writer.writeObject(this.users);
			writer.close();
		} catch (IOException e) { e.printStackTrace(); }
	}
}

Edit : enfin l'utilisation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
    public static void main(String args[])  { 
 
		Storage store = new Storage();
		User user1 = store.create();
		User user2 = store.create();
 
		Control control = new Control(user1);
		control.setPlayerName(1, "Toto");
		store.save();
    }

[OButterlin]

C'est une façon comme une autre d'enregistrer des états, en fonction du contexte, c'est peut-être même la meilleure des solutions, rapide, compacte

[Alexino2]

Je vais peut-être dire une bêtise, mais si Java était doté d'un outil "Base de données binaire", ça ferait longtemps que SQL et autre XML seraient tombés aux oubliettes ? Sans parler des problèmes de sécurités qui auraient déjà été résolus...

Ce OutputStream me simplifie tellement la vie dans la gestion des données. Dommage que Java (ou autres?) ne fassent pas plus d'efforts pour stocker des données sans passer par des requêtes ou des frameworks usine à gaz :'(

[thelvin]

Ben... Y a pas que Java dans la vie.

Tu te rappelles, le web ? Ce truc dont le principe est que n'importe quel acteur peut être interrogé par n'importe quelle technologie ? Peu importe si c'est un PC, Mac ou téléphone, peu importe IPv4 ou IPv6, peu importe si le truc est en C, Python, PHP, Java ou assembleur ?

Par ailleurs, à partir d'une certaine importance du stockage de données, le stockage de données devient une responsabilité en soi. Il faut donc un acteur dont c'est le rôle, et les utilisateurs doivent pouvoir en obtenir ce dont ils ont besoin. Y faire des requêtes donc. Les collections standards fournies avec Java, comme HashMap, deviennent un peu trop simplistes à partir d'une certaine échelle de quantité de donnés, il faut donc faire plus compliqué.