Archief - Static/Final

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Cycloon

Legacy Member
NoGo zei:
Ik vraag mij eigenlijk af wat het nut is om a1.dieselprijs te gebruiken ipv Auto.dieselprijs :p Waarom zou je dit gebruiken?

Ook statics kunnen overschreven worden. Wanneer je dus niet op voorhand weet welk type je terugkrijgt dan kan je rechtstreeks via de instantie de variabele opvragen.

Overigens, een compiler warning duidt niet op foutief gebruik. Ik kan voldoende warnings aangeven die in vele situaties totaal irrelevant zijn.

Emerxill

Legacy Member
Cycloon zei:
Ook statics kunnen overschreven worden. Wanneer je dus niet op voorhand weet welk type je terugkrijgt dan kan je rechtstreeks via de instantie de variabele opvragen.
Meestal weet je wel in welke klasse die static steekt en spreek die die best aan op klasse niveau. Dat staat los van uw instance vind ik.

Verder geef ik je gelijk wat de "conceptuele fout" betreft. Het feit dat een static ook op instance niveau aanspreekbaar is, is volgens mij geen bad design van de programmeertaal. Want een static behoort conceptueel zowel bij de klasse als bij de instances. Het gebruiken van die static op instance niveau is door de programmeur is dan wel minder proper :)

NeverwinterX

Legacy Member
Emerxill zei:
Verder geef ik je gelijk wat de "conceptuele fout" betreft. Het feit dat een static ook op instance niveau aanspreekbaar is, is volgens mij geen bad design van de programmeertaal. Want een static behoort conceptueel zowel bij de klasse als bij de instances. Het gebruiken van die static op instance niveau is door de programmeur is dan wel minder proper :)

Dat spreekt elkaar tegen: het is geen bad design van de taal om de feature erin te steken volgens u maar de programmeur mag de feature niet gebruiken van u? Een feature die beter niet gebruikt kan worden is een feature die er beter niet in was gestoken.

Emerxill

Legacy Member
NeverwinterX zei:
Dat spreekt elkaar tegen: het is geen bad design van de taal om de feature erin te steken volgens u maar de programmeur mag de feature niet gebruiken van u? Een feature die beter niet gebruikt kan worden is een feature die er beter niet in was gestoken.
Een static variable aanspreken via de instance opzich is geen bad design, het zal niet leiden tot fouten in uw code. De klasse variable zal zich hetzelfde gedragen...

Je doet dat beter niet omdat je code dan minder duidelijk wordt, maw het is dan niet duidelijk dat je met een klasse-variable aan't werken bent. En dat kan leiden tot bad design/code dat zich anders gedraagt dan verwacht. Maar dat heeft meer te maken met het feit dat de developer zich niet bewust is dat hij met een klasse-variable aan't werken is, maar met de werkwijze op zich is niks mis.

NeverwinterX

Legacy Member
Emerxill zei:
Een static variable aanspreken via de instance opzich is geen bad design, het zal niet leiden tot fouten in uw code. De klasse variable zal zich hetzelfde gedragen...

Je doet dat beter niet omdat je code dan minder duidelijk wordt, maw het is dan niet duidelijk dat je met een klasse-variable aan't werken bent. En dat kan leiden tot bad design/code dat zich anders gedraagt dan verwacht. Maar dat heeft meer te maken met het feit dat de developer zich niet bewust is dat hij met een klasse-variable aan't werken is, maar met de werkwijze op zich is niks mis.

Ik denk dat je bad design van de programmeertaal verkeerd verstaat: bad design van de programmeertaal wilt zeggen dat diegenen die de programmeertaal zelf ontwikkeld hebben een verkeerde keuze hebben gemaakt.
En voorts zal bad design (of het nu in de programmeertaal zelf is of in uw eigen code) niet leiden tot fouten in uw code, het is slecht/onhandig/niet-uitbreidbaar... om te gebruiken. Er is een verschil tussen bad design en niet-correct-werkend (een bug).

Emerxill

Legacy Member
NeverwinterX zei:
Ik denk dat je bad design van de programmeertaal verkeerd verstaat: bad design van de programmeertaal wilt zeggen dat diegenen die de programmeertaal zelf ontwikkeld hebben een verkeerde keuze hebben gemaakt.
En voorts zal bad design (of het nu in de programmeertaal zelf is of in uw eigen code) niet leiden tot fouten in uw code, het is slecht/onhandig/niet-uitbreidbaar... om te gebruiken. Er is een verschil tussen bad design en niet-correct-werkend (een bug).
Nee, "bad design" zal niet leiden tot fouten in de code :ironic:...
Als je dan toch een definitie wil geven doe het dan juist :p. Bad design is:
- moeilijk aanpasbare code omdat het impact heeft op andere onderdelen van de code.Is dat van toepassing op een static? Neen.
- als je toch aanpassingen doet dat op bepaalde plaatsen fouten veroorzaakt (daar doelde ik op btw ;) ). Is dat van toepassing op een static? Neen
- moeilijk te hergebruiken. Is dat van toepassing op een static? Neen, integendeel zelfs.

Geen bad design dus.

Cycloon

Legacy Member
Inderdaad. Static op zich heeft totaal niks met bad design of whatsoever te maken. Zelf de manier hoe je die static oproept is irrelevant. Wat wél relevant is hoe je die dingen gaat gebruiken in een groter geheel en wat de 'conventies' zijn binnen het bedrijf.

NeverwinterX

Legacy Member
Emerxill zei:
Nee, "bad design" zal niet leiden tot fouten in de code :ironic:...
Als je dan toch een definitie wil geven doe het dan juist :p. Bad design is:
- moeilijk aanpasbare code omdat het impact heeft op andere onderdelen van de code.Is dat van toepassing op een static? Neen.
- als je toch aanpassingen doet dat op bepaalde plaatsen fouten veroorzaakt (daar doelde ik op btw ;) ). Is dat van toepassing op een static? Neen
- moeilijk te hergebruiken. Is dat van toepassing op een static? Neen, integendeel zelfs.

Geen bad design dus.

Je begrijpt het nog steeds niet: je denkt nog steeds teveel op het niveau van de code zelf over het gebruik van de static op een instance method, ik zeg dat ik het over het uitdenken van de programmeertaal zelf heb. En op dat niveau is de beslissing om static toe te laten op instanties in de syntax bad design. Uw begrip van design is veel te nauw en beperkt. Bad design bevat veel meer dan moeilijk aanpasbare code of moeilijk te hergebruiken, ook conceptueel fout ontwerp (i.e. wat design betekent) valt onder bad design.

Het feit dat je zelf zegt (en zowat alle compilers en IDE's) dat programmeurs beter geen static methode oproepen op een instantie omdat dat onduidelijk code geeft, geeft aan dat het bijvoorbeeld voor Java van James Gosling en co een verkeerde beslissing was om C++ te volgen en die syntax toe te laten. Als uw programmeertaal dingen toe laat die de programeur beter niet doet, dan is uw programmeertaal slecht ontworpen op dat punt en dat noemt bad design ja. C# laat het bijvoorbeeld niet toe.

Emerxill

Legacy Member
NeverwinterX zei:
Je begrijpt het nog steeds niet
Ik begrijp het maar al te goed, duidelijk beter dan jij.. Kan ik er niet aan doen dat begrijpend lezen niet uw sterkste kant is.

Indien je goed gelezen zou hebben, had je duidelijk kunnen lezen dat in één van mijn eerste reacties hierop ik aanhaal dat een static conceptueel deel uitmaakt van de instance als van de klasse.

Als de ontwerpers van bijv C# daar anders over denken is dat hun keuze. En dat heeft wrsch meer te maken omdat ze goed beseffen wat het doelpubliek voor C# is (sorry kon het niet laten :p).
Maar ik herhaal, (tot vervelens toe) het toegankelijk maken van een static vanaf de instance is géén bad design. Het zal nooit rechtstreeks de oorzaak zijn van slecht werkende code.

Voor je mij verwijt dat mijn begrip over bepaalde concepten te nauw en beperkt is, kun je best zelf zien dat je het algemeen beeld en de redenering achter bepaalde keuzes bij het ontwerpen van Java juist snapt en niet te eng is, net als de betekenis van "bad design" (dat je dan weer te ruim interpreteert om een reden dat mij vreemd is).

NeverwinterX

Legacy Member
Emerxill zei:
Ik begrijp het maar al te goed, duidelijk beter dan jij.. Kan ik er niet aan doen dat begrijpend lezen niet uw sterkste kant is.

Indien je goed gelezen zou hebben, had je duidelijk kunnen lezen dat in één van mijn eerste reacties hierop ik aanhaal dat een static conceptueel deel uitmaakt van de instance als van de klasse.

Je posts daarna geven anders totaal niet aan dat je het werkelijk snapt:
"moeilijk aanpasbare code omdat het impact heeft op andere onderdelen van de code.Is dat van toepassing op een static? Neen."
Die opmerking houdt geen steek als je werkelijk begrijpt dat ik het over de programmeertaal heb: het heeft helemaal niks te maken met aanpasbare code want het gaat namelijk over de programmeertaal op zichzelf, aanpasbare code komt daar op dat niveau niet eens bij kijken. Analoog voor de andere opmerkingen. Jij hebt het zeer specifiek over "object oriented design bij het schrijven van software", ik heb het over design in het algemeen, meer specifiek over het design van de programmeertaal zelf.

Voorts maakt een static er conceptueel geen deel van uit:
Een static hoort bij de klasse. Een klasse is een omschrijving van het gedrag/inhoud van de instanties van die klasse. De hond blackie is een instantie van de soort hond. Maar de hond blackie is geen soort. Een klasse is een metaniveau boven de instantie.

Neem de klasse Color uit de Java API:
Er zijn static variabelen voor rood, groen, blauw etc. Die horen bij de klasse Color. Volgens jou horen ze ook bij de instanties van de klasse Color.
Code:
Color red = new Color(1, 0, 0);
blabla = red.GREEN;
Is dus volstrekt logisch en conceptueel geheel correct voor jou: want groen hoort ook bij rood voor jou.

Het had minder moeite gekost om die feature er niet in te steken want het vraagt meer werk achterliggend: je moet de class van de instantie waar je de static oproept van opvragen en daarop dan de static oproepen. Je hebt er ook geen baat bij: als je de feature zou weglaten, zou je niks verliezen: Color.GREEN kan je perfect schrijven. Het is ook niet korter om het te schrijven met de instantie. Bovendien is het conceptueel verkeerd en leidt het tot verwarrende code.
Elke feature in een programmeertaal moet je kunnen verantwoorden met een reden, als die reden er niet is dan cut je de feature er beter uit.
"– A clear semantic model greatly boosts readability
– Every 'good' feature adds more 'bad' weight
– Sometimes it is best to leave things out"
- Evolving the Java Language - M. Reinhold/J. Darcy

Emerxill zei:
Als de ontwerpers van bijv C# daar anders over denken is dat hun keuze. En dat heeft wrsch meer te maken omdat ze goed beseffen wat het doelpubliek voor C# is (sorry kon het niet laten :p).

Kinderachtig.

Emerxill zei:
Maar ik herhaal, (tot vervelens toe) het toegankelijk maken van een static vanaf de instance is géén bad design. Het zal nooit rechtstreeks de oorzaak zijn van slecht werkende code.

Opnieuw geef je blijk van een slecht begrip van wat design is. Design op zich heeft niks te maken met het al dan niet werken van uw code.

Emerxill zei:
Voor je mij verwijt dat mijn begrip over bepaalde concepten te nauw en beperkt is, kun je best zelf zien dat je het algemeen beeld en de redenering achter bepaalde keuzes bij het ontwerpen van Java juist snapt en niet te eng is, net als de betekenis van "bad design" (dat je dan weer te ruim interpreteert om een reden dat mij vreemd is).

Design - Wikipedia, the free encyclopedia

"Design emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation. Ultimately, designs can be implemented and the implementation (such as code) expresses the true and complete realized design" - Larman

“Design is that area of human experience, skill and knowledge which is concerned with man’s ability to mould his environment to suit his material and spiritual needs.” - Archer

Jij interpreteert design bijlange niet ruim genoeg.

Edit:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Oh kijk nog iemand die het heeft over bad design van een programmeertaal.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan