Acties:
  • 0 Henk 'm!

Anoniem: 391751

Topicstarter
Op dit moment volg ik een HBO studie informatica (wil uitstroomrichting systeembeheer doen). Tijdens deze studie krijgen we vakken zoals: html/css, php, Java en C#.
Met html/css heb ik weinig moeite (misschien omdat dit geen programmeertaal is) maar met Java en C# wel.
Op alle vakken haal ik ook netjes voldoendes maar die programmeer vakken...misschien wil het niet lukken om dat het objectgeoriënteerd is.

Mijn medestudenten zeggen 'het kwartje moet even vallen' maar dat verdomde kwartje valt maar niet.
Wat is een goed begin om deze manier van denken onder de knie te krijgen?
Met het internet erbij kan ik best wel iets programmeren maar het moet ook zonder kunnen.

-edit-
Wist niet zeker waar ik dit topic moest plaatsen

[ Voor 4% gewijzigd door Anoniem: 391751 op 15-11-2013 17:00 ]


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 20:25

.oisyn

Moderator Devschuur®

Demotivational Speaker

Hier heb ik onlangs een leuke blog over gelezen, kijken of ik 'm nog terug kan vinden...

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Anoniem: 391751

Topicstarter
.oisyn schreef op vrijdag 15 november 2013 @ 17:04:
Hier heb ik onlangs een leuke blog over gelezen, kijken of ik 'm nog terug kan vinden...
Dat zou mooi zijn.

Acties:
  • 0 Henk 'm!

  • 418O2
  • Registratie: November 2001
  • Laatst online: 16:27
Het kan ook gewoon zijn dat je niet heel abstract kan denken. Ik heb ook redelijk wat backenddevelopment gedaan, maar ik ben niet abstract genoeg daarvoor. Kan leuk meekomen, maar haak toch wel af op een gegeven moment.

Ben nu Frontenddeveloper en Interactie ontwerper. Mijn backendervaring helpt daar wel erg bij.

hoewel je het principe van OO development wel moet kunnen begrijpen aan de hand van de simpele voorbeelden (Object voertuig, eigenschap aantal wielen, Object auto, gebasseerd op voertuig etc etc)

[ Voor 23% gewijzigd door 418O2 op 15-11-2013 17:19 ]


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 20:25

.oisyn

Moderator Devschuur®

Demotivational Speaker

418O2 schreef op vrijdag 15 november 2013 @ 17:16:
Het kan ook gewoon zijn dat je niet heel abstract kan denken.
Dat was ook een beetje het idee achter het artikel dat ik las, maar ik kan 'm nergens meer vinden :X. Het ging iig om iemand met een wiskunde-achtergrond die een informaticaopleiding had gedaan, en altijd heel goed was in de "puzzels" die men vroeg bij job interviews maar vervolgens op de werkvloer dan toch enorme moeite had om simpele dingen gewoon in code om te zetten.

God zeg het is echt maar een paar weken geleden oid dat ik 'm las, waarom kan ik 'm nou niet meer vinden.

.edit: ah hier: DEAR STARTUPS: STOP ASKING ME MATH PUZZLES TO FIGURE OUT IF I CAN CODE
.edit2: bij nader inzien misschien niet geheel op jou van toepassing.

[ Voor 26% gewijzigd door .oisyn op 15-11-2013 17:37 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • Paul
  • Registratie: September 2000
  • Laatst online: 16:01
Het is inderdaad een kwartje dat moet vallen, maar ik moet wel zeggen dat men het op de opleiding vaak moeilijker wil maken dan het is. Dan krijg je de opdracht een console-applicatie te maken die twee getallen aan de user vraagt, deze bij elkaar optelt en het resultaat op het scherm zet. En dan krijg je een onvoldoende als je huiswerk niet tenminste drie klassen bevat...

Als je dan een opdracht krijgt waarbij het wel voor de hand ligt om de boel wat abstracter te trekken dan valt dat kwartje eerder dan wanneer je iets dat in 3 regels kunt naar 3 klassen om moet klussen.

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Acties:
  • 0 Henk 'm!

  • Ikke_Niels
  • Registratie: Augustus 2001
  • Laatst online: 28-05 14:18
Sudoku boekjes kopen ;)

User Error -- Please Replace User


Acties:
  • 0 Henk 'm!

  • Sissors
  • Registratie: Mei 2005
  • Niet online
418O2 schreef op vrijdag 15 november 2013 @ 17:16:
hoewel je het principe van OO development wel moet kunnen begrijpen aan de hand van de simpele voorbeelden (Object voertuig, eigenschap aantal wielen, Object auto, gebasseerd op voertuig etc etc)
Moet zeggen dat dat voor mij nooit echt goed heeft gewerkt. Bij andere dingen ben ik prima in abstract denken, maar voor mij was dat een geforceerde manier waardoor ik misschien theoretisch wel begreep wat het idee van OO is, maar praktisch er niet veel mee kon.

Algemeen zou ik zeggen bij denken als een programmeur dat het voor een groot gedeelte logisch nadenken is en verbanden leggen, maar specifiek problemen met OO is denk ik meer dat je het gewoon praktisch moet gebruiken. IIG dat werkte bij mij.

Acties:
  • 0 Henk 'm!

Anoniem: 391751

Topicstarter
Ben toch wel blij dat mensen mijn ervaring delen, Dank voor jullie meningen en opmerkingen.
Heeft iemand nog echt concrete tips voor mij?

Acties:
  • 0 Henk 'm!

  • Twazerty
  • Registratie: April 2006
  • Laatst online: 20:10

Twazerty

AVCHDCoder developer

Bij mij viel het kwartje pas toen ik onderstaande begreep:

Java:
1
2
3
for(String string:strings){
 // Doe iets
}


gelukkig was dat al in de tweede les. De relatie met wiskunde zie ik vooral in logica. Ik was altijd goed in wiskunde en dat heeft mij veel geholpen. Ik ben overigens geen ster en haak op een gegeven moment ook af als het te abstract wordt.

Abstract kunnen denken is wel een pre.

Ruisende versterker: schakel je subwoofer in.


Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 14:20
Ik wil er nog even aan toevoegen dat het snappen van OOP alleen niet genoeg is. Mooi voorbeeld kwam uit mijn 1e jaar HBO. Ik moest samen met iemand een mobile java game maken. Ik snapte heel goed OOP, maar wist niet waar ik moest beginnen met het 'probleem' tackelen. Mijn projectgenoot kwam toen na een week of wat aanzetten met een complete game met echt de meest ranzige code qua OOP aspecten, maar het werkte wel. Ik heb het toen helemaal herschreven naar een fatsoenlijke codebase, maar in mijn eentje had ik het echt nooit kunnen doen.

Mijn advies is dus ook begin met programmeren, maak iets moois en vraag dan iemand om uit te leggen hoe je dat OO moet maken. Dat *kan* het kwartje bij je doen laten vallen :)

Acties:
  • 0 Henk 'm!

  • Zoijar
  • Registratie: September 2001
  • Niet online

Zoijar

Because he doesn't row...

Anoniem: 391751 schreef op vrijdag 15 november 2013 @ 20:48:
Heeft iemand nog echt concrete tips voor mij?
Ik snap niet echt wat voor concrete tips je wilt. "Het kwartje valt niet bij C# of Java" ... nog een keer het boek lezen? Wat snap je niet?

Laat dat hele OOP gaan. Schrijf gewoon code die het doet, isoleer functionaliteit, en voila, je hebt je classes. Programmeren is niet veel anders dan functionaliteit klassificeren: elk stuk code moet een duidelijke, enkele taak hebben. Dan knoop je die kleine taakjes aan elkaar tot een stukje dat een ook weer een iets abstractere taak heeft, maar nog steeds een taak. Totdat die taak main() is.

[ Voor 40% gewijzigd door Zoijar op 16-11-2013 00:12 ]


Acties:
  • 0 Henk 'm!

  • Shadowhawk00
  • Registratie: Juli 2010
  • Laatst online: 11-05-2024
Wat mij wel hielp is als je je opdrachtbeschrijving hebt om de belangrijke zelfstandige naamwoorden te onderstrepen. Of ga eens nadenken welke onderdelen je in het echt ziet en gebruik dat eens als objecten.

Wij kregen als voorbeeld het automatiseren van een bieb ( je weet wel dat gebouw waar ze die papieren ebooks uitlenen ) Dingen als boeken, kaartenbak, klanten, uitleenkaart enzo kan je dan gaan zien als objecten en die doen dan hetzelfde als die dingen in een "normale" bieb.

OO is een manier van denken als het kwartje valt dan is het daarna ook heel lastig om weer niet OO te gaan werken. script talen zijn voor mij nu heel irritant omdat het allemaal procedureel is ipv OO.

Acties:
  • 0 Henk 'm!

  • FRidh
  • Registratie: Januari 2004
  • Laatst online: 16:07
Zoijar schreef op zaterdag 16 november 2013 @ 00:08:
[...]

Schrijf gewoon code die het doet, isoleer functionaliteit, en voila, je hebt je classes. Programmeren is niet veel anders dan functionaliteit klassificeren: elk stuk code moet een duidelijke, enkele taak hebben.
Ik denk ook dat het het beste is voor jou om voorlopig op zo'n manier te werken. Schrijf code, tijdens het schrijven zal je opvallen dat bepaalde code iets herhaalt, maakt het een functie, en ga zo door. Ik denk dat je dan vanzelf wel beter wordt in het eerder inschatten welke functionaliteit geisoleerd moet worden en hoe.
Shadowhawk00 schreef op zaterdag 16 november 2013 @ 00:56:
Of ga eens nadenken welke onderdelen je in het echt ziet en gebruik dat eens als objecten.
Deze manier van nadenken hielp mij in het begin enorm, en ik denk dat dit ook een goede manier is te leren abstracter te denken. Kijk eens rond, wat zie je allemaal, welke eigenschappen hebben objecten en hoe hangen deze objecten en eigenschappen samen met andere objecten en eigenschappen. Kan je objecten groeperen op bepaalde eigenschappen of niet? Nu moet ik zeggen dat deze manier van denken mij wel erg ligt, waarschijnlijk ook door mijn achtergrond in natuurkunde.

Research is to see what everybody else has seen, and to think what nobody else has thought - Albert Szent-Györgyi


Acties:
  • 0 Henk 'm!

  • Lethalis
  • Registratie: April 2002
  • Niet online
Caelorum schreef op vrijdag 15 november 2013 @ 23:17:
Ik wil er nog even aan toevoegen dat het snappen van OOP alleen niet genoeg is. Mooi voorbeeld kwam uit mijn 1e jaar HBO. Ik moest samen met iemand een mobile java game maken. Ik snapte heel goed OOP, maar wist niet waar ik moest beginnen met het 'probleem' tackelen. Mijn projectgenoot kwam toen na een week of wat aanzetten met een complete game met echt de meest ranzige code qua OOP aspecten, maar het werkte wel. Ik heb het toen helemaal herschreven naar een fatsoenlijke codebase, maar in mijn eentje had ik het echt nooit kunnen doen.
Programmeren is dan ook veel meer dan alleen OOP.

Sterker nog, ik ben pas begonnen met objectgeorienteerd ontwikkelen toen ik met C++ begon. Al die jaren daarvoor heb ik met Visual Basic 4 en 5, en daarvoor met PowerBASIC (DOS) gewerkt. Dat had niets met OOP te maken, maar toch heb ik (en ook mijn vader) er hele programma's mee gebouwd die we voor duizenden gulden's hebben verkocht.

Het schrijven van goede algoritmes is net zo belangrijk als het snappen van OOP. Misschien zelfs wel belangrijker.

Een taal die ik vroeger vervloekte, maar de laatste jaren op mijn werk steeds meer mee doe is JavaScript. Daar doe ik eigenlijk bijna geen OOP mee (behalve JSON en DOM), maar ik heb het keihard nodig om interactieve web applicaties te bouwen. De serverkant is wel volledig objectgeorienteerd (webservices etc), maar aan de client kant ben ik vooral aan het scripten. En dan is het schrijven van slimme functies veel belangrijker dan het onderbrengen in classes :P

Er zijn zelfs hele volkstammen die tegen het gebruik van OOP zijn..

"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function." - John Carmack

"The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong


Bovendien zijn er bepaalde richtingen, bijvoorbeeld embedded development, waarbij OOP wordt afgeraden vanwege het geheugengebruik. Daar wordt vaak nog plain old C gebruikt, omdat het efficienter is.

Don't get me wrong, ik heb op zich niets tegen OOP en gebruik het zelf ook (ben ook voorstander van het gebruik van ORM wanneer het om database toegang gaat), maar het is simpelweg niet zo dat OOP altijd het belangrijkste is in het leven van een programmeur.

[ Voor 8% gewijzigd door Lethalis op 18-11-2013 10:35 ]

Ask yourself if you are happy and then you cease to be.


Acties:
  • 0 Henk 'm!

  • Sissors
  • Registratie: Mei 2005
  • Niet online
Volgens mij wordt bij embedded development tegenwoordig steeds vaker C++ gebruikt. Bij een 8-bit microcontroller is het inderdaad niet iets wat je wilt ivm geheugengebruik. Echter de grotere 32-bit microcontrollers kunnen het vaak prima hebben. En OOP heeft dan gewoon flinke voordelen in veel situaties.

Echter je moet het inderdaad niet geforceerd doen, je moet het doen omdat het voordelen heeft. Dat is dan ook het voordeel met C++, je kan ook gewoon probleemloos C functies gebruiken. Je moet gebruiken wat voor jouw doel het beste is, niet automatisch OOP. Maar met de wat serieusere microcontrollers kan dat prima qua geheugengebruik. (Wel weer met een kleinere versie van de standaard libs).

Acties:
  • 0 Henk 'm!

  • Shadowhawk00
  • Registratie: Juli 2010
  • Laatst online: 11-05-2024
Sissors schreef op maandag 18 november 2013 @ 11:00:
Volgens mij wordt bij embedded development tegenwoordig steeds vaker C++ gebruikt. Bij een 8-bit microcontroller is het inderdaad niet iets wat je wilt ivm geheugengebruik. Echter de grotere 32-bit microcontrollers kunnen het vaak prima hebben. En OOP heeft dan gewoon flinke voordelen in veel situaties.

Echter je moet het inderdaad niet geforceerd doen, je moet het doen omdat het voordelen heeft. Dat is dan ook het voordeel met C++, je kan ook gewoon probleemloos C functies gebruiken. Je moet gebruiken wat voor jouw doel het beste is, niet automatisch OOP. Maar met de wat serieusere microcontrollers kan dat prima qua geheugengebruik. (Wel weer met een kleinere versie van de standaard libs).
Sterker nog het kan omgekeerd ook. Je kan gewoon OO programmere in standaard C. Toegegeven dingen als private and public ben je kwijt maar veel werkt ook gewoon.
Maar C++ is eigenlijk de enige taal die alle aspecten van OO heeft, en je mag ze gebruiken het hoeft niet maar je kan ook hard de mist in gaan.

Acties:
  • 0 Henk 'm!

  • Lethalis
  • Registratie: April 2002
  • Niet online
Shadowhawk00 schreef op maandag 18 november 2013 @ 12:53:
[...]
Sterker nog het kan omgekeerd ook. Je kan gewoon OO programmere in standaard C. Toegegeven dingen als private and public ben je kwijt maar veel werkt ook gewoon.
Voor zover je het gebruik van typedefs en structs met pointers handig OO programmeren vindt :+

Ask yourself if you are happy and then you cease to be.


Acties:
  • 0 Henk 'm!

  • Jizzy
  • Registratie: Maart 2011
  • Laatst online: 22-05 17:38
Het beste advies blijft nog altijd om het gewoon veel te doen. In het begin zul je ontzettend lelijke code schrijven en soms uren over iets simpels doen, maar op een gegeven moment wordt je er langzaam steeds beter in.

Acties:
  • 0 Henk 'm!

Anoniem: 556043

Hoiii,

Ik ben zelf student HBO software, ik had 0,0 ervaring met programmeren, en nu gaat het me heel goed af.

Hoe ik dat heb gedaan?
Heeeeeeeeel veeeeeel oefenen en tuts volgen.
En dat is echt het enige advies, je moet het super veel doen.

Deze website kan je daar wel bij helpen.
http://thenewboston.org/tutorials.php

Succes

Acties:
  • 0 Henk 'm!

Anoniem: 225842

OO valt ook vaak samen met Design Patterns. Weten waarom (de pattern) je het opdeelt in classes maakt het natuurlijk ook makkelijker om het te begrijpen. Vaak als je iets opdeelt in classes ben je onbewust al met een pattern bezig.

[ Voor 4% gewijzigd door Anoniem: 225842 op 18-11-2013 15:11 ]


Acties:
  • 0 Henk 'm!

  • Oxidda
  • Registratie: Maart 2010
  • Laatst online: 25-12-2023

Oxidda

Heer Opblaaskrokodil

Anoniem: 225842 schreef op maandag 18 november 2013 @ 15:11:
OO valt ook vaak samen met Design Patterns. Weten waarom (de pattern) je het opdeelt in classes maakt het natuurlijk ook makkelijker om het te begrijpen. Vaak als je iets opdeelt in classes ben je onbewust al met een pattern bezig.
Alleen krijg je dan weer zo dat mensen design patterns gebruiken om het pattern, niet om het probleem.

Mijn advies, als je begint met programmeren. Niet zo nou kijken naar de patterns en als je eenmaal aan de bak gaat er voor zorgen dat je een junior traject in kan gaan waarin ze je kunnen omkleden tot een ontwikkelaar.

Zoals velen hier zeggen, er moet een bepaald kwartje vallen ongeacht welke taal, dat kwartje is hetzelfde. Je zou het kunnen leren door veel te doen, maar dat heeft mij niet geholpen. Bij mij viel het kwartje pas toen ik in een traineeship zat en een ontwikkelaar met een hele grote rugzak vol ervaring het ging uitleggen. En toen werd het allemaal een stuk lastiger.

Dan word je gebombardeerd met patterns en best practices, waarvan ik me bij een aantal nogsteeds afvraag of we het niet ingewikkelder maken dan eigenlijk nodig is. Om niet door te draven op wat er met de IT mis is:

Je hebt gewoon een goede leermeester nodig, voor de een tutorials, voor de andere een ervaren programmeur.

Acties:
  • 0 Henk 'm!

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Shadowhawk00 schreef op maandag 18 november 2013 @ 12:53:
[...]
Maar C++ is eigenlijk de enige taal die alle aspecten van OO heeft, en je mag ze gebruiken het hoeft niet maar je kan ook hard de mist in gaan.
Welke aspecten van OO heeft een taal als Java of C# dan niet?

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


Acties:
  • 0 Henk 'm!

  • zonoskar
  • Registratie: Januari 2000
  • Laatst online: 31-05 20:35

zonoskar

<-- Mika R.I.P!

Ik programmeer al 17 jaar (professioneel) C code moor ook ik snap niet veel van al dat OO gedoe met classes voor zelfstandige naamwoorden. Als ik een OO cursus doe, heb ik ook meestal een veel eenvoudiger ontwerp dan de bedoeling was. Het is, wat al gezegd is, ook een kwestie van veel doen. En ergens beginnen en refactoren is ook een goede suggestie.

Powermac G5 casemod. Mijn PV live output. | Ioniq 6 Style 77kWh Ultimate Metallic Red 18" RWD


Acties:
  • 0 Henk 'm!

  • Shadowhawk00
  • Registratie: Juli 2010
  • Laatst online: 11-05-2024
Woy schreef op maandag 18 november 2013 @ 15:59:
[...]

Welke aspecten van OO heeft een taal als Java of C# dan niet?
Multiple inheritance. Ja ze hebben het soort van met interfaces maar echt handig is dat niet, moet je nog steeds dezelfde method meerdere keren schrijven.
Soms kan dat wel handig zijn maar net zoals elke tool use with care.

Overigens vind ik wel dat veel mensen zijn doorgeslagen in OO en design patterns. Het zijn hulpmiddelen om je doel te bereiken. Er is niets mis met je design als je geen design pattern gebruikt en je programma kan net zo goed zijn zonder OO ontwerp.

Acties:
  • 0 Henk 'm!

  • krazzer
  • Registratie: Juli 2007
  • Laatst online: 16-05 11:50

krazzer

Tijd is een illusie

Hoe goed was je in wiskunde op de middelbare school? Toen ik Informatica ging studeren vertelde ze dat mensen die gemiddeld een 9 stonden, er 80% de opleiding haalde en mensen die gemiddeld een 5 stonden 0%

Acties:
  • 0 Henk 'm!

  • Droozle
  • Registratie: Juli 2004
  • Laatst online: 02-07-2022
Programmeren is in feite niets anders dan een probleem ophakken in kleine deelproblemen, net zo lang totdat elk kleiner probleem heel eenvoudig is te beschrijven. Goed leren programmeren is dan ook deels een kwestie van logisch leren beredeneren, en deels een kwestie van weten hoe een computer werkt.

Misschien heb je moeite met het opdelen in stappen. Het helpt dan om kleine, simpele programma's te bestuderen die je kan vinden in tutorials. Kies een onderwerp dat je leuk vindt, of stel jezelf een doel, en zoek op internet naar tutorials die je daarbij kunnen helpen.

Misschien heb je moeite met het dialect en de schrijfwijze van de programmeertaal. Ook dan geldt: bestudeer kleine, compacte programmaatjes. Probeer echt te begrijpen wat er staat, stap voor stap. Je zult er moeite voor moeten doen, en bij de een gaat het wat sneller dan bij de ander.

Overigens hoort jouw leraar (lerares) in staat te zijn om deze materie duidelijk uit te leggen. Wellicht schort het daaraan een beetje, en is het niet helemaal jouw schuld dat dat kwartje nog niet gevallen is.

Edit: kijk ook eens op http://projecteuler.net/ , daar staan compacte uitdagingen die je in elke programmeertaal op kan lossen. Zeker de eerste 10 of 20 problemen zijn goed te doen en soms toch iets ingewikkelder dan ze op het eerste oog lijken. Bijt je erin vast, en als je de oplossing gevonden hebt, kun je lezen hoe anderen het aangepakt hebben. Daar leer je soms best wat van.

[ Voor 15% gewijzigd door Droozle op 18-11-2013 17:40 ]


Acties:
  • 0 Henk 'm!

  • Oxidda
  • Registratie: Maart 2010
  • Laatst online: 25-12-2023

Oxidda

Heer Opblaaskrokodil

Shadowhawk00 schreef op maandag 18 november 2013 @ 16:42:
[...]


Multiple inheritance. Ja ze hebben het soort van met interfaces maar echt handig is dat niet, moet je nog steeds dezelfde method meerdere keren schrijven.
Soms kan dat wel handig zijn maar net zoals elke tool use with care.

Overigens vind ik wel dat veel mensen zijn doorgeslagen in OO en design patterns. Het zijn hulpmiddelen om je doel te bereiken. Er is niets mis met je design als je geen design pattern gebruikt en je programma kan net zo goed zijn zonder OO ontwerp.
De vraag is alleen of je multiple inheritance wel wilt gebruiken. Bij mijn weten is ook C# gewoon volledig OO , het ondersteund inheritance. Het is bij mijn weten niet zo dat je in OO per definitie multiple inheritance moet kunnen ondersteunen (Als dit fout is hoor ik het graag van je). Je maakt het daarmee namelijk moeilijker dan dat het is. En het kan iets als 'Single Responsibilty Principle' behoorlijk vernaggelen. Uiteraard kan je dat met goede afspraken voorkomen, mits men zich der aan houdt.

Zelf ben ik het gedeeltelijk met je eens. Er zijn inderdaad applicaties waar je alle regels aan je lars lapt, met name applicaties waar je voor de rest geen onderhoud aan gaat plegen. Bij mij was dat veelal de projectjes op school waarbij je alleen hoefde te laten zien dat het werkt.

Als je een programma bouwt waar je ook dan een redelijke lifecycle aan zit (Zoals bijv. Enterprise pakketten) dan zou ik me toch wat nauwer nemen op de OO principes en de onderhoudbaarheid van code door bijv een pattern toe te passen. Alleen dan moet het pattern toepassen niet het doel worden en dat word het meestal wel.

Voor beginnende ontwikkelaar zou ik me alleen geen zorgen maken over patterns, helemaal niet als je er net bij komt kijken. Dan is het belangrijkste syntax en standaard OO truukjes leren (Die zijn vrij essentieel om de meeste patterns onder de knie te krijgen).

Zoals ik al eerder zei, je mist een goede leermeester. Iemand die je op je handjes tikt en zegt hoe het wel "goede code is" of een hele goeie set tutorials waar je wat van kunt opsteken. En denk maar zo: De meeste mensen zaten in hetzelfde schuitje als dat jij zit.

Acties:
  • 0 Henk 'm!

  • Shadowhawk00
  • Registratie: Juli 2010
  • Laatst online: 11-05-2024
Oxidda schreef op maandag 18 november 2013 @ 17:56:
[...]


De vraag is alleen of je multiple inheritance wel wilt gebruiken. Bij mijn weten is ook C# gewoon volledig OO , het ondersteund inheritance. Het is bij mijn weten niet zo dat je in OO per definitie multiple inheritance moet kunnen ondersteunen (Als dit fout is hoor ik het graag van je). Je maakt het daarmee namelijk moeilijker dan dat het is. En het kan iets als 'Single Responsibilty Principle' behoorlijk vernaggelen. Uiteraard kan je dat met goede afspraken voorkomen, mits men zich der aan houdt.
MI kan voor heel vervelende situaties gelden klopt, maar het is wel een tool die soms handig is.
Het is heel handig dat objecten eigenschappen van 2 andere parent objecten kunnen hebben, dat is ook onderschreven door interfaces in C# en JAVA.
Zelf ben ik het gedeeltelijk met je eens. Er zijn inderdaad applicaties waar je alle regels aan je lars lapt, met name applicaties waar je voor de rest geen onderhoud aan gaat plegen. Bij mij was dat veelal de projectjes op school waarbij je alleen hoefde te laten zien dat het werkt.
Ik weet niet waar ik heb gezegd dat je al de regels aan je laars moet lappen maar er zijn toepassingen waarin OO gewoon niet mogelijk of handig is. Zelfs voor grote onderhoudbare systemen word niet altijd OO gebruikt omdat er voor de hardware simpelweg geen tools zijn. ASLM gebruikte toen ik er zat ook C voor de machines.
Juist op school wil je cleane code schrijven, vaak zijn docenten niet zo creatief en wat objecten hergebruiken van je vorige opdracht kan best wat tijd besparen. En je hebt docenten die je code beoordelen.
Als je een programma bouwt waar je ook dan een redelijke lifecycle aan zit (Zoals bijv. Enterprise pakketten) dan zou ik me toch wat nauwer nemen op de OO principes en de onderhoudbaarheid van code door bijv een pattern toe te passen. Alleen dan moet het pattern toepassen niet het doel worden en dat word het meestal wel.
Dat was ook mijn insteek, design patterns zijn een middel geen doel op zich. Lees het boek een keer door zodat je weet wat er aan patterns beschikbaar is en zet het in als het nuttig is. In tegenstelling tot school zijn er geen bonuspunten voor het gebruik van elk pattern in je code.

Acties:
  • 0 Henk 'm!

  • Cubic X
  • Registratie: Augustus 2006
  • Laatst online: 11:48
Niet om je te ontmoedigen, maar bij sommigen valt het kwartje nooit (zie ondergetekende). Als je niet goed was/bent in wiskunde dan kan je het wel vergeten.

Ik ben nog wel actief in de programmeerwereld, maar dan als PHP'er voor websites (CMS'en). Daar heb je geen OO voor nodig en dat gaat me goed af.

Acties:
  • 0 Henk 'm!

  • Shadowhawk00
  • Registratie: Juli 2010
  • Laatst online: 11-05-2024
Cubic X schreef op maandag 18 november 2013 @ 19:24:
Niet om je te ontmoedigen, maar bij sommigen valt het kwartje nooit (zie ondergetekende). Als je niet goed was/bent in wiskunde dan kan je het wel vergeten.

Ik ben nog wel actief in de programmeerwereld, maar dan als PHP'er voor websites (CMS'en). Daar heb je geen OO voor nodig en dat gaat me goed af.
Die wiskunde eis valt wel mee hoor, ik ben wel redelijk in wiskunde maar ik kan me niet herinneren dat ik ooit iets van wiskunde nodig heb gehad tijdens het programmeren.

Acties:
  • 0 Henk 'm!

  • Bossie
  • Registratie: Juli 2001
  • Nu online
Droozle schreef op maandag 18 november 2013 @ 17:23:
Programmeren is in feite niets anders dan een probleem ophakken in kleine deelproblemen, net zo lang totdat elk kleiner probleem heel eenvoudig is te beschrijven. Goed leren programmeren is dan ook deels een kwestie van logisch leren beredeneren, en deels een kwestie van weten hoe een computer werkt.

Misschien heb je moeite met het opdelen in stappen. Het helpt dan om kleine, simpele programma's te bestuderen die je kan vinden in tutorials. Kies een onderwerp dat je leuk vindt, of stel jezelf een doel, en zoek op internet naar tutorials die je daarbij kunnen helpen.
Tijdens mijn informatica opleiding had ik bijzonder veel moeite met programmeren, en voornamelijk de hoeveelheid en soort opdrachten. Veel opdrachten waren simpelweg programmeren om het programmeren en bijzonder saai (vaak was de halve stereotype nerd klas enthiousiast en had ik iets van "zucht").

Ik had hetzelfde met wiskunde, ook voornamelijk omdat ik er het nut niet van inzag tijdens de opleiding (veel wiskunde kwam immers ook niet terug in de programmeropdrachten).

Ik ben misschien een slecht voorbeeld omdat ik in het tweede jaar ben overgestapt naar bedrijfskundige informatica ondanks dat ik door veel te werken alle punten had gehaald in het eerste jaar.

Nu zeker 8 jaar later programmeer ik redelijk veel en gaat het me veel allemaal makkelijker af, voornamelijk omdat ik nu ook doelgericht bezig ben ipv veel stoffige huiswerkopgaven te maken.

---
Overigens vind ik http://www.codecademy.com/ een prima site om syntax te leren

We're just enthusiastic about what we do. -- Steve Jobs, 1985; Battle.net: Bossie#2919


Acties:
  • 0 Henk 'm!

  • Bossie
  • Registratie: Juli 2001
  • Nu online
Shadowhawk00 schreef op maandag 18 november 2013 @ 19:26:
[...]


Die wiskunde eis valt wel mee hoor, ik ben wel redelijk in wiskunde maar ik kan me niet herinneren dat ik ooit iets van wiskunde nodig heb gehad tijdens het programmeren.
+1; maar het is toch een groot deel van de opleiding.
In mijn geval was er tijdens de opleiding in ieder geval geen link tussen de wiskunde en programmeerlessen.

We're just enthusiastic about what we do. -- Steve Jobs, 1985; Battle.net: Bossie#2919


Acties:
  • 0 Henk 'm!

  • Caddy
  • Registratie: Januari 2000
  • Laatst online: 31-05 23:04

Caddy

Press start to shutdown

Deze: http://www.youtube.com/watch?v=H2AvoAzbGOE presentatie is zeker de moeite waard om te kijken, deze "Regels" hou ik nu ook altijd in mijn achterhoofd na het hebben gezien van deze presentatie.

Acties:
  • 0 Henk 'm!

  • ATS
  • Registratie: September 2001
  • Laatst online: 06-01 08:26

ATS

Droozle schreef op maandag 18 november 2013 @ 17:23:
Programmeren is in feite niets anders dan een probleem ophakken in kleine deelproblemen, net zo lang totdat elk kleiner probleem heel eenvoudig is te beschrijven. Goed leren programmeren is dan ook deels een kwestie van logisch leren beredeneren, en deels een kwestie van weten hoe een computer werkt.
Daar ben ik het niet mee eens. Een goede programmeur moet juist de grote lijn kunnen overzien. Niet alleen het probleem waar je nu aan werkt, maar vooral de samenhang met de rest van het systeem. Divide and conquer werkt vaak wel, maar levert niet altijd het beste resultaat op.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant


Acties:
  • 0 Henk 'm!

  • Caddy
  • Registratie: Januari 2000
  • Laatst online: 31-05 23:04

Caddy

Press start to shutdown

Ik ben geen Java kenner of developer maar als dat voor je studie noodzakelijk is zou ik wellicht eens een avondje hiermee gaan spelen: http://www.playframework.com/

Acties:
  • 0 Henk 'm!

  • KinkyClown
  • Registratie: Maart 2000
  • Laatst online: 28-05 11:38

KinkyClown

Eenvoud is beter dan twee fout

Woy schreef op maandag 18 november 2013 @ 15:59:
[...]
Welke aspecten van OO heeft een taal als Java of C# dan niet?
De andere post gaan allemaal in op multiple inheritance en dat klopt; Java en C# ondersteunen dat niet. Wat wel ontbreekt in deze talen en wat wel mooi is (vind ik) is operator overloading in C++. Ik ben opgeleid in C++ en Assembler maar werkt tegenwoordig in Javascript, Java en C#. Ik kan zonder maar het zou wel mooi zijn om te hebben in Java of C#.
Overigens vind ik multiple inheritance echt een fout iets. Ik heb ooit een grote library geschreven in C++ die er gebruik van maakte. In eerste instantie klonkt het logisch om het te gebruiken en kon ik het onderbouwen maar verderop tijdens de bouw gaat het al snel flink mis. Geef mij maar interfaces werkt mooier en is vele malen veiliger.

Acties:
  • 0 Henk 'm!

  • Amanoo
  • Registratie: December 2007
  • Laatst online: 21-04 11:48

Amanoo

Cᴀᴛs ᴀʀᴇ ɴɪᴄᴇ.

Ik ben het er trouwens wel mee eens dat OO programmeren een kwestie is van een kwartje dat moet vallen. Bij mij heeft het ook wel lang geduurd voordat dat kwartje wilde komen, maar als je eenmaal een beetje door begint te krijgen waar het allemaal om draait is het nog best logisch. Volgende kanaal heeft diverse playlists: YouTube: thenewboston
Onder andere Java (Beginner) Tutorials, Intermediate Java tutorials, Android Tutorials en ik geloof ook nog Game Development in Java. Oftewel, als je Java of concepten die veel in Java gebruikt worden (zoals OO) wil begrijpen is dit een best prima kanaal. Ik heb er zelf ook heel veel aan gehad. Ik durf nu te beweren dat ik het grote plaatje wel kan zien, maar dat heeft me veel tijd en inspanning gekost. Als je het eenmaal begrijpt kan programmeren trouwens best wel leuk zijn. Helaas ben ik een soort Leonard da Quirm, ik verlies snel mijn aandacht bij zelfverzonnen projecten, dus ik maak zelden iets af. Halve programma's en uitvindingen zijn in mijn kamer volop aanwezig.

Ik heb omdat ik nooit met wat anders dan Java heb gewerkt nooit problemen gehad met multiple inheritance, maar ik kan me voorstelen dat het misschien mis wil gaan. 1 ding inheriten houdt het wel zo overzichtelijk. Mijn ervaring is dat er ook prima omheen te werken is als maar 1 ding inherited kan worden. Neem een klasse die een mens beschrijft. Een mens is een primaat, dus primaat is superclass van mens. Het is een "is een"-relatie. Primaat is vervolgens weer een subclass van gewervelde. Omdat mens een primaat is, en primaat een gewervelde is dus ook mens een gewervelde (transitieve relaties heet dat, met een duur woord). Maar een mens is ook een wezen met 5 vingers aan elke hand. Je kan nu proberen om een tweede abstracte klasse te maken als tweede superclass voor mens, waarmee je beschrijft dat die aan elke hand 5 vingers heeft, maar mooier lijkt mij om dat met een interface te doen. Met een interface kan je goed aangeven wat een klasse allemaal kan. Het dient om aan te gevenn wat voor mogelijkheden een klasse heeft, van wat voor methodes er een implementatie is, maar in tegenstelling tot abstract classes/superclasses zegt het niet hoe. Het is in die zin minder sterk, maar wel op zijn eigen manier bruikbaar. Dat is een beetje hoe ik het mentaal voor me zie, althans.

[ Voor 55% gewijzigd door Amanoo op 18-11-2013 22:28 ]


Acties:
  • 0 Henk 'm!

  • t_captain
  • Registratie: Juli 2007
  • Laatst online: 31-05 10:31
@TS: iedereen programmeert in verschillende mate wel met OO principes. Het begint met het isoleren van functionaliteit, nadenken over welke minimale interface er nodig is enzo. Een stap verder ga je namespaces gebruiken of classes als middel om bij elkaar horende functionaliteit samen te houden en van de buitenwereld af te schermen achter een interface. Nog een stap verder ga je de state van je component ook in de objecten isoleren en dan komt inheritance.

Als je eens een heel andere manier van denken over software wilt oefenen kun je eens kennismaken met een functionele taal zoals Scala of Haskell.

Acties:
  • 0 Henk 'm!

  • juniordiscart
  • Registratie: Juni 2009
  • Laatst online: 06-05 14:37
Ik heb zelf het geluk gehad dat het kwartje redelijk snel was gevallen bij mij, maar ik kan er in komen dat de standaard voorbeelden die men gebruikt voor OO programmeren niet altijd even duidelijk zijn (bvb. het voorbeeld van de auto en zijn onderdelen en afgeleiden).

Wat mij persoonlijk meer hielp was om het van een andere kant te bekijken. Ik heb eerst geleerd procedureel te programmeren, en zo elk probleem in kleinere deelproblemen op te delen en die verder uit te werken. Dit was simpel.
Dan, OO programmeren heb ik eigenlijk geleerd door te kijken naar het probleem als een soort van "opperwezen" dat de macht krijgt over allerlei objecten in een doos. Met deze objecten in de doos wordt er verwacht een bepaald probleem op te lossen. Er zijn dan objecten die je aan elkaar kan koppelen die zouden samenwerken, en objecten die je dan kan opdragen om een bepaalde actie te ondernemen die leiden naar de totale oplossing.

Om dan toch even het voorbeeld van de auto nog even te gebruiken.
Het probleem: programmeer een conceptuele auto, en laat deze rijden aan een constante snelheid van 100km/h.
De oplossing: programmeer de verschillende onderdelen van de auto zoals de wielen en de motor. Plaats de onderdelen in elkaar (programmeer een object "auto" dat deze onderdelen bevat) en laat hem rijden tegen een constante snelheid (roep de methode "drive" op, op het "auto" object).

Ik hoop dat je hier iets aan hebt, en het zeker niet moeilijker heb gemaakt voor je. Alvast succes met het omver krijgen van je kwartje. ;)

Acties:
  • 0 Henk 'm!

  • The Eagle
  • Registratie: Januari 2002
  • Laatst online: 19:47

The Eagle

I wear my sunglasses at night

Bij mij viel het kwartje van OO pas 5 jaar nadat ik afgestudeerd was. Ik heb het toen maar opgeraapt en in mijn zak gestopt - kon immers nog eens van pas komen ;)
Overigens: zelfde uitleg heb ik recentelijk aan een stel ex-boekhouders gegeven. Don't ask, maar die snapten het ook. Dus here goes: OO voor dummies :P

Je hebt een object, laten we een theesetje beschouwen:

Afbeeldingslocatie: http://www.1000en1smaken.nl/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/t/h/theekopje_rood_schotel_7.jpg

Dit setje bestaat uit een kopje, een schotel, en een (theezak)houder. Dat zijn je hoofdobjecten.
Ieder object kan bepaalde eigenschappen hebben; zo heeft het kopje een bepaalde kleur, vorm, inhoud, etc. Idem voor de schotel en de houder.
OO vertaald wordt dat bijvoorbeeld:
Kopje.colour=red
Kopje.shape=oval.
In bovenstaand plaatje lijkt het kopje leeg te zijn, dus ook geldt:
Kopje.value = 0

Maar dat zelfde kopje heeft ook een oor. Dat is ook een object dat je kunt initieren; immers: een kopje kan wel of geen oor hebben.
Kopje.oor.colour=red
Kopje.oor.shape=round
Stel ik heb geen oor aan mijn kopje, of ik zie het niet, dan geldt:
Kopje.oor.=null, of Kopje.oor.visible=false
Het is maar wat je wilt.

Zo zou je ook een oor standaard een vorm en kleur kunnen geven:
Initiatate Oor:
Oor.shape = square
Oor.colour = green
Als je dan ineens zegt:
Kopje.Oor = Oor
Dan heb je ineens een rood kopje (want dat was het al) met een vierkant groen oor :)

Dit is het eigenlijk in een notedop. Je zou het hele theesetje als een class kunnen beschouwen, waar je dan weer dingen mee kunt doen. Bijvoorbeeld
Theesetje.colour = green
Dat is een gevalletje inheritance; alle objecten erven dan een eigenschap over van de class waar ze in zitten
Of deze:
Afbeeldingslocatie: http://oregonshar.files.wordpress.com/2012/12/empty-square.jpg
spoiler:
Wat anders dan: Theesetje.visible = false :P


En zo kun je door gelaagdheid steeds verder. Ermee programmeren is een kwestie van de juiste syntax gebruiken. Maar daar heb je je syntax-checker voor, danwel je compiler ;)
Tip: als je UltraEdit of Emerald Editor (freewareversie van Ultraedit) gebruikt, kun je daar een syntax highlighter inzetten voor jouw specifieke taal. Zijn zo te downloaden, even zoeken :)

Leuk detail trowuens: Ik kom in mijn werk zelfs af en toe instantiaties van complete programma's tegen die ook elkaar weer . Leuk voor parallel processing enzo. Maar gelukkig ben ik daar nit de programmeur van, ik hou het wel bij theekopjes, of liever nog

Kopje.koffie.value=1
Kopje.koffie.strenght=20
;)

Al is het nieuws nog zo slecht, het wordt leuker als je het op zijn Brabants zegt :)


Acties:
  • 0 Henk 'm!

  • Kettrick
  • Registratie: Augustus 2000
  • Laatst online: 13:55

Kettrick

Rantmeister!

Caddy schreef op maandag 18 november 2013 @ 21:18:
Ik ben geen Java kenner of developer maar als dat voor je studie noodzakelijk is zou ik wellicht eens een avondje hiermee gaan spelen: http://www.playframework.com/
Play hangt behoorlijk aan elkaar van complexe bilbliotheken. Voor je het week bevind je je in de wereld van Scala, Akka en SBT. Niets mis mee, het is mijn dagelijkse stack, maar voor een beginner zou ik het niet echt aanraden.

Als je wilt leren programmeren zijn java webframeworks helemaal niet interessant, omdat het voor een beginner ontzettend moeilijk is om de grens te trekken tussen "Java" en alle play/tomcat/spring/* boilerplate meuk.

Download de community versie van IntelliJ en ga lekker tests schrijven in JUnit, op die manier kan je je 100% richten op dat waar het om gaat, programmeren.

Acties:
  • 0 Henk 'm!

  • codebeat
  • Registratie: Januari 2010
  • Laatst online: 24-05 15:13
Het enige dat helpt is..... oefenen. Kies zelf een probleem en ga daarmee aan de slag, niet uit een boekje gewoon beginnen. Of maak een programma wat je altijd al wilde maken. Je neus stoten en dan zelf de oplossing vinden werkt het beste. Ben het met je eens dat het veel tijd kan kosten maar ja, je wordt er wel wijzer van.

Probleem met opleidingen is dat het nogal droge stof is vaak, althans dat was een paar jaar geleden nog zo. Priemgetallen afdrukken en dat soort ongein. Heb ook een Java cursus gedaan, echt om te huilen qua inhoud, daar leer je dus geen reet van.

Java is sowieso een omslachtige taal als je geen framework gebruikt. Verder vind ik de package structuur en namespaces onnodig ingewikkeld, je krijgt al heel snel heel veel (kleine) bestandjes (fragmentatie). Ook dat echt werkelijk alles een klasse of package moet zijn. Dat is ook de reden dat ik niet zo gek ben op Java. De vraag is dus of je problemen hebt met het begrijpen van OO of de te gebruiken structuur. Als het laatste het geval is zou ik je willen aanraden een andere programmeertaal te kiezen.

Aansluitend op @Shadowhawk00: "veel mensen zijn doorgeslagen in OO en design patterns." Daar heeft hij groot gelijk in, dat is inderdaad waar. Was ook een keertje met een stukje Javascript (da's weer wat anders natuurlijk) gemaakt door Microsoft. Was zo'n 100 regels, deed iets heel eenvoudigs maar klasse hier klasse daar. Heb toen dat stukje herschreven, hoe ik het zou doen en toen hield ik nog maar 20 regels over, deed exact hetzelfde. Klassen worden te pas en te onpas gebruikt wat de code alleen maar ingewikkelder kan maken.

Ik dacht toen nog: "Als de code van Windows zo gebouwd is, dan weet ik wel waarom het zo traag is". Niet dat Windows in JS is geschreven natuurlijk maar snapt hopelijk het idee. Het is de waanzin die @Shadowhawk00 benadrukt. Code lijkt wel onderhevig te zijn aan hoe 'goed' je code kunt designen terwijl het helemaal niet garandeert duidelijker of beter te zijn. Dan niet te vergeten de snelheid van de code. Het lijkt wel of sommige programmeurs zijn getransformeerd in 'Design Hippies', zonder dat ze nu werkelijk beseffen wat ze aan het doen zijn (behalve de design regels volgen).

Kijk je moet altijd netjes programmeren maar je kunt ook overdrijven. Als het korter kan is het altijd beter. Zet er dan goed commentaar bij ipv al die overdesign bullshit. Het is altijd goed zelf te blijven nadenken en niet zomaar alles klakkeloos over te nemen. 'iedereen doet het' of 'ik heb dat zo op school geleerd' zijn verschuilende redenen en geeft aan dat iemand niet weet waarom ie het zo doet.

Net zoals bij het gebruik van een database, precies hetzelfde verhaal.

Laat het hierbij, misschien kun je er wat mee.

EDIT: Nog een tip. Programmeer in het Engels. Wanneer je in het Nederlands blijft programmeren wen je niet aan de Engelse taal. De programmeertaal is in het Engels dus wees dan consistent. Verder is de code ook gemakkelijker uit te wisselen en begrijpt iemand op een Engels forum (of ander talige collega) ook meteen wat je bedoeld. De reden dat ik dit nu schrijf is het voorbeeld hierboven. Het lijkt eenvoudiger te begrijpen maar als je dan een keer iemands anders code onder je neus kijgt dan begrijp je het niet. Tevens ziet het er niet uit, Kopje.koffie.colour .... jaja.

Net zoiets als de je verwacht: object,getFileName() dat het ineens object.getBestandsnaam() moet zijn. Wordt het daar duidelijker van? Nee.

[ Voor 11% gewijzigd door codebeat op 19-11-2013 00:45 ]


Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Wat mij tijdens mijn scholing erg tegenwerkte was dat de 1e paar jaar we alleen maar simpele opdrachten kregen, bij mij viel het kwartje pas tijdens zelf grotere dingen bouwen waardoor de objecten echt nut kregen ( ipv 5 objecten in 100 regels code stouwen om maar te voldoen aan de opdracht, maar geen idee hebben wat nu het nut van 5 objecten boven 2 objecten en 70 regels code was)

Ik weet dat ik vrij veel schoolopdrachten gewoon maakte met 3x de beschrijving lezen om exact te weten hoeveel objecten ze wilden (want ik zou anders minder objecten gebruiken omdat de school-objecten te "weinig" deden) en dan in mijn hoofd maar onlogische dingen verzinnen om maar aan die x objecten te komen.

Acties:
  • 0 Henk 'm!

  • Kettrick
  • Registratie: Augustus 2000
  • Laatst online: 13:55

Kettrick

Rantmeister!

Erwines schreef op dinsdag 19 november 2013 @ 00:28:
Het enige dat helpt is..... oefenen. Kies zelf een probleem en ga daarmee aan de slag, niet uit een boekje gewoon beginnen. Of maak een programma wat je altijd al wilde maken. Je neus stoten en dan zelf de oplossing vinden werkt het beste. Ben het met je eens dat het veel tijd kan kosten maar ja, je wordt er wel wijzer van.

Probleem met opleidingen is dat het nogal droge stof is vaak, althans dat was een paar jaar geleden nog zo. Priemgetallen afdrukken en dat soort ongein. Heb ook een Java cursus gedaan, echt om te huilen qua inhoud, daar leer je dus geen reet van.
Sommige mensen leren anders dan je zelf gewend bent, niet iedereen is autodidact. Grofweg alle cursussen en opleiding als onzin afdoen is wat kort door de bocht.
Java is sowieso een omslachtige taal als je geen framework gebruikt.
Hier ben ik het, zeker voor een beginner, zeker niet mee eens. Vanilla Java is redelijk goed te begrijpen, zolang je maar van de obscure, en achterhaalde, concepten als servlets vandaan blijft. Gewoon OO coden in tests gaat uitstekend en is weinig omslachtigs aan. Pak er een boek als head-first en dan worden zaken al gauw duidelijk.
Verder vind ik de package structuur en namespaces onnodig ingewikkeld, je krijgt al heel snel heel veel (kleine) bestandjes (fragmentatie). Ook dat echt werkelijk alles een klasse of package moet zijn. Dat is ook de reden dat ik niet zo gek ben op Java. De vraag is dus of je problemen hebt met het begrijpen van OO of de te gebruiken structuur. Als het laatste het geval is zou ik je willen aanraden een andere programmeertaal te kiezen.
Dit is persoonlijk, maar java heeft een redelijk eenvoudige structuur. Als ik kijk naar bijvoorbeeld python's structuur vind ik dat een stuk minder werken. Daarnaast, als je begint met Java dump je alles lekker in de default package en het problem bestaat niet eens. Ik wordt altijd lichtelijk 'grumpy' als mijn collega's weer 20 case classes in "domain.scala" plempen....

Acties:
  • 0 Henk 'm!

  • Sissors
  • Registratie: Mei 2005
  • Niet online
KinkyClown schreef op maandag 18 november 2013 @ 22:10:
[...]

Overigens vind ik multiple inheritance echt een fout iets. Ik heb ooit een grote library geschreven in C++ die er gebruik van maakte. In eerste instantie klonkt het logisch om het te gebruiken en kon ik het onderbouwen maar verderop tijdens de bouw gaat het al snel flink mis. Geef mij maar interfaces werkt mooier en is vele malen veiliger.
Ik ben geen expert, maar waarom is het dan zo'n fout iets? Dat jij er iets mee hebt gemaakt waarbij het mis ging lijkt me niet de schuld van multiple inheritance, dan kan ik nog wel wat dingen de schuld geven.

Ik heb het zelf weleens gebruikt, en vond het toen ideaal voor wat ik ermee wilde doen (Inherit op een embedded system een FAT systeem en een USB mass-storage class, schrijf wat code erbij, en tada, lokaal bestandssysteem dat je via USB kan beschrijven).

Acties:
  • 0 Henk 'm!

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
KinkyClown schreef op maandag 18 november 2013 @ 22:10:
[...]

De andere post gaan allemaal in op multiple inheritance en dat klopt; Java en C# ondersteunen dat niet. Wat wel ontbreekt in deze talen en wat wel mooi is (vind ik) is operator overloading in C++. Ik ben opgeleid in C++ en Assembler maar werkt tegenwoordig in Javascript, Java en C#. Ik kan zonder maar het zou wel mooi zijn om te hebben in Java of C#.
Ten eerste heeft dat natuurlijk in principe helemaal niks met OO te maken, want een operator is ook gewoon een methode. Ten tweede heeft C# al sinds het begin operator overloading. Het is inderdaad wel beperkter dan het in C++ is.

MI word inderdaad niet echt ondersteund in Java en C# en word gedeeltelijk ondervangen door interfaces. C++ moet ook wel MI ondersteunen door het gebrek aan echte interfaces. Er zijn natuurlijk best momenten waarop MI nuttig kan zijn, maar ik vind het wel een logische keus om ze achterwege te laten. Door het gebruik van interfaces en compositie kun je het ook opvangen, maar het is inderdaad wel wat meer werk. Het zou mooi zijn als er vanuit de taal een constructie zou zijn om bijvoorbeeld een interface meteen naar een member te delegeren die die interface ook implementeert.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


Acties:
  • 0 Henk 'm!

  • Zoijar
  • Registratie: September 2001
  • Niet online

Zoijar

Because he doesn't row...

(functional) inheritance is the root of all evil. Compositie is bijna altijd beter. Dat komt omdat er bija nooit volledig voldaan wordt aan de "is-a" constraint. In jouw voorbeeld eindig je vaak met een class die net geen FAT systeem is en ook net geen volwaardig USB systeem omdat ze minder kunnen.

Ik vind het ook zonde dat men op opleidingen vaak meteen begint veel tijd te investeren in inheritance en polymorphisme -- dat zijn dingen die je helemaal niet zo vaak nodig hebt. Voor mij is OOP encapsulatie en bijkomend het scheiden van functionaliteit in blokken met een enkele, goed gedefineerde functie.

(hoezo heeft C++ gebrek aan "echte" interfaces? Wat kan een Java interface dan dat een C++ class met slechts pure virtual methods niet kan?)

[ Voor 45% gewijzigd door Zoijar op 19-11-2013 08:42 ]


Acties:
  • 0 Henk 'm!

  • nozem
  • Registratie: Januari 2009
  • Laatst online: 12-02 12:02
@TS: Ik kan mezelf goed herkennen in je verhaal. Het voelde erg frustrerend. Ik had zelf enige PHP-ervaring: daar kon ik jaren lang heel makkelijk en lelijk iets mee knutselen. De vraag waar ik 4 jaar studie en daarna 2 jaar werk mee rondliep was: why bother with OO?. Waarom 'class hondje' maken met methode blaf(), een instantie maken van dat hondje en daarvan de methode aanroepen terwijl ik ook gewoon echo "waf!"; kan typen?
Voor mij was het niet zozeer een kwartje dat viel, maar een combinatie van de volgende dingen:
  • Head First Java
  • Head First Design Patterns
  • Die boeken zijn dik, absoluut, maar echt ontzettend toegankelijk en beginner-proof. Als je gemotiveerd bent, ben je er zo doorheen. Ik heb het zelfs als heel leuk ervaren. Vervolgens:
  • Toepassen in een paar hobbyprojectjes, ikzelf heb deze breakout-game code gedownload en er zelf wat extra functionaliteit aan toegevoegd. Dat was leuk en leerzaam.
  • De laatste stap van mijn bekering was het terugzien van mijn oude PHP code. Ik heb bittere tranen geweend bij het zien van alle ongestructureerde bende die ik zo ijverig had ingeklopt. (ik weet dat PHP en non-OO niet automatisch betekent dat je lelijke code schrijft, maar voor mij gold dat wel). Ik zag nu gewoon hoe het met OO handiger kon worden aangepakt.
Het blijft een feit dat het in sommige gevallen echt wel een betere keuze is om gewoon echo "waf!"; te gebruiken. Wanneer je dat eenmaal zelf goed kunt bepalen, ben je waar je moet zijn, denk ik.
Ik zie mezelf als iemand die veel moeite moet doen om principes als OOP te doorgronden. Als dat voor jou ook geldt kan ik zeggen: kop op! Met voldoende (en de juiste) investering kom je er absoluut. Heb je dat er niet voor over dan moet je misschien overwegen om een andere richting op te gaan.

Dit gaat overigens allemaal over Java. Toen ik hiermee klaar was (een half jaar geleden) heb ik een baan gevonden als C# programmeur. Die overgang was dan weer een fluitje van een cent :)

Acties:
  • 0 Henk 'm!

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Zoijar schreef op dinsdag 19 november 2013 @ 08:35:
(hoezo heeft C++ gebrek aan "echte" interfaces? Wat kan een Java interface dan dat een C++ class met slechts pure virtual methods niet kan?)
Natuurlijk is een class met alleen pure virtual functies gewoon gelijk aan een interface, maar in C++ word dat onderscheid niet gemaakt, dus het implementeren van een "Interface" is in c++ perspectief ook gewoon MI.
In jouw voorbeeld eindig je vaak met een class die net geen FAT systeem is en ook net geen volwaardig USB systeem omdat ze minder kunnen.
Wat bedoel je met FAT en USB? ( Ik neem aan dat je niet op het file systeem, of Universal Serial Bus doelt ;) )

[ Voor 22% gewijzigd door Woy op 19-11-2013 08:58 ]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


Acties:
  • 0 Henk 'm!

  • Sissors
  • Registratie: Mei 2005
  • Niet online
Dat bedoelt hij wel want hij reageerde op mijn post ;)

Maar dan nog begrijp ik het niet. Want in mijn voorbeeld leverde juist multiple inheritance mij de volledige mogelijkheden van de FAT library en de volledige mogelijkheden van de USB library op. Juist per definitie kan het niet een niet-volwaardig systeem opleveren omdat de hele handel geinherit wordt.

Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 14:20
Gaan we nu niet een beetje te ver in op de talen? Denk niet dat xylon87 daar nu bij gebaat is ^^

Acties:
  • 0 Henk 'm!

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Ah, die reactie had ik over het hoofd gezien. Ik snap dan wel wat er mee bedoeld word. Het is niet handig om een class te maken die van zowel USB als FAT erft. Eigenlijk heb je een class ExternalDisk, die een USB interface heeft, en een FAT disk. Het is dus meer een has-a relatie dan een is-a. Dus kom je op compositie uit in plaats van inheritance.
Caelorum schreef op dinsdag 19 november 2013 @ 11:45:
Gaan we nu niet een beetje te ver in op de talen? Denk niet dat xylon87 daar nu bij gebaat is ^^
Het geeft wel mooi aan dat er niet maar één manier is waarop alle programmeurs denken ;)

[ Voor 29% gewijzigd door Woy op 19-11-2013 11:46 ]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


Acties:
  • 0 Henk 'm!

  • Sissors
  • Registratie: Mei 2005
  • Niet online
Caelorum heeft wel gelijk :P

Maar toch nog even, dat wordt natuurlijk definitie geneuzel. Je kan ook zeggen dat het opslagmedium een lokaal bestandssysteem is, en een USB bestandssysteem is.


Ik denk trouwens wel dat het tot op zekere hoogte ontopic is: (Oké misschien dit multiple inheritance wat minder), maar OO is een heel mooi principe, maar het is zeker niet iets wat altijd de beste optie is.

[ Voor 35% gewijzigd door Sissors op 19-11-2013 11:47 ]


Acties:
  • 0 Henk 'm!

  • ATS
  • Registratie: September 2001
  • Laatst online: 06-01 08:26

ATS

OO is belangrijk, maar het is niet het enige. Een goede programmeur heeft een breder arsenaal dan dat. Denk aan functioneel programmeren en zelfs aan template meta programming.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant


Acties:
  • 0 Henk 'm!

  • Ilantir
  • Registratie: Februari 2008
  • Laatst online: 03-02 01:41
Ik denk dat een goede programmeur ook goed vanuit de business case kan denken. Je moet werk dat mensen doen kunnen ontleden en vertalen naar programmeerstructuren.

Wordpad: Ik heb een Menu nodig om Bewerkingen mee uit te voeren op de Tekst die ik in het (Hoofd)Scherm invoer. (Zie je de hoofdletters?) Ik moet Tekst kunnen openen (Bewerking) en kunnen opslaan (Bewerking, hey is Bewerking een base class?).

Space Invaders: Ik beweeg (Actie) mijn Spaceship met de toetsen (hier moet ik dus input kunnen afvangen) en kan ik Invaders afschieten (Actie). Ik heb gewone Invaders en Boss Invaders (Afgeleid van Invader?).

Als je zo denkt, maakt de taal niet eens uit. Je kunt dan eigenlijk alles bij elkaar googlen.

Acties:
  • 0 Henk 'm!

  • ob3lix
  • Registratie: Januari 2010
  • Laatst online: 30-05 09:24
Ik volg de opleiding business it & management. In mijn propedeuse heb ik ook OO moeten programmeren. Mijn ervaring is, als je maar genoeg oefen, dan kan iedereen wel meekomen.

En ik geloof dat de één het makkelijker kan dan de ander. Maar het belangrijkste is volgens mij dat je het echt leuk vindt! Dat maakt, denk ik, het verschil tussen een goede en matige programmeur.

Hoe graag wil je het leren? Ben je nieuwsgierig naar nieuwe ontwikkelingen? Wil je steeds meer van de taal te weten komen?

Persoonlijk kwam ik erachter dat mijn passie er niet lag en dat ik nooit een excellente programmeur zou worden ;).

Acties:
  • 0 Henk 'm!

  • Lethalis
  • Registratie: April 2002
  • Niet online
Ilantir schreef op dinsdag 19 november 2013 @ 16:55:
Ik denk dat een goede programmeur ook goed vanuit de business case kan denken. Je moet werk dat mensen doen kunnen ontleden en vertalen naar programmeerstructuren.
Dat hangt nogal van de setting af.

Er zijn goede allround programmeurs, maar ook goede technische programmeurs.

Afhankelijk van de setting heb je meer aan de een dan aan de ander.

Ask yourself if you are happy and then you cease to be.


Acties:
  • 0 Henk 'm!

  • MonkeySleeve
  • Registratie: Februari 2009
  • Laatst online: 19:29

MonkeySleeve

It's just Monkey business

Ben nu bezig met afstuderen betreft Software Engineer, maar als ik zo die termen lees heb ik wel weer zoiets van; Ehm oh ja, wat was dat ook alweer. :P

Did you bring the banana's? Steam-id: MonkeySleeve


Acties:
  • 0 Henk 'm!

  • Ahrnuld
  • Registratie: April 2002
  • Laatst online: 20:32
Zeker niet iedereen kan meekomen. Ik werk wel eens met mensen die net in het grensgebied zitten, en dan merk je dat sommige mensen gewoon echt niet in staat zijn om abstract genoeg te denken. Zelfs met oefening blijft het niet meer dan kunnen reproduceren, en niet tot probleemoplossing (wat eigenlijk wel de kern is van ons werk?)

Maar die mensen kom ik weinig tegen, en over het algemeen ook niet op HBO of universiteit. Je hebt het dan al vrij zwaar binnen het VMBO.

Niets...


Acties:
  • 0 Henk 'm!

  • Lethalis
  • Registratie: April 2002
  • Niet online
Ik heb de ebook van dit boek gevonden online en even de eerste twee hoofdstukken gelezen (strategy pattern voorbeeld met eendjes, en het observer pattern voorbeeld met de weather app).

Het is inderdaad een leerzaam boek. Ik vind het wel wat overdreven met alle plaatjes, er staat eigenlijk zoveel onzin er omheen in die ik skip om de essentie er uit te halen dat de eerste 100 pagina's "lezen" voor mij een kwestie was van 3 kwartier ofzo.

Dus van die 654 pagina's is de helft eigenlijk gebakken lucht. Misschien werkt mijn brein anders dan zij verwachten :P

Maar goed, alsnog wel een aardig boek om te lezen als je weinig tot geen ervaring met patterns hebt.

Ask yourself if you are happy and then you cease to be.


Acties:
  • 0 Henk 'm!

  • curvemod
  • Registratie: Maart 2009
  • Laatst online: 19:39
Lethalis schreef op zaterdag 23 november 2013 @ 13:40:
[...]

Ik heb de ebook van dit boek gevonden online en even de eerste twee hoofdstukken gelezen (strategy pattern voorbeeld met eendjes, en het observer pattern voorbeeld met de weather app).

Dus van die 654 pagina's is de helft eigenlijk gebakken lucht. Misschien werkt mijn brein anders dan zij verwachten :P
Tja maar er al het een en ander van weet dan is dat niet het juiste boek natuurlijk, dus geen wonder dat je de helft skipt. Ik heb het gelezen toen ik nog bijna niets wist van design patterns en ik vond het een goed boek. Het helpt je op een vrij relaxte manier kennis te maken met design patterns.

Acties:
  • 0 Henk 'm!

  • nozem
  • Registratie: Januari 2009
  • Laatst online: 12-02 12:02
Lethalis schreef op zaterdag 23 november 2013 @ 13:40:
[...]

Ik heb de ebook van dit boek gevonden online en even de eerste twee hoofdstukken gelezen (strategy pattern voorbeeld met eendjes, en het observer pattern voorbeeld met de weather app).

Het is inderdaad een leerzaam boek. Ik vind het wel wat overdreven met alle plaatjes, er staat eigenlijk zoveel onzin er omheen in die ik skip om de essentie er uit te halen dat de eerste 100 pagina's "lezen" voor mij een kwestie was van 3 kwartier ofzo.

Dus van die 654 pagina's is de helft eigenlijk gebakken lucht. Misschien werkt mijn brein anders dan zij verwachten :P

Maar goed, alsnog wel een aardig boek om te lezen als je weinig tot geen ervaring met patterns hebt.
Het is inderdaad meer op beginners gericht. En ik kan me ook wel voorstellen dat het niet voor iedereen werkt. Ik heb zelf ook ervaren dat ze veel herhalen, terwijl je het soms allang snapt. Maar herhaling is ook weer goed 'to make it stick'.
semi-offtopic: Ik ben zelf nog steeds een redelijk beginnend programmeur en voor mij was "Clean Code" van Robert "uncle Bob" C. Martin een uitstekende volgende stap qua verdieping. In veel opzichten zijn de tips die daarin worden genoemd behoorlijk ambitieus (ik ben vaak al blij dat mijn code runt en performt), maar het 'vormt' je wel. :)
Pagina: 1