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

).
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.