Omis de généraliser des codes communs pour TableMECOLUMN de JAVAFX

SuperColumn<Person, String> column = new SuperColumn<>("Email", 100, "email");

Juste en termes de style de programmation général, il n'est pas particulièrement pratique de sous-classer une classe uniquement dans le but de configurer les instances créées, à moins que vous fournissez des fonctionnalités supplémentaires qui ne soient fournies par la classe de base. Si la sous-classe ne fait rien d'autre qu'un constructeur, il s'agit d'un indicateur particulier de cet anti-motif. Une meilleure approche, que je vais montrer ici, est d'utiliser une sorte de motif créé, qui peut être aussi simple que certaines méthodes statiques qui créent des instances pour vous. (Des implémentations plus avancées utiliseraient divers modèles d'usine.)

Quoi qu'il en soit, une version de ce que vous essayez de faire, ce qui ne repose pas sur la réflexion (je vais expliquer plus tard pourquoi je n'aime pas l'approche réflexive) aurait besoin que vous puissiez passer dans une sorte de fonction qui traite la nouvelle valeur (éditée) pour une instance personne particulière. < Code> biconsumer fonctionne bien pour cela: xxx

que vous créeriez avec xxx < / Pré>

Notez que l'exemple que vous avez lié n'est pas particulièrement bon (même si c'est le "officiel" d'Oracle: c'est vraiment très vieux). Une classe de modèle ( personne ) qui utilise des propriétés JavaFX devrait vraiment fournir des méthodes "accesseur de propriété": xxx

Utilisation de cette version de la personne classe, votre colonne de table doit simplement accéder à la propriété spécifique pour obtenir la valeur (dans le CellValueFactory ) et pour définir la valeur (dans le gestionnaire ONEDITCOMMIT ). Ainsi, tout ce dont vous avez besoin est une fonction qui fournit la propriété pour une instance personne donnée. Vous pouvez également généraliser facilement cela à une valeur de ligne paramétrée de type S : xxx

et maintenant vous faites xxx < / PRE>

Cette approche évite à la fois à l'aide de la réflexion directement et à l'aide du héritage PropertyValueFactory (qui utilise une approche similaire à base de réflexion sous la hotte). Le principal avantage est que le compilateur vérifiera maintenant que les méthodes appropriées existent et toutes les erreurs sont capturées lors de la compilation. (En revanche, lors de la spécification du nom de la méthode à l'aide de la réflexion ou du nom de la propriété dans le PropertyValueFactory , les erreurs ne peuvent pas être prises par le compilateur et échoueront simplement au moment de l'exécution, soit silencieusement (aucune donnée ne figure) ni avec une exception.)

juste pour l'exhaustivité, si vous voulez vraiment utiliser une sous-classe pour cela, cela ressemblerait à xxx

mais je Devrait souligner que cela n'est pas un bon usage de l'héritage, et vous devriez préférer l'approche basée sur les méthodes (ou en usine).