# Konstruktor mit vielen parametern



## OnDemand (25. Okt 2014)

Hallo zusammen, 

ich muss für mein Programm ein Objekt erstellen mit vielen Parametern. Hinzu kommt dass ich den Konstruktor mehrfach überladen müsste sa es von diesem Objekt mehrere Typen gibt. Insgesamt wären das dann 5 konstrukotoren mit 10, 13, 14, 19 Parametern zb. 

Das ist sicherlich nicht schöner Code. Daher meine Frage. Sollte ich lieber eine Oberklasse erstellen mit den Eigenschaften die alle haben und dann beerben  und spezialisieren oder einfach je Objektart eine eigene unabhängige Klasse? 

Edit...Meine Oberklasse hätte dann aber auch schon 8 Eigenschaften welche als Parameter rein müssten.

Vielleicht doch lieber eine Bean und die Eigenschaften mit settern setzen?

Danke euch für Tipps


----------



## Ruzmanz (25. Okt 2014)

Dazu gibts viele Möglichkeiten, nach Anwendungsfall bietet sich auch ein Build-Pattern an. Ansonsten ist ein "Parameter Object" prinzipell OK.

- Too Many Parameters in Java Methods, Part 2: Parameters Object | JavaWorld
- Too Many Parameters in Java Methods, Part 3: Builder Pattern | JavaWorld

Auf javaworld gibt es noch ein paar andere Lösungswege, wobei die beiden mMn am häufigsten anzutreffen sind.


----------



## OnDemand (28. Okt 2014)

Ok die Buildpatterns scheinen mir etwas to much zu sein. Noch jemand eine Idee, ansonsten geb ich meiner Oberklasse eben die 8 Parameter mit


----------



## Joose (28. Okt 2014)

NicoDeluxe hat gesagt.:


> Ok die Buildpatterns scheinen mir etwas to much zu sein.



Du meinst es ist dir zu hoch, dann probiere doch mal konkret nachzufragen bei Sachen die unverständlich sind.
Was genau an dem Pattern ist dir nicht klar?



NicoDeluxe hat gesagt.:


> Noch jemand eine Idee, ansonsten geb ich meiner Oberklasse eben die 8 Parameter mit



Ruzmanz hat dir 2 Optionen genannt. Die 2.Option (Build-Pattern) meinst du, ist dir zu hoch.
Dann schau dir die 1.Option (1.Link) an und verwende Parameter Objekte


----------



## OnDemand (28. Okt 2014)

Ich kann meine Parameter nicht in sinnvolle Klassen auslagern.
Zb. Artikelnummer, Farbe, Größe, Name, Beschreibung, Metatitle, Keywords etc


----------



## Joose (28. Okt 2014)

Meine Frage steht noch: Was genau am BuildPattern ist unklar/zu hoch?

Ist es dir möglich uns zu sagen wie die Klasse heißt und welche Attribute sie hat?
(inkl einer kleiner Beschreibung was die Klasse darstellt usw.)


----------



## OnDemand (28. Okt 2014)

Das BuildPattern scheint mir einfach zu viel zu sein für meine kleine Anwendung, das muss auch einfacher gehen.

Diese Klasse soll einen Artikel repräsentieren, mit den Attributen Farbe, Größe, etc. etc.

Nun gibt es aber verschiedene Artikel im Sortiment, zb Fahrräder und Klamotten (Bsphaft) ein Fahrradartikel würde dann mit einem Konstruktor und den passenden Parametern erstellt werden, eine Hose mit einem Konstruktor mit Klamotten-Parametern.

Daher denke ich ist es am sinnvollsten eine Oberklasse zu erstellen mit den Parametern die jeder Artikel hat (Nr., Farbe, Name, Beschreibung, Keywords, ..) und dann zu vererben oder? In einem Jahr weiß ich sonst nicht mehr was ich da programmiert habe.


----------



## Joose (28. Okt 2014)

Wie hast du dir denn Klassenstruktur vorgestellt anhand deine Beispiels?
Ich sehe hier das Problem das es in sehr sehr vielen Unterklassen ausarten wird, je nachdem wie breit gefächert das Angebot ist.


----------



## OnDemand (28. Okt 2014)

Es dürften nicht mehr als 5 Unterklassen (verschiedenen Artikelarten) sein noch feiner aufsplitten  würde dann keinen Sinn machen.


----------



## Moro (9. Nov 2014)

NicoDeluxe hat gesagt.:


> Sollte ich lieber eine Oberklasse erstellen mit den Eigenschaften die alle haben und dann beerben



Im Mittelpunkt der Klassenhierarchie steht nicht die Frage, wie man am meisten erben kann, sondern welche Klasse welche Verantwortlichkeiten besitzt und welche dieser Klassen sinnvolle Generalisierungen und Spezalisierungen voneinander darstellen.

Eine sinnvolle Klassenhierarchie macht bei Artikeln schon Sinn. Wie aber schon gesagt wurde: Du solltest sinnvolle Klassen bilden, so dass es nicht ausartet. Es macht in jedem Fall mehr Sinn als ein Artikel Objekt mit jeglichen Eventualitäten auszustatten. Versuch das möglichst grob Durchzugeneralisieren. 5 Unterklassen wie du sagst hört sich schon gut an. Und wenn denn immer noch "zu viele Parameter" da sind, dann ist das eben so. Die spätere Wartbarkeit und das handling sind wichtiger als schöne Parameter.


----------



## OnDemand (9. Nov 2014)

Danke für deine Antwort. Also werde ich je Artikelart ne extra Klasse erstellen ☺ danie dir


----------

