[Ruby] Mes premières classes, recherche de défaut

[Maz]

Bonjour, dans le but de coder en ruby différemment qu'en "php avec la syntaxe ruby", j'aimerais vous montrez 3classes que j'ai créé juste pour l'entraînement, j'ai suivi ce tuto qui nous apprends entre autres: boucles, itérations, conditions, comparaisons, type de variables, fonctions, classes... Un truc pour bon gros débutant comme moi. Ce que je recherches sont les critiques!

Voici donc mes 3classes:

class Adresse

	attr_accessor :numero, :rue, :code_postal, :ville, :pays

	def initialize(numero, rue, code_postal, ville, pays)

		@numero = numero

		@rue = rue

		@code_postal = code_postal

		@ville = ville

		@pays = pays

	end

	def to_s # Génère l'adresse complète

		@numero + " " + @rue + "\n" + @code_postal + " " + @ville + ", " + @pays

	end

end



class Personne

	attr_accessor :nom, :prenom, :adresse, :telephone, :adresse_email

	def initialize(nom, prenom, adresse, telephone, adresse_email = nil)

		@nom = nom.upcase

		@prenom = prenom.capitalize

		@adresse = adresse

		@telephone = telephone

		@adresse_email = adresse_email

	end

	def nom_complet

		@nom + " " + @prenom

	end

	def afficher # Affiche les coordonnées

		text_list = "Contact: " + nom_complet + "\n"\

		"Telephone: " + telephone + "\n"\

		"Adresse email: " + adresse_email + "\n"\

		"Adresse: \n" + adresse.to_s + "\n----------------------------------\n"

		text_list

	end

end



class Carnet

	def initialize(personnes)

		@personnes = []

		personnes.each do |personne|

			ajouter(personne)

		end

	end

	def ajouter(personne)

		@personnes.push(personne)

		@personnes = @personnes.sort { |a,b| a.nom_complet <=> b.nom_complet }

	end

	def retirer(personne)

		@personnes.delete(personne)

	end

	def chaque_personne # itérateur

		@personnes.each { |p| yield(p) }

	end

end

Merci.

[srm]

Préambule : je ne code pas tellement en Ruby

Ça me semble pas mal du tout ça

[Maz]

J'ai beaucoup essayé d'utiliser vraiment ruby comme il se doit, après 6ans de php, c'est un peu dur de penser façon ruby... Mais dorénavant je comprends beaucoup mieux les codes de Rails... je ne savais même pas que les each do était en fait des boucles... Il y a quelques points dans mes class sur lesquels j'ai un peu de doute sur "l'optimisation", tant technique que du point de vue visibilité, par exemple: dans une méthodes, on ne fait pas de return? j'ai essayer avec return text_list par exemple pour la méthode personne#afficher, ça fonctionnes, mais ça fonctionnes aussi sans... j'ai même essayer sans la variable text_list, ça marches aussi... Pour un codeur php c'est un peu bizarre de voir ça, mais bon, je m'y ferais ,) j'ai remarqué aussi que le adresse_email = nil dans personne#initialize était inutile... Si une variable n'est pas déclaré dans l'appel de la méthode, ça ne renvoi pas d'erreur? J'ai essayer new personne("Billoir", "Romain"), sans spécifier adresse ou autre variable qui ne sont pas défini comme optionnel, aucune erreur ne m'est renvoyé... Je trouves aussi les itérateurs vraiment très puissant et à la fois super simple d'utilisation.

[Sephi-Chan]

Je te conseille de passer à l'anglais tout de suite, c'est plus approprié pour le développement et encore plus pour Ruby on Rails, qui utilise beaucoup l'inférence de noms.

Généralement, on n'écrit pas explicitement le return : Ruby retourne automatiquement la dernière expression appelée.

Je n'aime pas trop cette méthode "afficher" pour tes personnes : je te conseille plutôt d'utiliser to_string.

Ensuite, je ne trouve pas la définition d'un itérateur pertinente : faire directement @address_book.contacts.each est infiniment plus naturel.

Enfin, je te recommande d'utiliser l'interpolation de chaîne plutôt que la concaténation (la coloration syntaxique est meilleure dans les éditeurs).

@numero + " " + @rue + "\n" + @code_postal + " " + @ville + ", " + @pays

"#{@numero} #{@rue}\n#{@code_postal} #{@ville}, #{@pays}"

Après, je ne sais pas trop si ce genre d'exercice te sera vraiment utile dans la mesure où tu écriras souvent des modèles/contrôleurs qui te fourniront un socle différent (par exemple, tes constructeurs ne prendront jamais une liste nom, prénom, etc. mais un hash d'attributs).

[Maz]

Je te conseille de passer à l'anglais tout de suite, c'est plus approprié pour le développement et encore plus pour Ruby on Rails, qui utilise beaucoup l'inférence de noms.

Généralement, on n'écrit pas explicitement le return : Ruby retourne automatiquement la dernière expression appelée.

Je n'aime pas trop cette méthode "afficher" pour tes personnes : je te conseille plutôt d'utiliser to_string.

Ensuite, je ne trouve pas la définition d'un itérateur pertinente : faire directement @address_book.contacts.each est infiniment plus naturel.

Enfin, je te recommande d'utiliser l'interpolation de chaîne plutôt que la concaténation (la coloration syntaxique est meilleure dans les éditeurs).

@numero + " " + @rue + "\n" + @code_postal + " " + @ville + ", " + @pays

"#{@numero} #{@rue}\n#{@code_postal} #{@ville}, #{@pays}"

Après, je ne sais pas trop si ce genre d'exercice te sera vraiment utile dans la mesure où tu écriras souvent des modèles/contrôleurs qui te fourniront un socle différent (par exemple, tes constructeurs ne prendront jamais une liste nom, prénom, etc. mais un hash d'attributs).

Check, check, check, check.
Par contre:
Oui, j'y trouves déjà une utilité, je comprends déjà beaucoup mieux ce que je fait sur Rails, quand on passes de php à Rails, sans passer par les fondamentales de Ruby, on se demandes si les syntaxes:
@variable
:variable
variables.each do |variable|

sont des syntaxes spéciales inventé par Rails, maintenant j'ai ma réponse.

Et puis de toute manière, mon but étant de faire un projet complexe de jeu web (j'allais dire jeu php...). Je ne pourrais pas tout faire avec Rails je penses (bien que je ne connaisses pas ses limites), mais déjà j'ai vu que les Active Record ne supportaient que les types suivant:

• :primary_key
  
• tring
  
• :text
  
• :integer
  
• :float
  
• :decimal
  
• :datetime
  
• :timestamp
  
• :time
  
• :date
  
• :binary
  
• :boolean
  

Or j'aurais besoin d'enum par exemple. Mais j'ai vu que pour "gruger", on utiliser string et on faisait la vérification du enum directement depuis le formulaire qui feras l'entrée en BDD. Mais j'ai aussi besoin du type point de PostgreSQL... Une idée pour le gruger?

[Sephi-Chan]

Tu as plus simple pour l'enum. Une simple chaîne avec un validateur.

class Person < ActiveRecord::Base

  GENDERS = [ 'male', 'female' ]

  validates_inclusion_of :gender, :in => Person::GENDERS

end

Pour ce qui est du type point, il faudrait que tu me décrives un peu le truc, j'ai peut-être une piste pour toi avec la composition. Et après, il doit sûrement exister des adapters pour les types géométriques des différentes bases.

[Maz]

Le type point est formé ainsi: (n, n). Tout simplement. Mais ensuite j'ai des type path: ((n, n), (n2, n2), (n3, n3)) probablement dans le futur aussi des type circle etc mais si j'arrives à gruger point, en théorie j'arrives pour path et le reste suivras. J'ai pas spécialement envie de passer en regex tout ce foutoirs :p

[Viciousity]

Même remarque que Sephi, nommer ses classes en anglais est mille fois plus naturel pour des langages tels que Ruby
Rajoutes à cela que Rails est un framework du type "Convention over configuration" et tu verras que même si cela demande parfois un certains effort, chercher et utiliser un nom adapté et cohérent pour tes classes est vraiment essentiel

[Sephi-Chan]

Tu peux dans ce cas utiliser la composition avec (composed_of), ça te permet d'avoir des objets composés (adresse, monnaie, coordonnées) au sein d'une entité.

Ça permet d'avoir par exemple un objet de la classe Address dans l'attribut address d'un utilisateur.

Jette un œil à la page de doc que je t'ai donné et fais quelques essais. Tu verras bien si ça colle à ton besoin.

[Maz]

ça m'as l'air d'être un bon début de piste, mais, mon champs si j'utilise composed_of seras un string et juste les objets en entrée et sortie seront des Class Point par exemple? si c'est le cas c'est pas l'idéal car j'utilise des fonction PostgreSQL tel que le calcul de la taille d'un chemin etc... J'ai choisi PostgreSQL pour ces fameux types géométriques qui collent beaucoup mieux aux jeux web que MySQL (qui de plus est beaucoup moins respectueux des normes SQL).