PHP OOP & Prozedural Wann ist OOP unnötig?

  • Ersteller Ersteller omaliesschen
  • Erstellt am Erstellt am
O

omaliesschen

Gast
Hi,

da ich derzeit mein Projekt umschreib stoß ich immer wieder auf Teile bei denen ich denke OOP ist unnötig.

Wann ist OOP fehl am Platz?
 
Dort wo es keinen Mehrwert bzw. keine Vereinfachungen bringt...

Grundsätzlich seh ich aber keinen Grund, keine Klassen zu verwenden...
 
Man sollte nur konsistent bleiben, entweder ganz oder gar nicht. Wobei eine Mischung bei PHP nicht zu vermeiden ist, da der Sprachumfang bis auf vereinzelte Dinge wie mysqli und PDO nun mal an Funktionen orientiert ist. Und diese Funktionen erst in eigene Klassen zu kapseln, um richtig objekt-orientiert arbeiten zu können, kann eigentlich nicht Sinn der Sache sein.
 
Du hast ihn falsch verstanden. Gerade Datenbanken sind eben objektorientiert (PDO und mysqli). Andere Sachen sind in PHP eben hingegen stur prozedural, z.B. String-Operationen. Während du in einer Sprache, die voll auf OO setzt, sagen würdest: $testresult=$mystring->compare($myotherstring); gehst du in PHP eben über strcmp($s1,$s2);

Kurz und knapp: PHP lebt von der Mischung. Das mag nicht jedem so schmecken, aber nun ja. Man sollte weitestgehend konsistent bleiben, dann passt das schon.
 
Klar, ich vermute mal, die meisten Frameworks für PHP sind objektorientiert. Ändert aber nichts daran, dass am Funktionsumfang von PHP selbst quasi nichts objektorientiert ist. Wenn man nie mit richtigen OO-Sprachen gearbeitet hat, mag das nicht weiter auffallen, ansonsten wirkt es einfach nur künstlich aufgesetzt (erfüllt seinen Zweck aber trotzdem irgendwie).

@Daaron so war's gemeint :)
 
ich les hier nur "PHP [blablabla] unnötig" und muss dem einfach zustimmen.

Zum Thema - ich würds so schreiben wie du es besser kannst - bist du C Programmierer? Dann schreibs prozedural, bist du Java Programmierer dann machs so gut OOP wie es geht.
But du reiner PHP programmierer - mein beileid.
 
bluebarcode, was du hier schreibst ist gelinde gesagt Schwachsinn. Oma will den Code schließlich mittelfristig veröffentlichen, außerdem ist das Projekt doch recht komplex. Bei so etwas NICHT objektorientiert zu arbeiten wäre vollkommen für den Eimer, egal ob man nun aus der C-Schiene kommt oder nicht.
Auch C-Entwickler sehnen sich nach Objektorientierung, sonst gäbe es wohl kein Objective-C. Und auch mit Structs kann man OO-Verhalten in gewissem Rahmen nachempfinden.
 
Hi,

ich nenn als Beispiel mal PHPBB. Ein riesiges MischMasch nach meinem Empfinden. Sowas gibts bei mir nicht. Ich verfolg derzeit folgendes Schema:

Die Index Datei ist mehr oder weniger prozedural und kümmert sich um includes und die Ausgabe des Endprodukts. Ausschnitt:

Code:
use PDO;
use Redis;

ob_start();
session_start(); 
#phpinfo();

$_SESSION['token'] = true;

define("DOCROOT", $_SERVER['DOCUMENT_ROOT']); 
define("INCPATH", '/var/inc/');
define("NOREMOTE", true);

// don't echo this without html_entities
isset($_SESSION['UID'])&&define("USERNAME",$_SESSION['Logged']);

require_once INCPATH.'autoloader/autoloader.php.inc';
require_once INCPATH.'functions.php.inc';
require_once INCPATH.'dbconnect.php.inc'; 
require_once INCPATH.'redisconnect.php.inc'; 

date_default_timezone_set('UTC');

$authtype  = new initialauth;
$v         = new visitors( $authtype->user_id );
$pageload  = new pagesettings;

Die Klasse Pagesettings händelt den Request und definiert die zu ladende Logik, das Template und kümmert sich darüber hinaus um alle Grundeinstellungen und Header,Footer etc. Am Ende wird das Resultat dann über verschiedene
Code:
$pageload->createBreadcrump
ausgegeben.

Die Logikdateien verfolgen folgendes Schema:

Code:
if ( ! defined('NOREMOTE') ) { exit; }

$prc_memlist = new membersearch();
$pt          = new paginator( $prc_memlist->getNumberOfPages(), $prc_memlist->getCurrentSite(), PARAM, $prc_memlist->getQuerystring() ); 

$pageload->setRoom( 'Membersearch' );
$pageload->setTitle( 'Membersearch' );
$pageload->setCrumpyTrails( array( 'Members' => 'index.php?search=members', 'Search' => false ) );

Und der Autoloader sucht die entsprechenden Klassen.

Das Konzept ist also im Grunde folgendes:

minimal prozedural->OOP->minimalProzedural->OOP->Ausgabe

Mein Frage ist ob es besser wäre z.B. auf der indexseite alles in class main{} zu setzen und die inkludierten Logikmanager an main zu heften?

But du reiner PHP programmierer - mein beileid.

Die Diskussion ist genauso alt wie sie überflüssig ist. Sei mal kreativ und bring was neues. Du kannst es nicht, Du plauderst nur nach was Du irgendwo mal aufgeschnappt hast? Dafür gibts dann MEIN Beileid.
 
Zuletzt bearbeitet:
Du hast da n Schreibfehler: Breadcrumb schreibt sich mit "b"... das führt sicher irgendwann zu Verwirrungen, wenn du es nicht korrigierst.

Ansonsten ist dein Ansatz durchaus sinnig. Ich halts nicht für zweckdienlich, in der index.php eine main-Klasse zu erzeugen und dann am Ende nur $bla = new main(); $bla->parse(); zu sagen. Kann man machen, muss man aber echt nicht. Bietet keinen Mehrwert.

Übrigens, wenn du phpBB schlimm findest (ich habs nicht weiter angeguckt), dann guck mal auf Wordpress... kaltes Grausen.
 
Breadcrumb schreibt sich mit "b"... das führt

Ich wollte nur ein klein wenig Humor reinbringen und nenne es bei mir CrumpyTrail in Anlehnung an gängigen CollegeHumor. Das HTML und Mikromarkup verzichtet allerdings auf den Humor und ist Googlekonform.

Ich halts nicht für zweckdienlich, in der index.php eine main-Klasse zu erzeugen und dann am Ende nur $bla = new main(); $bla->parse();
Seh ich ähnlich nur wollte ich es so nah wie möglich an Sprachen ausrichten bei denen das Konzept nicht funktionieren würde und denke darüber nach zumindest eine Funktion main einzubauen.

Code:
function main(){ ... };
main();

Sehe, außer der konzeptionellen Annäherung an andere Sprachen, allerdings keinen weiteren Sinn darin.

Übrigens, wenn du phpBB schlimm findest (ich habs nicht weiter angeguckt)
Bei mir ist es umgekehrt. mal kurz in Wordpress reingesehen und tiefer in PHPBB. Schaus dir an und lobe danach den Autodidakten.^-^ Minderwertigkeitsgefühle sind nach Sichtung des PHPBB codes wie weggeblasen. Die Datenbank dagegen ist gut. Lässt sich was lernen bzgl. Indexierung. Wobei die DB an vielen Stellen überladen wirkt.
 
Zuletzt bearbeitet:
Schlecht kann die Datenbank von phpBB ja auch kaum sein, sonst würde es bei großen Foren gnadenlos zusammen brechen.
 
Mein Forum läd mit üppiger TestDB, wenn man css und Javascript bei beiden abzieht dreimal schneller als das fast leere installierte phpbb. Denke das ist akzeptabel. Leider ist die CSS File recht umfangreich. Gibt es einen Weg Browsern mitzuteilen dass sie Javascript und CSS, sofern es sich um nix neues handelt ( main.css?version=x ), nicht erneut downloaden sollen?

Dateispezfisches expire?
 
Zuletzt bearbeitet:
Hi,

Wenn im Netzwerkmonitor der Entwicklertools ein "304 not modified" steht bedeutet dass das die Dateien nicht erneut geladen wurden?
 
Jein, der Client hat beim Server angefragt ob sich die Datei geändert hat und der hat gesagt es gibt keine Änderung: wird nicht wieder geladen.
Der Client muss trotzdem jede Ressource anfragen: langsam

Google mal nach dem Expires-Header, genau das suchst du.
 
Jep, dein Apache braucht mod_expires, und es muss natürlich auch aktiv sein. "sudo a2enmod expires"

Für deine .htaccess gibts dann noch in etwa sowas hier:
Code:
##
# Expires headers (for better cache control)
# @see https://github.com/h5bp/html5-boilerplate
##
<IfModule mod_expires.c>
  ExpiresActive on
  ExpiresByType text/cache-manifest           "access plus 0 seconds"
  ExpiresByType text/html                     "access plus 0 seconds"
  # Data
  ExpiresByType text/xml                      "access plus 0 seconds"
  ExpiresByType application/xml               "access plus 0 seconds"
  ExpiresByType application/json              "access plus 0 seconds"
  # Feed
  ExpiresByType application/rss+xml           "access plus 1 hour"
  ExpiresByType application/atom+xml          "access plus 1 hour"
  # Media: images, video, audio
  ExpiresByType image/gif                     "access plus 1 month"
  ExpiresByType image/png                     "access plus 1 month"
  ExpiresByType image/jpg                     "access plus 1 month"
  ExpiresByType image/jpeg                    "access plus 1 month"
  ExpiresByType image/x-icon                  "access plus 1 month"
  ExpiresByType video/ogg                     "access plus 1 month"
  ExpiresByType audio/ogg                     "access plus 1 month"
  ExpiresByType video/mp4                     "access plus 1 month"
  ExpiresByType video/webm                    "access plus 1 month"
  # HTC files  (css3pie)
  ExpiresByType text/x-component              "access plus 1 month"
  # Webfonts
  ExpiresByType application/x-font-ttf        "access plus 1 month"
  ExpiresByType font/opentype                 "access plus 1 month"
  ExpiresByType application/x-font-woff       "access plus 1 month"
  ExpiresByType image/svg+xml                 "access plus 1 month"
  ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
  # CSS and JavaScript
  ExpiresByType text/css                      "access plus 1 year"
  ExpiresByType application/javascript        "access plus 1 year"
</IfModule>

Edit: Und denk an mod_deflate oder sonstige Kompressions-Tricks. Das bringt enorm viel.

Außerdem:
- wenn deine Seite HTTPS nutzt, dann versuch deinem Server SPDY beizubringen. Dann kannst du all die miesen kleinen Icon-PNGs, die man so hat, in einem Abwasch transferieren. Geht nicht mit HTTP 1.1, wird erst Teil von HTTP 2.0
- wenn du kein SPDY nutzen kannst: arbeite großflächig mit CSS Sprites oder binde kleine Grafiken als base64-Strings direkt in die .css ein. Und kombiniere alle .css - Dateien zu einer großen, genau wie alle .js. Danach sollte JS noch durch n Kompressor wie YUI.
 
Zuletzt bearbeitet:
Danke für die Mühe, aber es läuft über Lighttpd. Mod_compress aktiviert und zlib.output_compression in php.

Cache control, expire etc. im Header kenn ich natürlich nur kann lässt sich das nicht in die index Datei setzen.
 
Zuletzt bearbeitet:
Na ja, kann lighttpd keine Expires-Settings irgendwo hin pflanzen? Klar, dass es mit ner .htaccess wohl nix anfangen kann, aber muss doch was analoges geben.
Ich für meinen Teil bleib bei Apache2. Da weiß ich, woran ich bin. Wir müssen größere Mengen kleiner und mittlerer Seiten bereitstellen, da ist Apache einfach mit das beste Werkzeug. Wenn, dann würd ich auf Cherokee migrieren...
 
Zurück
Oben