[Kimppa]

Hej,

Lite kort:
Sitter väldigt ofta med många projekt som inte alls behöver vara något komplext. Mitt problem är nog att "allt ska vara perfekt" innan jag är nöjd med det och känner att detta är något jag skulle vilja publicera. Eftersom jag kommer utgå från PHP i mina exempel (då det är mest känt för mig, vilket också innebär att det kommer vara mer åt webbutvecklingshållet) så hoppas jag inte, att det på något sätt påverkar vad det är ja vill komma fram till.

Låt oss ta ett HTML dokument som ett exempel.

Det är uppbyggt ungefär så här: (doctype) html, head, body, html-slut

För de som jobbar eller jobbat med webbutveckling så programmerar man oftast inte hela projektet i samma fil, utan delar upp det i olika filer samt mappar. Jag har tidigare och använder mig fortfarande av "includes" för att lägga in html/head/title etc och avsluta mina dokument med en "end-include".

Nu har jag börjat funderat på att programmera i något typ av Objekt Orienterad Programmering PHP och kom fram till följande idag, och undrar om det är ett sätt som folk arbetar på, eller om det är så man ska arbeta (kanske man inte är så norsk, skämt åsido)?

PHP-koden (som kanske räknas som objektorienterad?):

<?php

class Elements {

public $id;
public $p;

public function newDiv($id) {
echo ("<div id=\"$id\">\n");
}
public function endDiv($id) {
echo ("</div><!--$id-->");
}

public function addParagraph($p) {
echo ("<p>$p</p>\n");
}

}

$html = new Elements;
$html->newDiv("namn");
$html->addParagraph("En paragraf.");
$html->endDiv("namn");

?>

HTML-koden:

<div id="namn">
<p>En paragraf.</p>
</div><!--namn-->

Resultatet:
En paragraf.

Kan detta vara ett bra tillvägagångssätt om man har flera projekt man arbetar med?
HTML element används ju dagligen på webbsidor, så att ha fördefinierade funktioner för det, är det bra?

Vill ni dela med av er hur ni försöker få era projekt så organiserade så som möjligt.. med fokus på programmering?

[linusoleander]

Din kod bör ha så lite sidoeffekter som möjligt. Du bör m.a.o inte printa ut något i din metod.

[CotopaXi]

Jag använder ramverk. Både på klientsidan (bootstrap) och serversidan (Django).

Att bygga ett eget ramverk, som jag tolkar det som att du gör, kan ha sina fördelar och nackdelar. Fördelarna är att du kan precis all kod i ditt ramverk. Nackdelen är att du får ingenting byggt åt dig och bedömt inte samma säkerhet eller kodkvalité som du hade fått om du hade valt ett större ramverk.

[lunarmys]

Om det är just html-output du vill pyssla med, så lyssna på CotopaXi: använd ett befintligt ramverk.

Är det något annat du är ute efter så får du nog förtydliga frågan lite

[tartareandesire]

Det kan vara trevligt att bygga ett eget ramverk också men OM man inte är 100% säker på att det endast kommer att användas av en själv så bör det dokumenteras noga allteftersom (det är tråkigt och bökigt att dokumentera kod i efterhand). Fördelen med att bygga eget är framför allt att man kan göra det mer effektivt och slipper allt onödigt som man inte använder. Det är också bra träning men kanske inte det första man ska ge sig på

En trevlig medelväg är att bygga ett "eget" ramverk utgående från komponenter i exempelvis Symfony där man enkelt man göra sig av med allt man inte vill använda:

http://fabien.potencier.org/article/...ponents-part-1

[Conny Westh]

Det går alldeles utmärkt att bygga sitt eget ramverk. Primärt gör man det för att långsiktigt effektivisera utvecklingsjobbet och höja kvaliteten på sin egen kod.

Det går givetvis att använda ett befintligt ramverk, men då lär man sig inte så mycket, dessutom måste man först lära sig ett antal olika ramverk för att testa vilket som passar bäst för ens behov.

Jag har alltid som utgångspunkt att bygga egna ramverk för min kod. Men jag kanske börjar med top-down-modell i stället för en bottom-up-modell.

Dvs jag tänker ut de funktionella komponenter jag vill använda och sen löser jag det tekniska efter hand som det behövs, med stegvis förfining, det har funkat för mig (men jag varierar mig så vissa tekniska komponenter bygger jag också bottom-up).

Skilj ut de komponenter som är till för att kapsla in HTML så de går att återanvända oavsett vilken typ av funktionell komponent du använder.

Det funktionella är ju oftast det som skiljer mellan de projekt man bygger.

Ska du bygga ett HTML-ramverk på ett bra sätt så bör du tänka på att Element är en generalisering av exemplevis DIV, BODY, HEAD mfl taggar. Det betyder att om man vill vara ortodox inom objektorientering så ska DIV vara en egen klass, PARAGRAF en egen klass m.m.

Man kan ju i BODY lägga många olika DIV och DIV kan vara nästade i varandra.

Skilj även på detaljklasser och listklasserna, det är inte samma sak, då det är helt olika egenskaper på listor och detalj/informationsklasser.

Det kan vara en hög tröskel att få till ett användbart ramverk, men när man väl har rätt struktur så blir det kollosalt enkelt att använda, bygga ut och modifiera, det är enligt min mening mycket av det som är poängen med objektorientring.

[pelmered]

Ursprungligen postat av ConnyWesth

Det går givetvis att använda ett befintligt ramverk, men då lär man sig inte så mycket, dessutom måste man först lära sig ett antal olika ramverk för att testa vilket som passar bäst för ens behov.

Där håller jag inte med.
Om man använder ett bra ramverk och verkligen sätter sig in i hur det fungerar(läser källkoden) lär man sig väldigt mycket, men framför allt lär man sig rätt. De flesta ramverk prioriterar best practices och hög kvalitet i koden så långt det är möjligt vilket gör att lär sig att skriva bra kod själv när man utökar och utvecklar i ramverket. Det finns inte, åtminstone inte enligt mig, något bättre sätt att lära sig än att kolla på bra kod och använda den om man vill lära sig rätt och skriva bra kod.

Givetvis lär man sig mycket att experimentera och bygga eget också, men risken är att man då lär sig fel och får dåliga vanor när man kodar. Börjar man med ett ramverk utan väldigt goda kunskaper om mjukvaruarkitektur så kommer man mes största sannolikhet också få skriva om hela ramverket eller kasta det när man blivit en duktigare utvecklare. Det är inget jag kan rekommendera oavsett vilken kunskapsnivå man ligger är på. Jag egentligen inte någon poäng med att skriva egna ramverk från grunden alls. Det är ett enormt jobb att hålla sitt egna ramverk modernt och up to date.

En väldigt intressant trend är det som tartareandesire skrev om ovan, dvs att man plockar komponenter ifrån olika ramverk och på så sätt syr ihop ett eget ramverk där man plockat de bästa modulerna för varje uppgift. I och med att Composer blivit en standard kan man numera på ett väldigt smidigt sätt hantera dessa beroenden och uppdatera komponenterna separat från sin egen "app"- eller "core"-kod. Man får då både extremt flexibel kod som man har väldigt mycket kontroll över samtidigt som den inte är så jobbig att underhålla. Modulerna uppdateras löpande av tredje part och har redan bra dokumentation vilket förenklar enormt mycket.

[Conny Westh]

Givetvis har man en stor fördel av att kika på annan kod, men du måste först hitta ett ramverk som heter duga och har bra kod från grunden. Det finns många ramverk som är halvmesyrer och som visar på många dåliga kodvanor som inte är objektorienterade alls.

Men i princip så håller jag med dig om att man ska titta på andras bra kod för att lära sig mer.

Men man behöver ändå skriva sitt eget ramverk för de applikationer man skriver. Jag har alltid en grund att jobba vidare med så jag skapar "wrappers" runt vissa externa klasser som jag vill kunna byta ut utan att skriva om hela min kod.

Men det är viktigt att skapa sin struktur så man bygger applikationerna i "komponenter" så man inte gör sig beroende av externa ramverk som man inte har kontroll på. Detta gäller mer för större applikationer. Gör man bara ganska små applikationer, där den egna koden är minimal i relation till den totala kodmassan, så kan man givetvis ha stor hjälp av att enbart använda tredjeparts-ramverk.

Men om du ligger i framkant i den tekniska utveckling av kodstandards kan man inte använda externa ramverk, de bygger ju på gammal känd teknik. Skriver man miljontals rader applikationskod så kan det hända att man har behov av nya sätt att tänka som inte tillverkarna av ramverken tänk på eller implementerat ännu. Då måste man ha egna ramverk. Därmed inte sagt att all kod måste vara egen, man kan mycket väl som Tartaren skriver blanda efter det som passar äst, dvs använda best practices. Men man jobbar med några viktiga principer:

- Objektorientring så långt det är möjligt
- Komponenttänkande
- Återanvändning i tanken redan från början (dvs använd gärna befintliga ramverk om det adderar värde)
- Wrappers kring klasser som kan tänkas behöva bytas i ett senare skede
- Skilj på tekniska ramverk och domänspecifika/verksamhetsspecifika ramverk
- Använd best practices
- Börja på en grov nivå och använd stegvis förfining
- Förbättra den egna koden kontinuerligt
- Var konsekvent
- Skapa ditt eget ramverk utifrån best practices (bygg gärna vidare på andras ramverk som du gillar)
- Utveckla din egen kompetens och jobba aktivt för at skapa nya sätt att tänka

Detta är generella principer som kan tillämpas på alla (av mig kända) objektorienterade programspråk (inkl PHP, Ruby, Python, C#, C++, mfl).

[Clarence]

Jag håller inte heller riktigt med. Det är väldigt sällan det finns anledning att skriva sitt eget ramverk. I väldigt specifika och annorlunda applikationer eller väldigt intensiva och förhållandevis enkla applikationer är det försvarbart. Men annars finner jag det alltid bättre att använda ett väl underhållet och strukturerat ramverk istället för att försöka göra jobbet som 10-tals personer gjort under en lång tidsperiod själv.

Dock är det ju viktigt att ramverket är flexibelt och har en bra struktur där du faktiskt kan byta ut delar mot dina egna komponenter. I vissa språk är sådana ramverk väldigt sällsynta och där går jag ifrån min syn på det. Men så fort du rör dig i populära OSS-språk som PHP så har du flertalet bra alternativ. Oavsett om du vill ha ett väldigt lätt ramverk eller ett väldigt komplett så har du bra ramverk som är lätta att utöka/förändra och har gjort 90% av grovjobbet åt dig.

T ex skulle du säkerligen om du valde ett bra ramverk komma in på tanken att skapa HTML direkt via objekt är en klumpig och komplicerande practice. Visst finns det edge cases där det kan vara smidigt - men i de allra flesta fall skapar det mycket ont till liten nytta.

Med det sagt är det ingen skada att skapa ett eget ramverk för att utöka sin egen kompetens. Men det är förhållandevis dödfött att bli ett bra ramverk de första åren om man inte haft erfarenhet av välskrivna ramverk och hur de underlättar ditt arbete.

[Kimppa]

Väldigt intressanta diskussioner!

Jag kodar i mestadels PHP.

Tycker ConnyWesth tänker ganska precis som jag tänker och var ungefär vad jag menade med denna tråd.

Jag har inte menat at skriva "superavancerade" ramverk utan enklare ramverk för att skriva ut början av t.ex. HTML-dokument (då jag inte applikationsutvecklar) och även slutet för HTML dokumentet.

För tillfället så använder jag mig av två PHP-funktioner för de flesta av mina projekt (enklare projekt) och de är:

1. Skriver ut allt från DOCTYPE till början på BODY.
(Brukar göra någon custom header som jag kan använda mig av i första fuktionen, oftast väldigt olikt designade)
2. Avslutar andra funktionen med </BODY> och eventuell "close" av databas.

Jag har länge tänkt på detta med klasser och PHP men aldrig riktigt förstått mig på det.

Om jag fårstår dig rätt Conny:
- Skulle det vara möjligt att skapa en klass som skapar html_start->html-end, för att sedan i PHP-dokumentet (med själva webbplatsstrukturen) kunna klistra in metoder/objekt/funktioner från denna klass?

Eller är de bättre att strukturera upp det som jag gjort tidigare?

EDIT: Jag använder mig av "ramverk" ungefär på samma sätt som templates/mallar i Word, när jag kodar CSS med speciella margins för headers, text, etc. (som går att återanvändas i olika projekt för bra artiklar etc.)