Attribute eines Objekts einer Klasse durch statische Methode einer 2. Klasse ändern?

[berndoa]

Kurze dumme Frage:
Sagen wir, ich habe eine Klasse A, in deren Main Methode eben ein A Objekt erzeugt wird, typische nicht-statische Methoden und Attribute hat.
Wie man halt so ein Objekt benutzt.
Hat auch alle möglichen Attribute, (primitive Datentypen wie auch nicht-primitive)

Und dann eine Klasse B, die im Prinzip nur als Lagerraum für Methoden dienen soll und sprichwörtlich nur aus static Methoden besteht.

Kann ich nun hingehen und in A eine Methode aus B aufrufen und Attribute aus A als Argumente übergeben, sodass die Attribute von der B Klassenmethode geändert werden?


Weil ich habe ziemlich viele Methoden in A, die alles mögliche tun und dabei auch die Attribute verändern (sowohl bei ints den zahlenwert verändern als auch bei Arrays die Elemente überschreiben).
Die würde ich gerne "auslagern" in die B Klasse und der entsprechenden b methode halt die Verweise auf die Attibute soweit übergeben wie nötig.

Also wenn A bspw. die Attribute

int zahl=5;
int[] arb={1,2,3,4,5};

hat, das ich dann irgendwo in A eben

B.blabla(zahl,arb);

und diese blabla funktion aus B eben die 2 übergebenen Attribute des A Objekts anpasst.


Bei Referenzsachen wie String, Array und Co. würde ich auf Anhieb vermuten dass es geht, aber wie macht man das bei primitiven ints?
können die auch durch eine statische Mathode einer anderen Klasse verändert werden?



Edit: Oder, im 2. Gedankengang, müsste ich gar womöglich das Ganze Objekt (bzw. die Referenz darauf) an die Methode der anderen klasse übergeben?
Aber das wird ja vermutlich schwierig da ich bspw. in der Klasse A die Methode 1 habe, die die methode 2 aufruft. Und in der Methode 2 wird dann die methode B.blabla(Objektreferenz); aufgerufen.
Hat denn diese untermethode dann überhaupt zugriff auf das objekt um es der B Klassenmethode zu übergeben?

Oder würde man da ein ganz klassisches B.blabla(this); benutzen?

Ich steige da nicht ganz durch wie ich systematisch und easy die fertigen methoden aus A in andere Klassen auslagern kann ohne überall an Zugriffsproblemen zu scheitern bzw. fehlenden "Änderungsrechten" sozusagen :-/

 

[Jw456]

Bei Referenzsachen wie String, Array und Co. würde ich auf Anhieb vermuten dass es geht, aber wie macht man das bei primitiven ints?
können die auch durch eine statische Mathode einer anderen Klasse verändert werden?

nein du übergibst ja eine Kopie

wenn sie das tun soll braucht B die Instanz von der Klasse A um auf Elemente von A zuzugreifen wenn sie public sind.

 

[Neumi5694]

Es gilt: Wenn du einen Parameter übergibst, dessen Eigenschaften sich per
parameter.setValue(...) ändern lassen (klassisches Beispiel: Point. p.setLocation), dann ja: dann kannst du so etwas ändern, was in deiner Ursprungsklasse gespeichert wird - allerdings nur in Ausnahmefällen zu empfehlen, sauberer Code schaut anders aus (falls überhaupt, dann muss der Name der aufgerufenen Methode klarmachen, dass dies passieren wird).

Falls eine Variable aber nicht auf diese Weise änderbar ist, sondern nur per Zuweisung, dann geht es nicht, da du ja nur den Inhalt der Variable an die Funktion übergibst und nicht eine Referenz auf die Variable.

 

[berndoa]

Es gilt: Wenn du einen Parameter übergibst, dessen Eigenschaften sich per
parameter.setValue(...) ändern lassen (klassisches Beispiel: Point. p.setLocation), dann ja: dann kannst du so etwas ändern, was in deiner Ursprungsklasse gespeichert wird - allerdings nur in Ausnahmefällen zu empfehlen, sauberer Code schaut anders aus (falls überhaupt, dann muss der Name der aufgerufenen Methode klarmachen, dass dies passieren wird).

Falls eine Variable aber nicht auf diese Weise änderbar ist, sondern nur per Zuweisung, dann geht es nicht, da du ja nur den Inhalt der Variable an die Funktion übergibst und nicht eine Referenz auf die Variable.

Hm, und wenn ich ein ganzes Objekt (bzw. eine Referenz darauf) der Methode übergebe?
Dann müsste doh eigentlich die methode, wenn er als Argument bspw. das Objekt Haus bekommen hat, dann in der Methode deren Attribut Hausnummer mittels

Haus.hausnummer=55;

selbst wenn das Attribut eben vom Typ int, also einem primitiven Datentyp ist.
Oder?

Wobei, klar, anstatt direkt auf das Attribut zuzugreifen, könnte Haus auch eine Setter Methode haben, die eben aufgerufen wird.

Dass das vermutlich kein guter Stil ist, ist klar.
Aber so ist der Code wenigstens in ein paar Klassen ausgelagert.

Wo Alles in einer Klasse ist, ist die "Maintenance" echt schwierig, da muss man mit strg+f nach Allem suchen, anders findet man es in den hunderten Codezeilen nicht mehr :-/

Und natürlich Attribute und Co Alles shcön publik damit ich mich nicht noch zusätzlich mit Zugriffsreichweten und rechten rumschlagen muss .-)

 

[yfons123]

könnte Haus auch eine Setter Methode haben

"sollte"

Und natürlich Attribute und Co Alles shcön publik damit ich mich nicht noch zusätzlich mit Zugriffsreichweten und rechten rumschlagen muss .-)

naja, das mit dem du dich "rum schlagen musst" ist genau das was du nicht durch zugriffsrechte beschützt hast, das ist ja der witz an der ganzen sache

 

[berndoa]

"sollte"


naja, das mit dem du dich "rum schlagen musst" ist genau das was du nicht durch zugriffsrechte beschützt hast, das ist ja der witz an der ganzen sache

"naja, das mit dem du dich "rum schlagen musst" ist genau das was du nicht durch zugriffsrechte beschützt hast, das ist ja der witz an der ganzen sache"

Ich höre da jetzt schon den Compiler meckern, diese Methode kenne das programm nicht, dieses Attribut müsse static, public oder sonstwas sein.

Der produziert mir so schon genug Fehlern die man ausbügeln muss, da muss ich mir nicht noch zusätzlich reinholen indem ich mich mit packages, private, protected und Co. rumschlage.

 

[yfons123]

stell dir vor das hätten sich die entwickler der arrayliste auch gedacht

dann würde niemand mehr die arrayliste hernehmen, ABER ich bin grad am umschreiben ( eines beschissenen ) github codes

andem bis jetzt 100 zeilen weg gefallen sind an code einfach weil er es doppelt hatte, derjenige hat alles in ein ding gebacken
also gedulde dich! da kommt dann noch eine Standpauke über zugriff und clena code an dem beispiel erklärt

 

[berndoa]

stell dir vor das hätten sich die entwickler der arrayliste auch gedacht

dann würde niemand mehr die arrayliste hernehmen, ABER ich bin grad am umschreiben ( eines beschissenen ) github codes

andem bis jetzt 100 zeilen weg gefallen sind an code einfach weil er es doppelt hatte, derjenige hat alles in ein ding gebacken
also gedulde dich! da kommt dann noch eine Standpauke über zugriff und clena code an dem beispiel erklärt

Ich meine nur, mir und meine Hausgebrauchrprogramm bringt es wenig Vorteile wenn ich überall die zugriffsrechte so weit wie möglich einschränke dass es gerade noch funktioniert. Läuft ja auch so und solange kein perversling meinen Computer klaut, machen die public Klassen und Methoden nicht

Habe auch mal mein 700+ Zeilen Programm nun in mehrere Klassen (glaube 7 Stück) ausgelagert....
Mit Unmengen this Verweisen und ausschließlich statischen Methoden in allen Klassen ausser der Main Klasse! :O

Ich glaube, wenn ich das hier posten würde, würden manche CJWs vor Wut schnauben und tot umfallen vor Zorn

 

[yfons123]

this

brauchst du nicht?

 

[berndoa]

brauchst du nicht?

nicht? :O

Edit: Okay, hast recht, vermutlich könnte ich getter und setter Methoden benutzen.
Aber für so viele Variabeln je 2 Methoden schreiben...
Das müllt doch nur wieder die Klasse zu und ich checke am Ende gar nix mehr :-(

 

[yfons123]

nicht? :O

nein nur wenn du überdeckungen hast, ich habs so eingestellt dass es es als fehler auswerten sollte wenn this unnötig da steht

aber das liefert dir halt nur "nicht notepad artiges" *hust *hust*

du hast halt das oop1 trauma aber den ganzen mist was du da tust brauchst du nicht mehr wenn du mal tiefer gehst in die materie und ahnung von dem ganzen hast wann du was brauchst

 

[berndoa]

nein nur wenn du überdeckungen hast, ich habs so eingestellt dass es es als fehler auswerten sollte wenn this unnötig da steht

aber das liefert dir halt nur "nicht notepad artiges" *hust *hust*

Wobei noch so IDEartiges wie Ecklops oder so? *huste stärker*

Aber gut, es ginge wohl mit gettern und settern.
ich mag die aber nicht so :-(


Wobei, irgendwie habe ich so das Gefühl dass ich um eine herumgereichte Objektreferenz nicht drum herum komme, oder?

Selbst wenn ich in einer Klasse B eine set/get Methode eiens Objekts der Klasse A aufrufen will, bauche ich doch erst mal eine Referenz auf das A Element?

Mir will gerade nicht einleuchten wie ich das Ganze korrekt löse...

 

[yfons123]

eclipse ist halt "zum scheißen taugts" aber merh auch nicht

da ich im moment nur c# hantiere mit vs community und resharper von idea machts halt eig alles automatisch was ich so brauche
du musst halt ohne vernünftige IDE einstellungen den ganzen scheiß selber schreiben ... geht dir das nich auf den sack?

 

[berndoa]

Ich komme wohl um ein wenig Code nicht dum herum.
Hier mal an einem super simplen Beispiel mein Problem (das ich baute um zu testen ob mein this referenzieren und attribute ändern klappt):
Die "Hauptklasse A", deren Attribute durch andere Klassen und deren Methoden geändert werden sollen:

public class A{
    int a=0;
    String name="five";
   
    public static void main (String[] args){
        A help=new A();
       
    }
   
    public A(){
        metod();
       
       
    }
   
    public void metod(){
        System.out.println("a vorher: "+a+", name vorher: "+name);
        B.change(this);
        System.out.println("a nachher: "+a+", name nachher: "+name);
   
   
    }
   
   
   
}

Und hier die B Klasse, deren Methode aufgerufen wird und "aus der Ferne" die Attribute des A Objekts ändern soll (und wohl auch tut im Beispiel):

public class B{
   
    public static void change(A pedo){
        pedo.name="veraendert";
        pedo.a=666;
       
       
    }
  
   
   
   
}

Das ist wie erwähnt nur ein minimalbeispiel, mein 7 Klassenproblem hat da locker 20 solcher Zeilen wie

B.change(this);

Was ich generell sehen würde ist, dass ich von der B Klasse in der A Klasse ein Objekt erzeugen könnte und dadrüber die (dann nicht mehr statischen) Methoden aufrufen könnte.
Wie ich nun aber ohne das this auskommen kann, ist mir unklar.
Gerade wenn ich in der Methode der Klasse B dann ein Attribut von A ändern will.
Für den String könnte ich bspw. noch das Attribut selbst übergeben da String ein Referenzteil ist.
Dessen "Wert" lässt sich aus der Ferne ändern.

Aber wenn ich bspw. die Methode der Klasse B umschreiben würde zu

public static void change(String name, int a){
        name="veraendert";
        a=666;
       
       
    }

Und würde ihr beim Aufrufen in der A Kalsse halt die 2 Attrbiute übergeben, dann würde zwar erfolgreich der String geändert werden 8weil Referenztyp).
Der int aber nicht.
Da der primitiver Datentyp ist, würde der Methode nur eine Kopie des int werts übergeben, den könnte ich zwar ändern.
Aber das reale int Attribut des A Objekts bliebe unverändert weil nur an einer kopie rumgewerkelt wurde.

Wie umgeht man sowas?

 

[Jw456]

Die Methode in B muss nicht static sein.
Wenn du auch in a ein Objekt von ihr erstellst

 

[yfons123]

B.change(this);

warum ist das nicht eine methode von A ohne parameter?

 

[KonradN]

Ich sehe das Problem, dass Du bezüglich Objektorientierung ein ganz schlechtes Design hast. Wenn die Klasse B dazu da ist, die Klasse A zu ändern, dann riecht das erst einmal nach einer Gott Klasse. Was hat B denn die Klasse A zu ändern? Die Methode in B, die dazu da ist, a zu ändern, scheint also schlicht in A zu gehören.

Sowas mag es manchmal geben. Ein Beispiel für sowas sind Extension Methoden oder Utility Klassen. Im Java Framework wäre das z.B. bei Arrays. Aber Arrays sind halt eine Klasse, die da nicht erweiterbar war. Also gibt es diese Klasse Arrays, die irgendwas mit Arrays macht.

Ich meine nur, mir und meine Hausgebrauchrprogramm bringt es wenig Vorteile wenn ich überall die zugriffsrechte so weit wie möglich einschränke dass es gerade noch funktioniert.

Hier ist auch das Verständnis wichtig. Es geht hier nicht um Sicherheit! Die gibt es durch sowas nicht. Es geht rein darum, den Entwickler bei der dem strukturierten Aufbau zu unterstützen. Und dazu gehört nun einmal auch das Thema Kapselung.

Aber für so viele Variabeln je 2 Methoden schreiben...
Das müllt doch nur wieder die Klasse zu und ich checke am Ende gar nix mehr :-(

Also generell muss man viele Dinge nicht selbst schreiben. Das machen entweder die IDEs oder man nutzt etwas wie Lombok. Somit ist dieser Legacy Code zwar unschön, aber dafür gibt es genug Lösungen und Ideen.

Selbst wenn ich in einer Klasse B eine set/get Methode eiens Objekts der Klasse A aufrufen will, bauche ich doch erst mal eine Referenz auf das A Element?

Mir will gerade nicht einleuchten wie ich das Ganze korrekt löse...

Es ist halt wichtig, das man ein gutes OO Design hat. Dazu einfach vorstellen, dass die Klassen (Instanzen von diesen) sowas wie kleine Gnome sind. Die Klasse beschreibt halt das Verhalten eines Gnomes und auch, was diese kennen/sich merken. Aufrufe sind dann Nachrichten, die der Gnom bekommt. Das hilft evtl. etwas dabei, etwas sinnvoll zu unterteilen. Wenn ein Gnom irgendwas hat womit etwas gemacht werden muss: Dann würdest Du das doch nicht für den Gnom machen sondern sondern statt dessen dem Gnom sagen, dass er es mit seinen Sachen machen muss.

Wenn jemand etwas aus deiner Geldbörse haben will, dann nimmt er sich das ja nicht sondern sagt Dir: Gib mir das Geld!

Und dann kommen viele Situationen schlicht nicht! Du reichst keine Instanzen wild umher. Aber klar: Das, was sie brauchen, das kriegen sie. Ein Auto braucht einen Motor. Den muss das Auto also bekommen. Aber dann war es das auch schon. Jede Instanz sollte haben, was es halt zum arbeiten braucht.

Bei komplexen Applikationen braucht es ggf. viele Basis-Dinge. Da kommen dann durchaus Lösungen ins Spiel wie Dependency Injection. Aber unter dem Strich ist das auch nur, dass bei der Erstellung Dinge dem Konstruktor übergeben werden oder nach dem Konstruktor noch paar Setter aufgerufen werden. Und zur Vereinfachung muss man das nicht mehr selbst machen - das übernimmt dann ein Framework für einen.
Aber um sowas zu nutzen sollte man erst einmal verstanden haben, wie diverse Dinge funktionieren. Das generelle Grundverständnis ist wichtig.

Wenn Du da so Probleme hast, dann wären diverse Ansätze denkbar:
a) "Entwurfsmuster von Kopf bis Fuß" ist ein Buch, das diverse Möglichkeiten aufzeigt. Wenn man diverse Möglichkeiten kennt, dann erkennt man ggf. auch, wo man diverse Pattern anwenden kann. Ist aber auch problematisch, denn wenn Du den Hammer einmal kennst, neigst Du ggf. dazu, damit überall drauf zu hauen. Eine Schlagbohrmaschine soll darauf aber nicht gut reagieren ...
b) Ein Buch, das ich vor vielen Jahren gut fand, ist das Buch "Object Thinking" aus dem MS Press Verlag. Das zeigt aus meiner Sicht sehr schön auf, wie die Herangehensweise sein sollte. Ob es für Dich hilfreich ist, kann ich nicht sagen. Aber evtl. kommst Du da ja irgendwie ran.

 

[mihe7]

Ich glaube, wenn ich das hier posten würde, würden manche CJWs vor Wut schnauben und tot umfallen vor Zorn

Du bekämst gutgemeinte Ratschläge - ob Du die beherzigst oder nicht, ist Deine Sache und ob jemand sich durch Spaghetti-Code wühlen will, muss jeder, inkl. Antwortgeber, selbst wissen.

 

[yfons123]

Ich meine nur, mir und meine Hausgebrauchrprogramm bringt es wenig Vorteile wenn ich überall die zugriffsrechte so weit wie möglich einschränke dass es gerade noch funktioniert. Läuft ja auch so und solange kein perversling meinen Computer klaut, machen die public Klassen und Methoden nicht

Habe auch mal mein 700+ Zeilen Programm nun in mehrere Klassen (glaube 7 Stück) ausgelagert....
Mit Unmengen this Verweisen und ausschließlich statischen Methoden in allen Klassen ausser der Main Klasse! :O

Ich glaube, wenn ich das hier posten würde, würden manche CJWs vor Wut schnauben und tot umfallen vor Zorn

also ich kann dir ein code beispiel zeigen

mvp - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

command_terminal/CommandTerminal/Terminal.cs at master · stillwwater/command_terminal

Unity Command Terminal: In-Game Console. Contribute to stillwwater/command_terminal development by creating an account on GitHub.

github.com

die beiden codes tun fast das gleiche, was findest du lesbarer ? dass du den code nicht verstehst ist klar das ist c# speziell von unity, es geht um die übersicht und lesbarkeit
beides macht das ( fast ) gleiche

( das mit der "bösen" oop , hat sogar wesentlich weniger zeilen code weil nicht mehr alles doppelt und dreifach tun muss )

 

[berndoa]

Ich sehe das Problem, dass Du bezüglich Objektorientierung ein ganz schlechtes Design hast. Wenn die Klasse B dazu da ist, die Klasse A zu ändern, dann riecht das erst einmal nach einer Gott Klasse. Was hat B denn die Klasse A zu ändern? Die Methode in B, die dazu da ist, a zu ändern, scheint also schlicht in A zu gehören.

Sowas mag es manchmal geben. Ein Beispiel für sowas sind Extension Methoden oder Utility Klassen. Im Java Framework wäre das z.B. bei Arrays. Aber Arrays sind halt eine Klasse, die da nicht erweiterbar war. Also gibt es diese Klasse Arrays, die irgendwas mit Arrays macht.


Hier ist auch das Verständnis wichtig. Es geht hier nicht um Sicherheit! Die gibt es durch sowas nicht. Es geht rein darum, den Entwickler bei der dem strukturierten Aufbau zu unterstützen. Und dazu gehört nun einmal auch das Thema Kapselung.


Also generell muss man viele Dinge nicht selbst schreiben. Das machen entweder die IDEs oder man nutzt etwas wie Lombok. Somit ist dieser Legacy Code zwar unschön, aber dafür gibt es genug Lösungen und Ideen.


Es ist halt wichtig, das man ein gutes OO Design hat. Dazu einfach vorstellen, dass die Klassen (Instanzen von diesen) sowas wie kleine Gnome sind. Die Klasse beschreibt halt das Verhalten eines Gnomes und auch, was diese kennen/sich merken. Aufrufe sind dann Nachrichten, die der Gnom bekommt. Das hilft evtl. etwas dabei, etwas sinnvoll zu unterteilen. Wenn ein Gnom irgendwas hat womit etwas gemacht werden muss: Dann würdest Du das doch nicht für den Gnom machen sondern sondern statt dessen dem Gnom sagen, dass er es mit seinen Sachen machen muss.

Wenn jemand etwas aus deiner Geldbörse haben will, dann nimmt er sich das ja nicht sondern sagt Dir: Gib mir das Geld!

Und dann kommen viele Situationen schlicht nicht! Du reichst keine Instanzen wild umher. Aber klar: Das, was sie brauchen, das kriegen sie. Ein Auto braucht einen Motor. Den muss das Auto also bekommen. Aber dann war es das auch schon. Jede Instanz sollte haben, was es halt zum arbeiten braucht.

Bei komplexen Applikationen braucht es ggf. viele Basis-Dinge. Da kommen dann durchaus Lösungen ins Spiel wie Dependency Injection. Aber unter dem Strich ist das auch nur, dass bei der Erstellung Dinge dem Konstruktor übergeben werden oder nach dem Konstruktor noch paar Setter aufgerufen werden. Und zur Vereinfachung muss man das nicht mehr selbst machen - das übernimmt dann ein Framework für einen.
Aber um sowas zu nutzen sollte man erst einmal verstanden haben, wie diverse Dinge funktionieren. Das generelle Grundverständnis ist wichtig.

Wenn Du da so Probleme hast, dann wären diverse Ansätze denkbar:
a) "Entwurfsmuster von Kopf bis Fuß" ist ein Buch, das diverse Möglichkeiten aufzeigt. Wenn man diverse Möglichkeiten kennt, dann erkennt man ggf. auch, wo man diverse Pattern anwenden kann. Ist aber auch problematisch, denn wenn Du den Hammer einmal kennst, neigst Du ggf. dazu, damit überall drauf zu hauen. Eine Schlagbohrmaschine soll darauf aber nicht gut reagieren ...
b) Ein Buch, das ich vor vielen Jahren gut fand, ist das Buch "Object Thinking" aus dem MS Press Verlag. Das zeigt aus meiner Sicht sehr schön auf, wie die Herangehensweise sein sollte. Ob es für Dich hilfreich ist, kann ich nicht sagen. Aber evtl. kommst Du da ja irgendwie ran.

Gelesen hab ichs wohl, allein mir fehlt der Glaube.

Klar gehören die Methoden idealerweise zu A.
Da hatte ich dann aber irgendwie 20+ Methoden in A und über 700 Zeilen Code.
Um was zu finden, musste ich das mit strg+f suchen (lassen), da viel zu viele Methoden in einer Klasse.

Also irgendwann verliert mand a den Überblick weil man auffassungsmässig nicht mehr das komplette Programm im Hinterkopf behalten kann

Ist doch sch... OOP Design, wenn man Alles in eine Methode packt, oder?
Also hab ichs, halbwegs thematisch geordnet, in verschiedene Klassen ausgelagert.
Da aber halt immer noch Attribute des A Objekts geändert werden müssen, müssen da die anderen Klassen und deren Methoden rankommen.

Die primitivste Variante, die mir einfiel um das umzusetzen, war eben das Übergeben des kompletten Objekts mittels this

 

[yfons123]

wenn du es postest für ein refactoring wirst du sicher antworten bekommen

 

[KonradN]

Da hatte ich dann aber irgendwie 20+ Methoden in A und über 700 Zeilen Code.

Dann ist diese Klasse evtl. sinnvoll zu unterteilen. Würde mich sehr wundern, wenn das nicht gehen würde. Und das sind im Schnitt über 30 Zeilen Code pro Methode - das sieht auch nicht gut aus.

Also hab ichs, halbwegs thematisch geordnet, in verschiedene Klassen ausgelagert.

Ja, aber das hast Du ganz offensichtlich nicht mit einem Objektorientierten Ansatz gemacht sondern Du hast nur Prozedural unterteilt und irgendwas ausgelagert. Und damit hast Du dann die ganzen Probleme bekommen, die Du dann hier in Thread beklagst und die Du mit einem vernünftigen Design eben nicht hättest.

Ist doch sch... OOP Design

Es ist eben kein (gutes, vernünftiges) OO Design, das Du da hast. Das ist eben Dein großes Problem. Und da hilft es Dir nicht, irgendwelche Workarounds zu suchen sondern Du musst lernen, wie man etwas sinnvoll unterteilt. Ggf. könnten dabei sogar Inhalte aus Vorlesungen helfen, dessen Namen Du sogar schon vergessen / verdrängt hast - von den Inhalten mal ganz zu schweigen

 

[Neumi5694]

Hm, und wenn ich ein ganzes Objekt (bzw. eine Referenz darauf) der Methode übergebe?

Klappt natürlich, im Beispiel mit Point wird ja auch ein ganzes Objekt übergeben (halbe Objekte sind nicht möglich).
Aber wie gesagt: Sofern die Methode nicht gezielt darauf ausgerichtet ist, ein Objekt zu manipulieren, ist das eine nicht empfehlenswerte Vorgehensweise.

/**
 * "Ganzes" Objekt wird übergeben und geändert.
 */
public static void moveThisPointby(Point p, int dx, int dy) {
    p.setLocation(p.x + dx, p.y + dy);
}

Aber so ist der Code wenigstens in ein paar Klassen ausgelagert.

Im Gegensatz zu manch anderem hier kann ich das durchaus nachvollziehen, ich hab auch erst auf die harte Tour lernen müssen, dass es oft besser ist, wenn die Objekte nicht alle Methoden selbst mitbringen. Daten und Logik gehören streng getrennt, Daten werden grundsätzlich immer von außen manipuliert und oft auch ausgewertet. Java selbst arbeitet da auch nicht anders. Z.B. Shapes erstellen auch nicht selbst eine verschobene, gespiegelte oder gedrehte Kopie von sich, dafür gibt's die Affinetransformation, das Shape wird von außen ausgelesen, es wird ein neues Shape mit den geänderten Koordinaten erstellt.

Wann das Ganze sinnvoll ist und wann nicht, wirst du noch herausfinden.
Ob es in diesem Fall passt ... keine Ahnung, dazu müsste man den Code sehen.

 

[KonradN]

Daten und Logik gehören streng getrennt, Daten werden grundsätzlich immer von außen manipuliert und oft auch ausgewertet. Java selbst arbeitet da auch nicht anders. Z.B. Shapes erstellen auch nicht selbst eine verschobene, gespiegelte oder gedrehte Kopie von sich, dafür gibt's die Affinetransformation, das Shape wird von außen ausgelesen, es wird ein neues Shape mit den geänderten Koordinaten erstellt.

Also die Aussage ist so viel zu pauschal. Was Du vielleicht meinst ist eine Trennung Daten von Businesslogik. Da wäre ich dann bei Dir.
Und in den typischen Business-Anwendungen läuft es dann genau auf sowas hinaus. Einfachste Entities ohne ein wirkliches Verhalten. Bei dem Verhalten in einer typischen Business-Applikation geht es um die Prozesse und nicht um die Daten, die irgend ein Verhalten haben. Das ist aber ein Speziallfall. Dass man Daten ohne Verhalten hat, hat man sonst eigentlich nicht:

Aber bei der Softwareentwicklung gibt es ja deutlich mehr. Und da ist es eben wichtig, dass es eine Kapselung gibt. Und dann gehören viele Dinge direkt in die Klasse. Beispiel BigDecimal - da ist das eigentliche Verhalten in der Klasse enthalten. Bei so einer Klasse wirst Du hoffentlich nicht fordern, die Daten (die intern irgendwie gespeichert werden) von außen zu verändern oder so.

Und Verhalten muss nicht zwingend in der Klasse liegen. Es gibt viele Möglichkeiten, eine Klasse "aufzuteilen". Das einfachste ist, wenn Daten weiter gekapselt werden können. Ein Auto hat dann halt weitere Instanzen wie Motor, Getriebe, ....
Aber auch bei reinem Verhalten kann man sehr viel machen: Spezifisches Verhalten kann eine eigene Klassenhirarchie bilden. Da müsste jedem doch direkt das Strategy Muster einfallen.

Das Beispiel mit dem AffineTransform - das ist doch auch relativ einfach objektorientiert zu sehen und hat keine Trennung von Daten und Logik. Das Transform ja kein Verhalten von einem Shape sondern etwas, das "nur" etwas mit einem Shape macht. Das dies eine eigenständige Klasse ist, wird schnell klar:
- die Klasse hat ein eigene Datenbasis, auf der sie basiert
- die Klasse hat sowas wie ein eigenes Verhalten. Ich denke da nur an dies getRotateInstance und so. Diese Methoden gehören ja wohl kaum zu Shape. Oder ist ein Shape zuständig, AffineTransformation Instanzen zu erzeugen? Und wenn es in Shape wäre und es die Klasse AffineTransformation nicht gäbe: Was würde da erstellt? Oder zu was müsste man es da umschreiben?
Im Rahmen einer Objektorientierten Entwicklung ist das Ergebnis somit klar und auch im Java Framework gut zu erkennen.

Aber macht und seht es, wie ihr wollt. Meine Sichtweise habe ich dargestellt. und mehr will ich nicht.

 

[mihe7]

Was Du vielleicht meinst ist eine Trennung Daten von Businesslogik. Da wäre ich dann bei Dir.

Daten und Logik gehören streng getrennt

?!?

 

[Neumi5694]

Also die Aussage ist so viel zu pauschal. Was Du vielleicht meinst ist eine Trennung Daten von Businesslogik. Da wäre ich dann bei Dir.
Und in den typischen Business-Anwendungen läuft es dann genau auf sowas hinaus. Einfachste Entities ohne ein wirkliches Verhalten. Bei dem Verhalten in einer typischen Business-Applikation geht es um die Prozesse und nicht um die Daten, die irgend ein Verhalten haben. Das ist aber ein Speziallfall. Dass man Daten ohne Verhalten hat, hat man sonst eigentlich nicht:

Aber bei der Softwareentwicklung gibt es ja deutlich mehr. Und da ist es eben wichtig, dass es eine Kapselung gibt. Und dann gehören viele Dinge direkt in die Klasse. Beispiel BigDecimal - da ist das eigentliche Verhalten in der Klasse enthalten. Bei so einer Klasse wirst Du hoffentlich nicht fordern, die Daten (die intern irgendwie gespeichert werden) von außen zu verändern oder so.

Und Verhalten muss nicht zwingend in der Klasse liegen. Es gibt viele Möglichkeiten, eine Klasse "aufzuteilen". Das einfachste ist, wenn Daten weiter gekapselt werden können. Ein Auto hat dann halt weitere Instanzen wie Motor, Getriebe, ....
Aber auch bei reinem Verhalten kann man sehr viel machen: Spezifisches Verhalten kann eine eigene Klassenhirarchie bilden. Da müsste jedem doch direkt das Strategy Muster einfallen.

Das Beispiel mit dem AffineTransform - das ist doch auch relativ einfach objektorientiert zu sehen und hat keine Trennung von Daten und Logik. Das Transform ja kein Verhalten von einem Shape sondern etwas, das "nur" etwas mit einem Shape macht. Das dies eine eigenständige Klasse ist, wird schnell klar:
- die Klasse hat ein eigene Datenbasis, auf der sie basiert
- die Klasse hat sowas wie ein eigenes Verhalten. Ich denke da nur an dies getRotateInstance und so. Diese Methoden gehören ja wohl kaum zu Shape. Oder ist ein Shape zuständig, AffineTransformation Instanzen zu erzeugen? Und wenn es in Shape wäre und es die Klasse AffineTransformation nicht gäbe: Was würde da erstellt? Oder zu was müsste man es da umschreiben?
Im Rahmen einer Objektorientierten Entwicklung ist das Ergebnis somit klar und auch im Java Framework gut zu erkennen.

Aber macht und seht es, wie ihr wollt. Meine Sichtweise habe ich dargestellt. und mehr will ich nicht.

Na dann nehmen wir dein Beispiel mit der Geldbörse.
Der Benutzer hat reingefasst und ihren Inhalt verändert.

Hier ist noch ein Beispiel für gegenseitige Beeinflussung.

class Person {

  void getAHairCutFrom(Barber barber) {
    walkTo(barber);
    //Preisüberprüfung ...
    barber.cutHairOf(this); //man übergibt sich selbst, lässt sich extern ändern.
    pay(amount, barber):
  }
}

class Barber extends Person {
    void cutHait(Person person) {
        person.getHair().setLength(0.004);
    }
}

Alles streng objektorientiert und doch ändert der eine den anderen. Beim Bezahlan kann man noch darüber diskutieren.

 

[berndoa]

hallo,
habe jetzt mal ein eigenes Thema aufgemacht zu meinem eigentlichen Programm und so:

https://www.java-forum.org/thema/wie-kann-ich-mein-8-klassen-gebilde-objektorientierter-schreiben.197538/

Wäre coll wenn mir hier die "Profis" sagem könnten, wie man es nun richtig macht.
Denn ausser "falsch, falsch. falsch" bei jedem Umschreiben des Programms habe ich irgendwie bisher noch nichts mitbekommen, keine Ahnung wie es denn nun richtig auszusehen hätte :-/

 

[KonradN]

Also wenn der "Barber" den internen Zustand "Haare" der Person ändert, dann hast Du ein super Beispiel gemacht, wie man es nicht machen sollte. Das Thema Kapselung werde ich aber nicht weiter vertiefen. Du darfst es so machen!

Und natürlich kann eine Instanz eine andere Instanz beeinflussen. Aber doch bitte nur über das Verhalten dieser Klasse! Person kann von mir aus eine Methode getHair haben und Hair hat dann eine Methode cut und damit kann dann Barber eben eine Instanz, die das HasHair Interface implementiert, durchaus beeinflussen.

 

[Neumi5694]

Also wenn der "Barber" den internen Zustand "Haare" der Person ändert, dann hast Du ein super Beispiel gemacht, wie man es nicht machen sollte. Das Thema Kapselung werde ich aber nicht weiter vertiefen. Du darfst es so machen!

Und natürlich kann eine Instanz eine andere Instanz beeinflussen. Aber doch bitte nur über das Verhalten dieser Klasse! Person kann von mir aus eine Methode getHair haben und Hair hat dann eine Methode cut und damit kann dann Barber eben eine Instanz, die das HasHair Interface implementiert, durchaus beeinflussen.

Ich hab kein Barber-Programm geschrieben, aber es gibt keinen plausiblen Grund, warum man das nicht machen sollte.
Die Haare können sich nicht selbst schneiden, vor allem kennen sie keine verschiedenen Frisuren (wenn wir mal einen Schritt weiter gehen). Die Technik zum Erstellen von Frisuren kennt nur der Friseur und der verändert die Haare. Haare haben diesbezüglich keine Ausbildung gemacht.
Die Methoden zum Anwenden verschiedener Frisuren haben in der Klasse Haare nichts verloren. Die Haare werden entsprechend diesen Methoden von außen geändert (man weise ihnen z.B. ein Shape zu). Die Haare sind die Datenklasse und haben als Information, wie sie ausschauen (Farbverlauf, Länge, Shape). Der Friseur kennt die Möglichkeiten, wie man sie ändert. Die Person weist sich selbst dem Friseur zu, damit dieser Änderungen vornimmt. Klar - eine "strenge" Trennung ist das auch nicht. Wie ich gesagt hab - man muss von Fall zu Fall unterscheiden, was sinnvoll ist und was nicht.
Wir können uns jetzt noch 200 Beispiele und Gegenbeispiele and den Kopf werfen und werden doch zu dem Schluss kommen, dass es keine absolut und unabrückbar gültige beste Art gibt, die Probleme zu lösen. Du darfst die deinene natürlich auch so lösen, wie DU es für richtig hältst!

Das Tolle an all den Pattern, Antipattern, Richtlinien, Paradigment und was der Geier was ist, dass sie nicht in Stein gemeißelt sind. Wären sie das, dann hätten wir heute immer noch die selben wie 1978. Sie wurden immer wieder an die technischen Möglichkeiten und Bedürfnisse angepasst.

 

[KonradN]

?!?

Ja, die Differenzierung mit Logik <-> Business Logik ist nicht wirklich gut. Aber hier geht es es ja um zwei DInge:

Das eine ist ein Objektorientierter Entwurf. Und da kommt Kapselung und Co ins Spiel.
Das andere ist eine n-Layer Architektur. Da hat man also eine Architektursicht.

Und was ich mit der ungeschickten Aussage halt etwas ausdrücken wollte ist etwas, dass die Businesslogik eben nicht eine reines Verhalten (Logik passt hier nicht) der Entities ist, sondern lediglich ein Ausdruck von Busniess-Regeln ist, die separat zu sehen sind. Da geht es ja nicht darum, was eine Rechnung macht, sondern was eben der Betrieb mit der Rechnung machen will ...

Kann ich vielleicht nicht richtig ausdrücken, aber ich hoffe, dass es etwas deutlich geworden ist. Du kannst aber auch einfach mal Deine Sicht schreiben.

 

[KonradN]

Ich will Dich nicht überzeugen - ich habe meine Sichtweise geschrieben und damit ist die Sache erst einmal erledigt. Nur um einen kleinen Teil Deiner Aussage zu nehmen:

Die Haare können sich nicht selbst schneiden,

Du hast also ganz offensichtlich Haare - was also irgend eine Instanz mit irgend einer Klasse dahinter ist. Und diese Instanzen haben ein Verhalten: sie können geschnitten werden.

Somit hast Du eine Instanz Haare von der Du das Verhalten schneiden aufrufen kannst. Das kann dann gerne ein Object "Barber" machen, der sich die Haare von einer "Person" hat geben lassen. (Das wäre dann übrigens auch der Aufruf - da würde man vermutlich einfach this.haare statt nur this übergeben.)

Aber das nur als kleine Ergänzung gedacht um aufzuzeigen, wie man bei so einfachen Beschreibungen direkt ein Objektmodell erkennen kann.

 

[mihe7]

Ich denke, dass Ihr im Grunde das gleiche meint, das Uncle Bob als Data/Object Anti-Symmetry beschrieben hat, die Unterscheidung als solches schon nicht einfach ist und es sehr schwer wird, aus dem Kontext gerissene Beispiele als "Beleg" anzuführen.

 

[Neumi5694]

Du hast also ganz offensichtlich Haare - was also irgend eine Instanz mit irgend einer Klasse dahinter ist. Und diese Instanzen haben ein Verhalten: sie können geschnitten werden.

Steht auch in meinem Post. Mal mit setLength(), mal mit dem Zuweisen der Frisur/Shape. Nur wissen sie nichts über das 'wie'. Das ist die Logik, die von außen die Haare verändert.

Alles gut, ich weiß schon, dass wir da verschiedene Sichtweisen haben