Serait-il OK de mettre mes interfaces publiques dans leur propre paquet (pour mon organisation seulement).OK pour mettre mes interfaces publiques dans leur propre paquet
par exemple
com.example.myprogram - contains all normal code
com.example.myprogram.public - contains public accessible interfaces
com.example.myprogram.abstract - contains abstract classes
Est-ce une bonne ou une mauvaise chose à faire, sont-il des inconvénients?
Je ne voudrais pas cette pratique du tout. Vous devez regrouper les classes, abstraites et concrètes, et les interfaces en fonction des fonctionnalités.
Regardez l'API Java comme un exemple. Sun a-t-il séparé les interfaces Collections des implémentations? Les pratiques de Sun ne sont pas toujours le meilleur guide, mais dans ce cas je suis d'accord.
Ne le faites pas.
Je ne vois pas cela comme étant une mauvaise pratique, mais vous pourriez considérer comme une alternative l'organisation de vos affaires par fonctionnalité logique plutôt que la définition syntaxique, de sorte que tout le code pour une unité donnée de le code va dans le même paquet. C'est l'un des principes de modular programming. Cela dit, mettre toutes les interfaces (mais seulement celles) dans un paquet séparé peut être nécessaire en fonction de la taille du projet, et pourrait même devenir presque nécessaire si vous avez une architecture de plugin basée sur les composants purs (de sorte que d'autres le module ne connaît que les interfaces et l'implémentation réelle est en quelque sorte dynamiquement injectée).
Les interfaces publiques sont un contrat formel entre des modules ou des systèmes du système. À cause de cela, il est logique de les isoler du reste du code, pour les faire ressortir. Par exemple, dans un système sur lequel j'ai travaillé, toutes les interfaces publiques entre le serveur et les composants clients du système ont été placées dans un module système spécial (appelé, sans surprise, "api"). Cela a un certain nombre d'effets souhaitables, parmi lesquels ceux-ci: - sémantiquement, vous savez où regarder si vous avez besoin tout type d'information sur la façon dont la communication devrait avoir lieu - vous pouvez la version du module api séparément, ce qui est particulièrement utile lorsque vous ne veut pas de cible mobile, c'est-à-dire que vous signez un contrat pour délivrer une application qui prendra en charge "l'api v.1.1" plutôt que de jouer constamment pendant que quelqu'un d'autre change d'interface et vous oblige à adapter votre côté. ne signifie pas que vous ne devriez pas les organiser plus en sous-ensembles pour distinguer ce qu'ils sont pour. :)
En résumé, vous faites la bonne chose en séparant les interfaces du reste de la base de code, bien qu'en fonction de vos besoins spécifiques, vous fassiez bien d'aller plus loin et d'isoler les interfaces dans un module de système séparé.
Je peux vous suggérer 2 façons communes:
Si vous pensez vraiment que vos interfaces peuvent avoir plus de mises en œuvre à l'avenir (à savoir que vous travaillez sur l'API) puis les déplacer à un module séparé et créer il y a un paquet spécial avec le nom 'core', par exemple. (com.example.myprogram.core). Les implémentations devraient être dans des paquets correspondants (comme com.example.myprogram.firstimpl).
Si vous n'avez qu'une seule implémentation, laissez toutes vos interfaces dans le package com.example.myprogram et dans toutes les classes concrètes in com.example.myprogram.impl package.