Je veux modéliser la situation suivante dans OOP:
Je veux que la classe de fret soit une classe abstraite, car j'aimerais que mon programme facture des frais supplémentaires en fonction du degré de danger qu'un morceau de cargaison a.
réellement le problème que J'ai eu, c'est que je veux que la classe de fret soit une gamme d'objets. Je veux dire qu'il peut stocker des bagages et des morceaux de cargaison. Ma question est de savoir où puis-je mettre une méthode appel additem? Devrais-je le mettre dans la pièce de bagages et morceau de classes de cargaison? Ou devrais-je mettre une méthode abstraite générale appelée AddiTem dans la classe de fret? Quelque chose comme ça (j'utilise Java à cet effet): de sorte que dans mon programme principal, je peux faire quelque chose comme: Toute suggestion où je peux mettre cette méthode AddiTem?, de sorte que le fret de la classe contienne une gamme d'objets de bagages de type et de cargaison? Merci
8 Réponses :
Si vous voulez Faire chaque classe s'étend Freight CODE> Pour pouvoir contenir ces autres types, vous avez trois options: fret code>: p> class DeliveryItem
{
addItem(DeliveryItem item){...}
}
class Luggage extends DeliveryItem
{
//override addItem if need be
}
class Freight
{
List<DeliveryItem> items = new ArrayList<DeliveryItem>();
List<DeliveryItem> getItems()
{
return this.items;
}
void addItem(DeliverItem item)
{
this.items.add(item);
}
}
@ Woot4moo pourquoi ne pas utiliser une interface "DeliveryItem"?
@Pring car il y a probablement une fonctionnalité par défaut qui peut être fournie. C'est une fonction additionnelle standard avec une implémentation standard pouvant être remplacée s'il existe une nécessité de fournir un ajout amélioré.
@Jma demandez-vous comment fret donne accès à son ensemble interne de DeliveryItem S?
@ Woot4moo, oui comment il peut mettre des éléments dans le delivery et comment y accéder
@Jma mise à jour. Vous pouvez simplement écrire des accesseurs et des mutateurs (getters / setters) pour gérer ce type d'activité.
Merci beaucoup @ woot4moo, une dernière question pour la fermeture, comment implémentez-vous l'additem dans la classe DeliveryItem, est-ce une méthode abstraite?
@JMA Dans ce cas particulier, je le laisserais comme abstrait, car il ne semble pas y avoir de comportement par défaut, vous pouvez fournir.
@ Woot4MOO et les attributs pour le fret, comme ID et poids, devraient rester sur le fret ou devraient être déplacés vers DeliveryItem ?. Je demande cela parce que maintenant des bagages et des cargaisons sont hérités de la livraison et plus de marchandises
envisagez de casser votre classe de fret en deux classes:
En général, une heuristique pour la conception orientée objet est de rendre chaque classe représenter exactement un concept.
Je pense qu'il y a une faille de conception ici si je comprends ce droit. Vous devez utiliser un objet conteneur comme extrait de Wikipedia: Vous pouvez utiliser un objet "feuille" au cas où vous avez affaire à un fret concret et s'il est juste un "conteneur "Vous pouvez utiliser le" composite ". Ce pseudo code indique la faille de conception: dans un objet feuille, vous ne pouvez pas fournir une implémentation sensible pour fret qui contient une collection d'éléments. Mais si vous collez avec cette conception ce dont vous avez besoin ici est un composite Je pense. additem .
Je veux dire qu'il peut stocker des bagages et des morceaux de cargaison. em> p>
Cela sonne un lot affreux plus comme une relation code> relation code>, qu'un
héritage code> relation. Par exemple, pensez à une superclasse plus logique, commeélément code> et fairecargo code> etbagages code> une sous-classe de celle-ci. P>public Luggage() { super(5); // Example value. // Rest of constructor. }
Pourquoi ne pas utiliser l'interface pour la classe d'articles?
Pensez que mon édition a simplement souligné un avantage d'utiliser une classe abstraite.
Actually the problem that I got is that I want that the Freight class to be an array of objects. I think your concept mixes up holding the freight and being the freight, which leads to your design problem. Without knowing your whole environment, think about this design:class FreightContainer: Holds your array (actually I would recommend a LinkedList or ArrayList, depending on the O(n) you want to have during runtime). Is responsible for adding (,publishing) and removing your Freight items, doing limit checks and so on. So this is where you would implement addItem(Freight newItem).class Freight and subclasses: Are responsible for being the freight, thus having all attributes alike your UML above.There might be further adjustments, but that would need further information on your problem.
Je pense que vous devriez diviser votre classe de fret. Je ferai quelque chose comme ça:
public interface Freight
public class Luggage extends Freight
public class Cargo extends Freight
public class FreightCollection
{
private ArrayList<Freight> freights;
public FreightCollection(){
freights = new ArrayList<Freight>()
}
public void addFreight(Freight freight){
freights.add(freight);
}
}
Comme vous voulez que votre classe de fret conserve une collection de Pipefluggage et de PipefCargo, je pense que vous voulez qu'ils prolongent une classe autre que le fret. Alors P> Freight fr = new Freight();
PieceOfLuggage l1=new PieceOfLuggage(100,50,1234); //ident, weight, id
PieceOfCargo c1=new PieceOfCargo(300,123.56,1111,1); //ident, weight, id, degree of hazard
fr.addItem(l1);
fr.addItem(c1);
Votre conception confuse que "a beaucoup" type de relation avec le "est un" type de relation.
Un meilleur design est le suivant.
Lorsque vous y pensez, les morceaux de Lugagge peuvent également avoir un diplôme de danger, même quand il est zéro.
Freigth en tant que méthode additem () (non affichée dans le dessin) qui accepte un PipeOflugGge n'est pas un fret , SINCES A Fret est composé d'une ou de nombreuses morceaux de Lugagge.
fret a une collection de FreightItem , chaque frettem peut être un PipeflugGge ou un PipedCargo .
fretttitem et ajoute-le à la collection.
Cela n'a pas de sens. Comment un morceau de cargaison peut-il être composé de morceaux de cargaison? Vous embrouillez la conception propre originale. Si vous voulez quelque chose qui est une collection d'éléments de fret puis modéliser cela comme une classe distincte.
@Sebastianredl envisager une palette d'articles individuels. Pendant que je ne discute pas que l'idée de l'OP est une bonne, la cargaison peut être consolidée à plusieurs points dans le processus d'expédition.