Différence entre méthode et fonction

[Utilisateur supprimé] · mars 2019

P'tite question, sur Xcode y'a une p'tite fonction bien pratique "refactor" par contre je vois pas de différence en méthode et fonction. Elle se trouve ou la subtilité ?

klog · avril 2019

Apriori, une méthode est une fonction attachée à une classe (Objective-C). Une fonction est indépendante (type C).

[Utilisateur supprimé] · avril 2019

Ouais mais dans l'absolu je vois pas du tout ce que ça peut changer.
P'tet qu'ils ont fait leur feignant, pas envie de regarder si le fichiers est de l'objective ou du C, demerde toi

[Utilisateur supprimé] · avril 2019

Trouvé. Passage de pointeur à fonction.
En gros, la méthode n'est capable de retourner qu'une valeur/objet, la fonction permet d'avoir la modification de plusieurs variable simultanément.

Mala · avril 2019

@Harlo a dit :
Trouvé. Passage de pointeur à fonction.
En gros, la méthode n'est capable de retourner qu'une valeur/objet, la fonction permet d'avoir la modification de plusieurs variable simultanément.

Non. klog a expliqué la différence.

[Utilisateur supprimé] · avril 2019

Ben si, il a qu'une partie de la réponse. Test et tu verra bien.

Mala · avril 2019

Test et tu verra bien.

Même si j'ai tendance à l'hibernation depuis un moment, je suis sans nul doute le plus ours des modérateurs du site (et pas pour mon côté dormeur). Je codais déjà sous Xcode alors qu'il s'appelait Project Builder donc évite ce genre de réflexion avec moi...

@Harlo a dit :
Ben si, il a qu'une partie de la réponse. Test et tu verra bien.

Non il a dit tout ce qu'il fallait savoir. Le refactoring d'Xcode n'en est que l'application bête et disciplinée.

@Harlo a dit :
Trouvé. Passage de pointeur à fonction.
En gros, la méthode n'est capable de retourner qu'une valeur/objet, la fonction permet d'avoir la modification de plusieurs variable simultanément.

En gros tu ne maitrises pas le sujet. Tu n'as pas compris la subtilité entre méthode et fonction.

Pour faire synthétique:
1- Méthode et fonction même combat: une seule valeur/objet retournée.
2- Une méthode, de par son appartenance à l'instance d'une classe, peut accéder à toutes les variables de sa classe ainsi qu'aux variables et méthodes des classes dont elle hérite sous réserve que leur portée soit accessible (public, protected mais pas private).
3- Une fonction ne peut modifier que les variables à sa portée (locale ou les variables globales -mais peu recommandé de nos jours-). Dans le cas d'un objet la fonction doit passer par ses accesseurs publics pour le manipuler (et encore heureux).
4- Les fonctions viennent de la belle époque où la POO n'existait pas encore et où on connaissait la valeur d'un octet. On les utilise encore aujourd'hui car cela reste bien pratique quand on veut juste isoler un petit bout de code indépendant pas trop spécifique à une classe.

Est-ce que ça déjà c'est clair dans ton esprit?

Larme · avril 2019

Pour comprendre la différence entre fonction et méthode, il faut comprendre ce qu'est la Programmation Orientée Objet (POO) et ses atouts.

Là où c'est compliqué (si on n'a pas compris la POO), c'est qu'on utilise couramment les termes méthodes et fonctions à mauvais escient en voulant dire l'autre, parce qu'entre nous, on sait de quoi on parle, donc on sait si on parle vraiment de méthode ou de fonction infine.

Je dirais donc, sans rentrer dans les détails, que les fonctions n'ont pas de restrictions, que les seuls des objets peuvent appeler des méthodes d'instances et il y a aussi les méthodes de classes (que je vais omettre légèrement).
Les méthodes étant propres aux objets, c'est grosso-modo une fonction qui n'a de sens que si elle est appliquée à un objet en particulier. C'est une fonction où tu n'as pas besoin de mettre l'objet en question en paramètre, car c'est lui-même qui l'appel. Ça a ses avantages.

[Utilisateur supprimé] · avril 2019

C'est compliqué d'avoir des infos ici.

Merci

muqaddar · avril 2019

@Harlo a dit :
C'est compliqué d'avoir des infos ici.

Non, c'est simple, tu as eu 2 belles réponses.

Joanna Carter · avril 2019

Petit exemple en code :

Programmation procédurale

struct Person
{
  var forename: String

  var name: String

  var age: Int
}


func getFullPersonName(person: Person) -> String // function
{
  return "\(person.forename) \(person.name)"
}


{
    let person = Person(forename: "Joanna", name: "Carter", age: 21)

    print(person.forename)

    print(person.name)

    let fullName = getFullPersonName(person: person)

    print(fullName)
}

POO

struct Person
{
  var forename: String

  var name: String

  func getFullName() -> String // method
  {
    return "\(forename) \(name)"
  }

  var age: Int
}

{
    let person = Person(forename: "Joanna", name: "Carter", age: 21)

    print(person.forename)

    print(person.name)

    print(person.getFullName())
}

tablier · avril 2019

Ouais, c'est exactement ça ! Moi qui programme depuis les années 65-66 (1900, pas 1800) j'ai eu beaucoup de mal à aborder la POO quand je l'ai découverte !!!!! mais quand on a compris comment ça s'articule ça simplifie la vie !

Pyroh · avril 2019

@tablier a dit :
Ouais, c'est exactement ça ! Moi qui programme depuis les années 65-66 (1900, pas 1800) j'ai eu beaucoup de mal à aborder la POO quand je l'ai découverte !!!!! mais quand on a compris comment ça s'articule ça simplifie la vie !

Je travaille avec des gens qui pleurent le COBOL et considère que la POO est une hérésie. C'est pas facile tous les jours...

Joanna Carter · avril 2019

@Pyroh a dit :
Je travaille avec des gens qui pleurent le COBOL et considère que la POO est une hérésie. C'est pas facile tous les jours...

Joanna Carter · avril 2019

Pour être plus "Swifty", on peut utiliser un var "calculé" à la place d'une méthode. En effet, c'est une var, en lecture seule, avec une méthode "encastrée"

struct Person
{
  var forename: String

  var name: String

  var fullName: String
  {
    return "\(forename) \(name)"
  }

  var age: Int
}

{
    let person = Person(forename: "Joanna", name: "Carter", age: 21)

    print(person.forename)

    print(person.name)

    print(person.fullName)
}

klog · avril 2019

@Pyroh a dit :

@tablier a dit :
Ouais, c'est exactement ça ! Moi qui programme depuis les années 65-66 (1900, pas 1800) j'ai eu beaucoup de mal à aborder la POO quand je l'ai découverte !!!!! mais quand on a compris comment ça s'articule ça simplifie la vie !

Je travaille avec des gens qui pleurent le COBOL et considère que la POO est une hérésie. C'est pas facile tous les jours...

Houla... Cobol ?!
Je croyais qu'on en avait fini

Draken · avril 2019

@Pyroh a dit :

Je travaille avec des gens qui pleurent le COBOL et considère que la POO est une hérésie. C'est pas facile tous les jours...

Sont-ils au courant qu'il existe un COBOL Objet depuis 1997 ?

Pyroh · avril 2019

@Draken a dit :

@Pyroh a dit :

Je travaille avec des gens qui pleurent le COBOL et considère que la POO est une hérésie. C'est pas facile tous les jours...

Sont-ils au courant qu'il existe un COBOL Objet depuis 1997 ?

Hérétique !

Sinon plus sérieusement ici au Luxembourg un bon COBOListe indépendant gagne très bien sa vie avec toutes ces banques qui conservent pas mal de leurs applications backend en COBOL et les AS400 qui vont avec. Visiblement le passage au Java (sic) se passe assez mal dans la majorité des cas et ils sont obligés de maintenir des codes ayant connu Mathusalem —si pas écrits par lui...

Donc si tu es plus ou moins jeune, que tu es bon en COBOL, que tu aimes déclarer toutes tes variables en haut de ton code, que lire du code imprimé par une imprimante matricielle sur du papier avec les petits trous sur le côté est ta passion et que tu aimes l'argent, le Luxembourg est fait pour toi !

Remarquez ça doit aussi marcher pour la Suisse.

Céroce · avril 2019

Je travaille avec des gens qui pleurent le COBOL et considère que la POO est une hérésie. C'est pas facile tous les jours...

Je t'avoue que plus j'étudie la programmation fonctionnelle, plus je trouve la POO bizarre.
Cette manière de créer des entités sensées représenter des objets réels mais qui finissent tous par s'appeler Manager ou Controller.
Cette gymnastique pour y faire entrer ou sortir des données.

Au final, le meilleur moyen de s'en sortir est d'avoir un maximum d'objets immutables.
Alors on pourrait dés-encapsuler les méthodes des objets qu'on ne verrait pas trop la différence. Et on arriverait à la programmation fonctionnelle.

Pyroh · avril 2019

@Céroce a dit :

Je travaille avec des gens qui pleurent le COBOL et considère que la POO est une hérésie. C'est pas facile tous les jours...

Je t'avoue que plus j'étudie la programmation fonctionnelle, plus je trouve la POO bizarre.
Cette manière de créer des entités sensées représenter des objets réels mais qui finissent tous par s'appeler Manager ou Controller.
Cette gymnastique pour y faire entrer ou sortir des données.

Au final, le meilleur moyen de s'en sortir est d'avoir un maximum d'objets immutables.
Alors on pourrait dés-encapsuler les méthodes des objets qu'on ne verrait pas trop la différence. Et on arriverait à la programmation fonctionnelle.

Oui je connais ton scepticisme grandissant face à la POO. Ce que je comprends.
La majorité des projets bordéliques que j'ai pu voir ne l'étaient pas à cause de la POO mais surtout lié au fait que les gens ont oublié que ça impliquait une solide phase d'analyse. Les diagrammes sont tombés en désuétude ces dernières années, l'UML est moqué et considéré comme une pratique obsolète.
En POO on ne peut pas vraiment "pisser" du code comme on dit dans le jargon. Enfin si mais on fini souvent par se pisser sur les pompes. Le problèmes des contrôleurs et autre managers que tu décris est souvent la preuve d'une analyse bâclée. Ces objets sont autant de petites cales employées à aligner des objets mal conçu ou conçus sans tenir compte du reste.

J'avais une prof qui avait l'habitude de dire qu'une bonne architecture objet relevait autant de compétences techniques que de sensibilité artistique. Elle était un peu perchée mais je pense que sur le coup-là elle avait pas tort 😃

Draken · avril 2019

@Céroce a dit :
Je t'avoue que plus j'étudie la programmation fonctionnelle, plus je trouve la POO bizarre.

J'adore la POO, tout en la pratiquant d'une manière probablement peu orthodoxe. Bon c'est vrai que je suis un autodidacte complet, avec une formation d'électronicien à la base. N'ayant jamais eu de véritable cours d'informatique, je bricole à ma manière. J'ai beaucoup été influencé par un ouvrage sur la programmation orientée agents, que j'ai lu dans les années 90. Concevoir une application comme une petite société d'agents collaborants pour remplir des tâches colle parfaitement à ma manière de penser.

Cette manière de créer des entités sensées représenter des objets réels mais qui finissent tous par s'appeler Manager ou Controller.

Oui, mais un logiciel est un outil de traitement de l'information. Il est assez normal que les objets fassent du travail de gestion, contrôle et stockage des données.

Céroce · avril 2019

@Pyroh a dit :
Oui je connais ton scepticisme grandissant face à la POO. Ce que je comprends.
La majorité des projets bordéliques que j'ai pu voir ne l'étaient pas à cause de la POO mais surtout lié au fait que les gens ont oublié que ça impliquait une solide phase d'analyse.

Justement, le besoin d'une longue phase d'analyse est un grand défaut de la POO en soi.
N'importe qui d'un peu sérieux liste les données et les traitements qui doivent être effectués.

Ensuite il faudrait définir des Objets et leur affecter des Responsabilités — faites des CRC cards qu'ils disent! — puis essayer de connecter le tout à base de protocoles, d'héritages et de design patterns.

Une fois qu'on a nos beaux schémas, il faut alors se confronter à la réalité:

on reçoit des données de l'extérieur sous forme de fichiers, de JSON, de tables de Base de données. Il faut convertir tout ça en objets.
on se repose sur des frameworks qui ont leur propres principes.
les nouvelles specs qui arrivent cassent tous nos jolis plans et belles abstractions.

Les diagrammes sont tombés en désuétude ces dernières années, l'UML est moqué et considéré comme une pratique obsolète.

Par rapport à mon avis donné ci-dessus, je considère moi-aussi la phase de conception POO comme obsolète. Je ne fais plus trop de diagrammes de classe depuis 4 ou 5 ans. Avant, je voyais ça comme un mal nécessaire, aujourd'hui je me dis que je fais les objets les plus simples possibles, les plus facilement remplaçables et que j'évite tout code «intelligent». Je préfère avancer, et faire du refactoring dans la direction que je me suis donné.
Et cette libération fait un bien fou.

Mais là où notre pensée se rejoint est qu'on manque de réflexion dans le métier de programmeur aujourd'hui. Il semble qu'on soit toujours pressé et interrompu. Quitte à passer pour un vieux con, c'est peut être générationnel: les jeunes sautent de l'IDE à Slack, à Twitter, aux e-mails sans arrêt. Ça rend difficile tout travail de réflexion profonde.

Joanna Carter · avril 2019

Je pratique le POO pendant presque 30 ans. Ça devrait être appelé APOO (analyse et programmation orienté objet), car la programmation sans l'analyse ne vaut rien. Et c'est là le problème ; très peu prennent le temps d'apprendre l'analyse.

Et c'est les environments de développement qui l'encouragent. Avec Xcode, on peut construire un "modèle" CoreData comme on construirait une base de données. Mais c'est seulement les objets "persistants" ; on oublie qu'il y a encore les "objets de fonctionnalités" qui contiennent et gèrent les objets persistants.

Du coup, les ViewControllers deviennent les récipients de n'importe quel code, y compris les données, les "managers", la validation, les "state machines", etc.

Moi, je suis passionnée de la structure MVP.

Presenter
— Model
——CommandSet
———Command(s)
—— Selection
— View
— Interactor(s)

Avec ça on peut séparer les domaines d'interêt.

Le problème avec Cocoa et UIKit est qu'ils proposent un lien très fort entre la vue et le contrôleur ; du coup, il est attendu que tous les interactions soient rédigées dans le contrôleur, souvent, plusieurs fois, le même code dupliqué d'un autre contrôleur.

D'où vient l'idée des "interactors", que l'on puisse rédiger indépendamment pour gérer l'interaction entre un UITextField (ou autre composant) et une var d'un certain type. J'ai écrit une série d'articles sur le sujet : https://joannamacdev.github.io/Interactors-Part-1/

Une fois que l'on a construit tout les composants de base de MVP, on peut les hériter pour "specialiser" leurs comportement selon les différents types, mais leurs fonctionnalités et leurs interactions sont déjà prises en charge :

On peut avoir les "interactors" qui gèrent les zones de saisi, ou qui gèrent les actions des boutons ou des menus. Pour les boutons, on n'a pas besoin de mettre les titres là dessus, il suffit de spécifier le nom du command que l'on voudrais exécuter et l'interactor mettrait le titre sur le bouton et se connecte au command.

Ceux sont tous les "objets" qui contiennent leurs propres états et qui permettent de "capsuler" les données et les comportements qui sont connectés.

Oui, c'est beaucoup d'effort de créer les "frameworks" mais, après on peut les réutiliser ave beaucoup moins de code, surtout dans les ViewControllers !

Différence entre méthode et fonction

Réponses