Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

61

01.04.2015, 09:35

Eben. Static richtig verwendet hat rein gar nichts mit Faulheit zu tun, sondern damit, dass die relevante Methode eben keinerlei Instanz-Bezug besitzt. Wieso sollte sie dann also nicht static sein? Mein Beispiel zeigt das sehr deutlich und ist sauber und hat weder was mit schlechter Lösung, noch mit Faulheit zu tun.
Dabei will ich sicher nicht abstreiten, dass es falsche Verwendung von static gibt. Es generell als Faulheit oder Unfähigkeit des Programmierers zu bezeichnen ist aber eben falsch.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

62

01.04.2015, 10:58

Eben. Static richtig verwendet hat rein gar nichts mit Faulheit zu tun, sondern damit, dass die relevante Methode eben keinerlei Instanz-Bezug besitzt. Wieso sollte sie dann also nicht static sein? Mein Beispiel zeigt das sehr deutlich und ist sauber und hat weder was mit schlechter Lösung, noch mit Faulheit zu tun.
Dabei will ich sicher nicht abstreiten, dass es falsche Verwendung von static gibt. Es generell als Faulheit oder Unfähigkeit des Programmierers zu bezeichnen ist aber eben falsch.

Ich würde sogar so weit gehen, dass generelle Aussagen über bestimmte Konstrukte ("static Member/Methoden meiden", "Singletons gar nicht verwenden", "Unbedingt <Design Pattern> verwenden", ...) vermieden werden sollten. Letztendlich bildet man mit seinem Software Design bestimmte Problemstellungen ab, wofür man die gegebenen Mittel und Möglichkeiten so nutzen sollte, dass die Problemstellung bestmöglich abgebildet wird.
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

Fireball

Alter Hase

Beiträge: 415

Wohnort: Werne

Beruf: Dipl. Inf.

  • Private Nachricht senden

63

01.04.2015, 11:01

Bei static gibt es immer Probleme mit dem Unit Test, diese Variablen bekommt man nicht richtig weg gemockt.

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

64

01.04.2015, 11:22

Ich hatte im Projekt konkret das Beispiel dass Daten (von Datum) hin und her geparsed wurden, mit Hilfe einer Utility Klasse. Die Daten kamen natürlich aus einer Datenbank und lagen dann meistens als Strings in den Objekten. Dazu auch nicht einheitlich, also z.B. als Timestamp, Datum String, Date Objekt, mit Uhrzeit, ohne Uhrzeit usw.
Da stellt sich mir dann die Frage warum nicht jedes Datum einheitlich gespeichert wird, z.B. als Timestamp und beim auslesen dann immer in ein Date Objekt umgewandelt wird, so dass alle Methoden zum objekt gehören:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
class Datum{
    private long timestamp;
    public String toString(){}
}

// statt:

class DatumUtil{
    public static Date parseDate(String ganzVieleFormate);
    public static String toString(Date datum){}
}


Mal stark vereinfach geschrieben. Die Utility Klasse hat 40-50 statische Methoden für diesen Kram. Darauf bezog sich zumindest mein Beispiel für falschen Einsatz von static.
Das sind aber grundlegende Designfehler im ganzen Projekt, überhaupt dass so viel mit String gearbeitet wird...

static hat natürlich seine Berechtigung, das sehe ich so wie die Poster vor mir.

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

65

01.04.2015, 11:52

Das wahre Problem ist doch, dass Java keine freien statischen Methoden unterstützt.
Die Namen "DatumUtil" und "FileUtil" sind doch grober Unfug.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

66

01.04.2015, 14:00

Das ist wohl darin begründet, dass es rein OOP ist und keine imperativen Möglichkeiten bietet. In C++ würde ich wohl immer einen Namespace und freie Methoden empfehlen und sicherlich keine Klasse. Das heißt aber dennoch nicht, dass die Verwendung von static in Java in jedem Fall schlecht ist. Verschiedene Sprachen haben verschiedene Herangehensweisen.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

67

01.04.2015, 19:00

Ist bei euch gerade das mentale Rechtschreibmodul ausgefallen? ;) edit: Wow, was für ein klasse Aprilscherz!!! :thumbsup:

@Fireball: Dafür könnte man sowas wie PowerMock benutzen :) Am besten sollte man aber tatsächlich statische Methoden nur benutzen, wenn die Operationen zustandslos und in sich geschlossen sind (also auch keine externen Daten abfragen). Math ist ein gutes Beispiel, viel mehr als mathematische Algorithmen fällt mir allerdings nicht ein, jedenfalls wenn die Methoden im Gegensatz zu BlueCobolds Beispiel direkt aufgerufen werden. Dann hat man nämlich schnell den Fall, das man bei einem Komponenten-Test eben nicht auf die externen Daten sondern auf speziell vorbereitete Daten zugreifen möchte. Wie Du schon sagst ist das bei statischen Methoden ein Problem. Für solche Fälle ist Dependency Injection ein Segen. Da bekommt man schließlich die Util-Klassen ohne große Probleme als Member injected.

Fireball

Alter Hase

Beiträge: 415

Wohnort: Werne

Beruf: Dipl. Inf.

  • Private Nachricht senden

68

01.04.2015, 23:54

@Chromanoid sicher ist das möglich, doch wenn sich bereits für Mockito entschieden wurde, dann hat man ein neues Framework an der Backe.

Naja wie dem auch sei, ich hatte es letztens mit einer Anwendung zu tun, die es heute zum Glück nicht mehr gibt, dank eines kompletten Redesign meinerseits, da hatten die Entwickler alle DB Zugriffe über eine Statische Klasse gelöst. Diese Klasse wurde so gut wie überall instantiiert. Alles schimpfte auf die schlechte Testabdeckung, aber einfach mal einen Unit Test bauen ging nicht, denn eine Datenbank wurde immer benötigt.

Ätzend, naja ist nun Geschichte.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

69

02.04.2015, 09:32

Das ist wohl richtig.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

fkrauthan

Supermoderator

Beiträge: 979

Wohnort: Vancouver

Beruf: Software engineer

  • Private Nachricht senden

70

02.04.2015, 18:05

Im grunde gibt es gerade in der Java Welt kaum gruende was statisch anzubieten. Ausnahmen sind sowas wie Simple calculationen. Z.b. die Java Math library. Alles andere sollte nie per Static geloest werden. Im Zeitalter von DI frameworks braucht es das auch garnicht da eine gute DI den Code auch deutlich einfacher und besser testbar macht.
Homepage: fkrauthan.de | Browser-game: flowergame.net

Werbeanzeige