Fördelen med OOP?

PHPportalen Forum Index » Diskutera webbutveckling
Lägg ett bokmärke på hela tråden
Skapa nytt inlägg   Svara på inlägget
Visa föregående ämne :: Visa nästa ämne  
Startad av: Meddelande
gelgz



Medlem i: 3517 dagar

Status: Offline



#675810
Inlägg Skrivet: 2010-03-18 04:37      Ämne: Fördelen med OOP? Citera

Hallå där!

Jag har suttit och funderat lite angående OOP programmering. Men har inte kommit fram till någon riktigt bra anledning att programmera OOP än vanligt.
Det enda jag kan se är att man får en bättre struktur på sin kod och att den ser "snyggare" ut.

I min mening så tar det längre tid att utveckla hemsidor osv om man enbart kör med OOP programmering.

Om man programmerar som vanligt så kan koden se ut som ren "kattskit", men det bryr sig ju inte användaren om. Bara dom får upp det dom vill ha på skärmen så är dom ju nöjda.

Så någon som kan komma med någon bra förklaring till att varför man ska köra OOP det istället?
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Azreal
Administratör



Medlem i: 5072 dagar
Från: Uppsala, bor i Göteborg
Status: Offline



#675813
Inlägg Skrivet: 2010-03-18 08:55      Ämne: Citera

Flyttas till Diskutera Webbutveckling.

Finns några diskussioner om ämnet här redan, bla denna.
http://www.phpportalen.net/viewtopic.php?t=79992
 

_________________
Konsultation via PM, inte gratis.
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
gelgz



Medlem i: 3517 dagar

Status: Offline



#675867
Inlägg Skrivet: 2010-03-18 16:06      Ämne: Citera

OT: Gjorde jag den inte i "Disskutera webbutveckling" ? Jag trodde då det iaf.

Det var lite intressant läsning, enda gången jag använt mig av OOP är om jag te.x. vill göra en modul jag senare vill inkludera i flera olika projekt utan att ändra i själva "main" koden om man säger så.

Jag gjorde förut en VCP.php class som hanterade ventrilo serverar på en linux dator.
Så det var egentligen bara en samling funktioner som jag anropade från min hemsida.

Men utöver det så förstår jag inte varför man ska använda OOP.
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Koila



Medlem i: 4492 dagar

Status: Offline



#675882
Inlägg Skrivet: 2010-03-18 16:42      Ämne: Citera

Varit inne i samma tankar som du verkar vara. Har letat på många forum och google. En stor anledningen verkar vara just översikten, gör det lättare att modifiera och ändra i koden. Men sitter man och gör allt själv, utan ambitioner på att underhålla kodstrukturen, utan snarare skriva om allt när det behövs, ja då finns det inga argument för.

Arbetar man med andra finns det dock stora fördelar, då andra kodare bara måste veta vilka funktioner som ska anropas och vilka resultat de ger, dvs inget om själva processen.
Kan vara att jag blandar ihop lite i argument för MVC-ramverk och generellt om OOP. Men sitter man själv och bortser från framtida modifikationer är det en smak-fråga.

Har även läst att OOP kan innebära högre serverbelastning, men så liten att den minskade tiden för utvecklaren att modifiera väger upp det... Har själv ingen erfarenhet av sånt dock.
 

_________________
Skadeglädje är den enda sanna glädjen
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
Walkman
Ex-Moderator



Medlem i: 4888 dagar
Från: Vaxholm (bor i Göteborg)
Status: Offline



#675893
Inlägg Skrivet: 2010-03-18 18:03      Ämne: Citera

Finns det någon anledning att inte hålla sin kod strukturerad och välskriven?

Det tog ett tag för mig att förstå vad tusan OO var bra för, speciellt i webbutvecklingssammanhang. Sätt er med ett av de etablerade ramverken så kanske det lossnar.

Rätt använd OOP maximerar återanvändning av kod (plug'n'play ftw) och ger en otroligt mycket bättre kodstruktur. Även om man arbetar själv så betyder det att utvecklingen går otroligt mycket snabbare — och arbetar man flera blir fördelarna ännu mer självklara, då det blir *mycket* enklare att dela upp koden i separata småjobb som ska göras.
 

_________________
Koda alltid som om nästa person som till slut ska läsa din kod är en våldsam psykopat och vet var du bor.

Förstå kod innan du använder den.
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
Saurid
Moderator



Medlem i: 5550 dagar
Från: Karlshamn
Status: Offline



#675917
Inlägg Skrivet: 2010-03-19 10:03      Ämne: Citera

gelgz skrev:
Jag gjorde förut en VCP.php class som hanterade ventrilo serverar på en linux dator. Så det var egentligen bara en samling funktioner som jag anropade från min hemsida.

I det läget har du inte så mycket mer nytta av OOP än med vanliga funktioner. Fördelarna börjar du märka ordentligt först när du kombinerar olika klasser och objekt med varandra. Men även innan dess så uppskattar jag sättet du kan "gruppera" variabler (egenskaper) och funktioner (metoder) i ett och samma objekt. Så även med enstaka objekt kan du lättare organisera funktionalitet och data på ett mer logiskt sätt än med bara funktioner.
 

_________________
waljefors.se :: waeke.se :: GitHub :: SoundCloud
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
gelgz



Medlem i: 3517 dagar

Status: Offline



#675922
Inlägg Skrivet: 2010-03-19 12:52      Ämne: Citera

Då verkar vi bara tillbaka till ruta ett, det går visst inte få något "praktiskt" exempel hur detta kan vara bra.
Verkar som man måste stöta på det hela själv, när det nu händer.
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Ajaxschampo



Medlem i: 4905 dagar
Från: Kalmar
Status: Offline



#675923
Inlägg Skrivet: 2010-03-19 12:57      Ämne: Citera

Det är just i större projekt som det är skönt med OOP och strukturerad kod. När man väl har 500 filer så är det skönt att ha en bra struktur på det hela så att man vet var man kan hitta allt.
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida MSN Messenger
Walkman
Ex-Moderator



Medlem i: 4888 dagar
Från: Vaxholm (bor i Göteborg)
Status: Offline



#675979
Inlägg Skrivet: 2010-03-19 20:48      Ämne: Citera

gelgz skrev:
Då verkar vi bara tillbaka till ruta ett, det går visst inte få något "praktiskt" exempel hur detta kan vara bra.

Som jag sa tidigare, ta en titt på något av Zend Framework, CodeIgniter, Kohana, CakePHP, Yii och så vidare. Där har du gott om praktiska exempel på bra användning av OO.

I många fall är proceduriell programmering helt okej. Att nyttja OOP bara för att använda OO är värdelöst, och du kommer inte få ut något av det — faktum är, att gör man detta så är det inte OO man håller på med. Däremot måste man hålla på med det för att lära sig hur det ska göras ordentligt, och det kommer ta tid. Folk brukar ha samma attityd till att lära sig CSS: “varför, det jag gör fungerar ju?”

Fördelarna med OO?
- Abstraktion av kod; att kunna gömma implementationsspecifika detaljer. Då kan användaren av koden (ofta en själv) använda den utan att förstå hur den fungerar inuti. En vanlig funktion är en abstraktion av en simpel process, och med OO kan man ta allting mycket längre när det börjar bli krångligare kod.
- Inkapsling; med god inkapsling kan vi ändra viktiga delar av våran kod utan de som använder sig av koden behöver bry sig. Någonsin behövt ändra på många ställen i din kod bara för att du ändrat någon liten detalj någon annan stans? Här har du din lösning.
- Modularisering; att kunna bryta ner ett stort problem i många delproblem, och använda flera moduler för att lösa ett stort problem. Skrivna ordentligt går de senare att använda i andra projekt (vilket sparar både tid och huvudvärk).
- Arv; möjlighet att återanvända kod och göra specialiseringar av den utan att behöva ändra i originalet.
Alla dessa tillsammans gör OO ett väldigt användbart sätt att programmera på, men det är allt det är: ett verktyg.

När allt kommer till kritan handlar det bara om att vara en bra programmerare — att skriva strukturerad och bra kod som uppmanar återanvändning och som inte är beroende av något annat än sig själv för att fungera.
 

_________________
Koda alltid som om nästa person som till slut ska läsa din kod är en våldsam psykopat och vet var du bor.

Förstå kod innan du använder den.
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
Saurid
Moderator



Medlem i: 5550 dagar
Från: Karlshamn
Status: Offline



#675983
Inlägg Skrivet: 2010-03-19 21:34      Ämne: Citera

Jag vet inte hur mycket du kan redan, eller om detta är ett riktigt bra "praktiskt" exempel. Men ett exempel är det iallafall. Tänk dig en webbshop. I dess allra enklaste form så ska den kunna hantera olika varor och dessa ska kunna läggas i en varukorg.

Här är en väldigt förenklad klass som hanterar olika varor. Du kan skapa varuobjekt med namn, pris och vikt på varan (som sedan kan användas för att räkna ut frakt tex). Koden är mer eller mindre självförklarande med minsta OO-kännedom:
PHP:
1:
 class Item
2:
{
3:
   private $name;
4:
   private $price;
5:
   private $weight;
6:
   
7:
   function __construct($name$price$weight)
8:
   {
9:
      $this->name $name;
10:
      $this->price $price;
11:
      $this->weight $weight;
12:
   }
13:
   
14:
   public function __get($key)
15:
   {
16:
      return $this->$key;
17:
   }
18:


Dessa varor behöver du kunna lagra i en varukorg. Du behöver en metod för att lägga till varor till korgen och en metod för att skriva ut varukorgen (eller egentligen returnera lite HTML-kod som du sedan kan skriva ut utanför objektet).

För att skriva ut varorna i metoden getCart(), så använder du dig av funktionalitet i Item-objekten men du gömmer själva implementationen av Item-objektet för varukorgen. Det enda du behöver veta här är hur du använder objektet.

PHP:
1:
 class ShoppingCart
2:
{
3:
   // Varor i varukorgen
4:
   private $items = array();
5:
   
6:
   // Lagra vald frakt-typ.
7:
   private $shipping;
8:
   
9:
   // Sätt en frakt-typ (ett Shipping objekt).
10:
   public function setShipping(Shipping $shipping)
11:
   {
12:
      $this->shipping $shipping;
13:
   }
14:
   
15:
   // Lägg en vara i varukorgen.
16:
   public function addItem(Item $item)
17:
   {
18:
      $this->items[] = $item;
19:
   }
20:
   
21:
   // Hämta HTML-kod för varukorgen.
22:
   // Skriv ut varorna varukorgen genom att
23:
   // loopa igenom alla varuobjekt i $items.
24:
   // Hämta pris på frakten genom att använda
25:
   // Shipping objektet.
26:
   public function getCart()
27:
   {
28:
      $output "<h4>Shopping cart</h4>";
29:
      foreach ($this->items as $item)
30:
      {
31:
         $output .= "<li>$item->name$item->price kr</li>";
32:
      }
33:
      $output .= "<h4>Shipping</h4>";
34:
      $output .= "<p>{$this->shipping->getShipping($this)}</p>";
35:
      return $output;
36:
   }
37:
 
38:
   // Räkna ut totalpriset för varukorgen.
39:
   // Summera respektive varas pris genom att
40:
   // loopa igenom alla varuobjekt i $items.
41:
   public function getTotalPrice()
42:
   {
43:
      $total 0;
44:
      foreach ($this->items as $item)
45:
      {
46:
         $total += $item->price;
47:
      }
48:
      return $total;
49:
   }
50:


Samma Item-objekt som visades ovan kan du så klart använda för att lista produkter utanför varukorgen också, innan de köpts.

Om du är uppmärksam ser du att det finns en metod setShipping, som tar ett Shippingobjekt som argument. Här tänker jag att man kan välja in olika frakt-sätt och därmed också olika sätt att räkna ut frakten på.

Vi börjar med att skapa ett interface som utgör en mall för hur frakt-objekten ska se ut och användas:

PHP:
1:
 interface Shipping
2:
{
3:
   public function getShipping(ShoppingCart $cart);
4:


Och så ett par olika frakt-sätt som implementerar interfacet ovan. För att vi ska kunna räkna ut frakten baserat på exempelvis priset, så måste Shipping objekten veta vad som ligger i varukorgen, därför skickar vi med varukorgen som argument när vi vill veta frakten.
PHP:
1:
 class FixedShipping implements Shipping
2:
{
3:
   public function getShipping(ShoppingCart $cart)
4:
   {
5:
      $shipping 100;
6:
      return "Frakt fast: $shipping kr";
7:
   }
8:
}
9:
 
10:
class PricedShipping implements Shipping
11:
{
12:
   public function getShipping(ShoppingCart $cart)
13:
   {
14:
      if ($cart->getTotalPrice() < 500) {
15:
         $shipping 50;
16:
      } else {
17:
         $shipping 150;
18:
      }
19:
      return "Frakt baserat på pris ({$cart->getTotalPrice()} kr): $shipping kr";
20:
   }
21:


Och så lite kod som anropar det hela:

PHP:
1:
 // Skapa en varukorg
2:
$cart = new ShoppingCart();
3:
 
4:
// Skapa Items-objekt och lägg dem i varukorgen
5:
$cart->addItem(new Item('Ipod'499100));
6:
$cart->addItem(new Item('Hörlurar'19910));
7:
 
8:
// Sätt metod för frakt (fast frakt)
9:
$cart->setShipping(new FixedShipping);
10:
 
11:
// Skriv ut varukorgen
12:
echo $cart->getCart(); 


För att ändra till ett annat fraktsätt så sätter du bara en annan Shippingmetod:
PHP:
1:
 // Frakt baserat på pris
2:
$cart->setShipping(new PricedShipping); 


Nu kan du lätt skapa nya klasser som handskas med frakten annorlunda. Tex en som räknar ut frakten baserat på vikten av varorna i varukorgen. Varukorgen behöver inte veta hur frakten räknas ut, eftersom det tas hand om av Shipping-objekten.

Sättet jag handskas med fraktuträkningar här är ett exempel på det design pattern, eller mönster, som kallas för Strategy Pattern. För att kunna förstå OOP's fulla potential är det just design patterns du ska läsa på om Smile

Jag vet inte om detta exemplet får det att klarna något, men för mig visar det lite fördelarna med den struktur man kan få med hjälp av OOP. Allt detta går så klart att göra med villkor, funktioner och vektorer också. Men tänk dig många fler och mycket mer avancerade lösningar än frakter i en varukorg. Tänk om du vill tillåta tredjepartsprogrammerare att skapa egna lösningar som ska användas av ditt system, då vill du kunna styra upp så mycket som möjligt!
 

_________________
waljefors.se :: waeke.se :: GitHub :: SoundCloud
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
Jalet



Medlem i: 5449 dagar
Från: Järfälla, Kallhäll
Status: Offline



#675984
Inlägg Skrivet: 2010-03-19 21:53      Ämne: Citera

Försök jobba med objekt utan att använda dig av OOP Wink Det är inte så lätt...

Skämt åt sido, om du på ett enkelt sätt vill kunna återanvända din kod, bygga ut din kod. jobba flera på samma projekt, om någon annan ska sätta sig in i din kod eller om någon annan ska fortsätta ditt jobb så är OOP tveklöst mycket bättre.
 

_________________
http://www.tv.nu | http://www.sport.nu
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Skicka e-post Besök användarens hemsida
gelgz



Medlem i: 3517 dagar

Status: Offline



#675994
Inlägg Skrivet: 2010-03-20 00:09      Ämne: Citera

Saurid, jag är i princip med vad du menar.
Men jag har en fundering i "ShoppingCart" klassen med metoden "addItem()".
Om jag nu addar en vara, och sen ska adda en till vara till exempel.

Då kommer ju instansen till klassen att försvinna och den kommer att skapa en ny, alltså efter varje "page refresh".

Detta har jag inte heller riktigt förstått mig på.. om jag vill lagra en massa data i en klass och kunna spara instansen och sen komma åt den på en annan sida. Vi kan kalla det en "pekare" som det heter i C++ (tror jag).
Som pekar på minnesadressen där detta objekt för denna klass finns.
Det är i princip så det fungerar i C++ om jag minns rätt.

Är du med?
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Saurid
Moderator



Medlem i: 5550 dagar
Från: Karlshamn
Status: Offline



#676028
Inlägg Skrivet: 2010-03-20 11:42      Ämne: Citera

gelgz skrev:
Om jag nu addar en vara, och sen ska adda en till vara till exempel. Då kommer ju instansen till klassen att försvinna och den kommer att skapa en ny, alltså efter varje "page refresh".

Ja, det är så PHP fungerar (PHP är "stateless"). Alla objekt måste på något vis återskapas vid varje sidladdning. OO eller strukturell programmering gör ingen skillnad.

Koden jag visade ovan är ju ganska förenklat. I just detta fallet med en varukorg så ligger förmodligen artiklarna i en databas, så du behöver funktionalitet som enkelt skapar ett Item-objekt från ett artikelid i din databas. Du kan då välja att lagra id'n och antal av varje vara i en sessionsvariabel som följer med användaren hela köpet, eller så kan du lagra infon i databasen.

Själva återskapandet av ShoppingCart-objektet gör du helt enkelt på samma sätt som jag visade i de två sista kodstyckena, fast du hämtar artikelid/antal från sessionsvariabler och resterande information från artikeldatabasen.

gelgz skrev:
Detta har jag inte heller riktigt förstått mig på.. om jag vill lagra en massa data i en klass och kunna spara instansen och sen komma åt den på en annan sida. Vi kan kalla det en "pekare" som det heter i C++ (tror jag).

Det går att lagra objekt i PHP mellan olika requests i sessionsvariabler eller i databas genom att använda serialize() och unserialize(). Man bör vara lite försiktig dock, då det kan röra sig om ganska mycket information som lagras i objektet. Man måste också försäkra sig om att class-definitionerna är laddade innan objektet återskapas med unserialize. Läs:
http://www.phpbuilder.com/manual/en/language.oop.serialization.php

Vanligen så återskapar man objekt mellan sidladdningar manuellt och lagrar bara så mycket information man behöver i sessionsvariabler.
 

_________________
waljefors.se :: waeke.se :: GitHub :: SoundCloud
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
Visa tidigare inlägg:   
Skapa nytt inlägg   Svara på inlägget
PHPportalen Forum Index » Diskutera webbutveckling
Hoppa till:  
Du kan inte skapa nya inlägg i det här forumet
Du kan inte svara på inlägg i det här forumet
Du kan inte ändra dina inlägg i det här forumet
Du kan inte ta bort dina inlägg i det här forumet
Du kan inte rösta i det här forumet
Du kan inte bifoga filer i detta forum
Du kan inte ladda ner filer från detta forum
Kontakta oss på adressen: info@phpportalen.net
Webbplatsen bygger i grunden på phpBB © 2001, 2002 phpBB Group

Modifieringar har senare gjorts i systemet av PHPportalen
Sid och logotypdesign skapad av Daren Jularic