Was spricht gegen Java?

7 Kommentare

Also wenn ich Artikel wie „Was fehlt dir an PHP?“ (hier vom PHP Gangsta) lese und die Kommentare dazu, frag ich mich: Warum nicht gleich Java nehmen? Was spricht gegen Java?

PHP scheint ja wirklich immer mehr in Richtung Java zu tendieren, vielleicht haben wir bald auch einen Java Zwilling der dann den Vorteil hat, dass er bei fast allen Hostern standardmäßig läuft.
Aber „Hoster“ ist doch nicht so ein großes Argument gegen Java? Einen Root oder vServer (mit Root Rechten) gibt es doch schon ab 10-15 Euro und da lässt sich ja dann auch Java drauf installieren und ich wette, dass es bestimmt einen Java-Hoster gibt, der ein bisschen Platz umsonst anbietet.

Das Problem ist (und da bin ich lange nicht der erste der das sagt), dass PHP keine klare Richtung hat: soll es objektorientierter werden oder weiterhin die einfache Erlernbarkeit und Verwendung fördern?
Wenn OOP gewünscht ist, dann kann man gleich auf Java umsteigen. Wenn PHP weiterhin „Duck-Typing“ und sonstige „fehlertolerante“ Features bietet, dann sollte dieser Stil vielleicht etwas weiter ausgebaut werden (keine Ahnung wie).
Vielleicht ist aber auch gerade dieser OOP-Prozedur-Hybrid Stil das, was PHP so besonders macht?

Ja, auch mir fehlt meistens die feste Typisierung in PHP oder „finally“ beim try-catch und weitere „OOP“ Features. Aber wenn ich das benötige, programmiere ich eben in Java (außer ich bin wie in den meisten Fällen vom System zu PHP gezwungen ;) ).
PHP bevorzuge ich, gerade weil ich damit schnell was zusammen gehackt bekomme.

Aus welchem Grund verwendet ihr lieber PHP als Java?

Advertisements

Warum PHP?

5 Kommentare

Diese Frage habe ich mir letztens gestellt, nach dem ich einige Kritiken über PHP gelesen habe.
Zum Beispiel ist PHP keine echte Objektorientierte Programmiersprache und wird es auch nicht sein, die wahre Stärke von PHP ist das „Templating“ / erstellen von HTML usw.
Naja, an dem Tag war ich auf jeden Fall etwas deprimiert, weil ich PHP doch irgendwo gern gewonnen hab.

Trotz der Argumente dagegen, ist PHP immer noch eine der verbreitetsten Programmiersprachen. Nicht das damit diese Sprache automatisch „gut“ ist, aber das hat schon mal einen gewissen „Community“ Vorteil.

Das wichtigste Argument FÜR PHP ist meiner Meinung nach die grundlegende Einfachheit:
– man kapiert schnell, wie aus dem Code das Ergebnis wird
– man kann auch mit wenig Kenntnissen mal was zusammen stricken

Naja und Einfachheit hat schon immer seinen Reiz. Siehe zum Beispiel das KISS Prinzip: „Keep it simple, stupid“. Ein Prinzip auf das zum Beispiel auch Apple großen Wert legt und damit Erfolg hat.
Genau das ist es, was so eine Sprache verbreitet macht und den ein oder anderen User dann auch mal dazu anregt PHP und CCD unter einen Hut zu bringen.

Mein Fazit – auch wenn PHP nicht die leistungsfähigste, schönste und eleganteste Sprache ist – es macht meistens einfach Spaß damit zu programmieren.
Cheers.

Objekte in PHP down-casten

11 Kommentare

Heute bin ich auf ein fehlendes OOP Feature von PHP gestoßen: „Down-Casten“ funktioniert nicht.
Ich weiß nicht, ob down-casten der korrekte Begriff ist, aber so hab ich ihn in einem PHP Forum gefunden.
Es geht darum, ein Objekt einer abgeleiteten Klasse in ein Objekt der Übergeordneten (parent) Klasse zu casten. So ungefähr sollte das eigentlich aussehen:

class ReadRecord {
  protected $value;
  private function __construct(){}
  public function getValue(){
    return $this->value;
  }
}

class WriteRecord extends ReadRecord {
  public function __construct(){}
  public function setValue($v){
    $this->value = $v;
  }
}

$wr = new WriteRecord();
$wr->setValue("hello world");
$rr = (ReadRecord) $wr;

Geht aber nicht! Man bekommt einen parse error: „syntax error, unexpected T_VARIABLE“. Doof.
Also hab ich drüber nachgedacht, wie man das trotzdem hin bekommt und bin dank der seit PHP5 vorhanden Reflection API auf folgende Lösung gekommen:

class ReadRecord {
  protected $value;
  protected function __construct(){}
  public function getValue(){
    return $this->value;
  }
}

class WriteRecord extends ReadRecord {
  public function __construct(){}
  public function setValue($v){
    $this->value = $v;
  }
  public function toReadRecord(){
    $rr = new ReadRecord();
    
    $reflectedReadRecordClass = new ReflectionClass("ReadRecord");
    $props = $reflectedReadRecordClass->getProperties();
    foreach($props AS $prop){
       $propName = $prop->getName();
       $rr->$propName= $this->$propName; 
    }
    return $rr;
  }
}

$wr = new WriteRecord();
$wr->setValue("foo");
$rr = $wr->toReadRecord();
//$rr->setValue("bar"); //Fatal error: Call to undefined method ReadRecord::setValue() in ...
echo $rr->getValue(); //prints "foo"

Das ganze ist vielleicht etwas unperformant, aber es geht!
Theoretisch könnte man auch eine abstrakte Klasse schreiben welche die „downcast“ Methode über Reflection allgemein implementiert, aber das finde ich unschön. So wie im oberen Beispiel kann man kontrolliert down-casten.

nicht private Eigenschaften vermeiden

Hinterlasse einen Kommentar

Heute bin ich zusammen mit einem Kollegen mal unsere internen Checkstyle Regeln durchgegangen um die Sinnhaftigkeit jeder einzelnen gegebenenfalls zur Diskussion für alle Entwickler freizugeben. Dabei sind wir unter anderen auf folgende interessante Regel gestoßen:
Eigenschaft X soll private sein„.
Mit dieser Regel sollen alle protected und public Eigenschaften (=Felder, Properties, Klassenvariablen) vermieden werden. Meine Kollege meinte sogar, dass selbst auf private Eigenschaften am besten nur über getter und setter zugegriffen werden sollte – also aus der eigenen Klasse heraus. Ausgenommen sind nur Konstanten.

Die Vorteile dieser „Privatisierung“:

  • die Sichtbarkeit kann genauer eingestellt werden
  • fehlerhafte Werte können abgefangen werden (auf default/fallback Werte zurückgreifen)
  • es ist möglich, Objekte erst beim Aufruf zu instanzieren (Lazy Loading)
  • AOP kann eingesetzt werden (=> Sicherheit, Caching, Tracking/Logging)

Redaxo mag ich doch nicht

14 Kommentare

Ich hab mich vor einiger Zeit mal in einem Artikel für das CMS System Redaxo ausgesprochen, aber das bereue ich jetzt!

Ich behaupte einfach mal, dass es an meiner verstärkten Arbeit mit Java und damit an meiner (wenn auch noch mickrigen) Erfahrung liegt. Kann auch sein, dass ich einfach gemerkt hab, wie angenehm und „unumgänglich“ OOP ist.
Auf jeden Fall kotz ich grad mit Redaxo ab. Leider. An für sich kein schlechtes CMS, aber dadurch das so manches fehlt, kann man damit einfach nicht arbeiten weil man ständig auf irgendwelches hässliche Zeug stößt.

An der Stelle wird man vielleicht denken: „Hey, es handelt sich hier um ein Open Source Projekt .. da kann man doch mitarbeiten und die entdeckten Mängel beseitigen!“
Meine Antwort: „Wo soll ich anfangen?“ (ADD: klingt arrogant)
Alles in eine reine objektorientierte Architektur umwandeln?
Dokumentation schreiben?
Coding Standards einführen und 50% der Addons raus schmeißen?
Die Addon-, Modul- und Template-Download Seiten mit „Features“ wie „Sortierung“, „Tagging“ oder „Bewertungssystem“ erweitern?

Hmm .. ich hab nicht so viel Zeit (ADD: wieder arrogant).
Leider hab ich noch so gut wie keine Erfahrung mit CM Systemen da ich eher der „Entwickler unter der Oberfläche“ bin (oder sein möchte?!?) … :) Von daher meine Frage:
Was verwendet ihr, wenn eine neue (±simple) Website erstellt werden soll?

EDIT: wer denkt, dass ich ein eingebildeter Arsch bin, hat vielleicht recht oder übersehen, dass ich diesen Artikel in Rage geschrieben habe .. eigentlich könnte und würde ich ihn am besten löschen, doch ich lass ihn mal bestehen um, da die genannten Punkte wirklich etwas „nervig“ sind.

private Methoden vermeiden

4 Kommentare

Ich muss zugeben, ich hab schon lange nichts mehr geschrieben. Aber dieser Blog ist weder tot noch ist es einfach nur eine „Sommerpause“. Ich bin grad am überlegen, wie ich diesen Blog neu ausrichten kann, da ich meiner Meinung nach (noch) nicht in der Lage bin, regelmäßig qualitative Beiträge zu schreiben. Mehr dazu aber wenn es dann soweit ist.

Jetzt erst einmal der Grund für diesen Post: wozu brauch man private Methoden?!
Jede private Methode schränkt Entwickler ein, die entsprechende Klasse nicht effektiv anpassen zu können. Will man kleine Details verändern ist man entweder gezwungen, die Klasse umzuschreiben (ist bei PHP möglich, nicht aber bei Java zum Beispiel) oder von dieser Klasse zu erben und die aufrufende Methode zu kopieren und umzuschreiben. Beides ziemlich doof, weil das eine die Updatefähigkeit einschränkt und bei der anderen „Lösung“ jede Menge Code dupliziert wird.
Aktuell bin ich der Meinung, man verwendet in 98% der Fälle protected anstelle von private Methoden. Und je weniger ein Methode macht – also je mehr die Funktionalität einer Klasse auf verschiedene Methoden aufgetrennt ist, desto einfacher ist es Änderungen an der Klasse elegant und schnell durchzuführen.

Anmerkung: Dieser Post ist aus aktuellem Anlass entstanden. Ich habe mich in dieses Thema nicht hineingelesen oder damit ausführlicher beschäftigt – dieser Post ist also eher als eine Art Theorie zu betrachten.