Dankjewel voor de link Wouter. Ik heb de tekst een beetje geskimmed ;) Wat ik vooral bedoel is... stel je hebt een class... en je komt er ineens een paar maanden later achter dat er een clas property in hoort te zitten, dan moet je die class aanpassen. Of je besluit dat iets handiger kan. Ik vind dat er soms zo'n ophef wordt gemaakt dat je een class niet mag aanpassen.
Ozzie, het is niet dat je een klasse niet mag aanpassen. Als je dat uit het skimmen hebt gehaald kun je niet skimmen en raad ik je aan het artikel maar eens helemaal te lezen.
De definitie van het Single Responsibility Principle (SRP): A class should have only one reason to change Er mag maar 1 rede zijn om een klasse aan te passen, een klasse mag maar 1 role hebben. Als je 2 reden hebt, bijv het veranderen van de opslag methode en het veranderen van hoe de data wordt getoond dan doe je iets verkeerd en moet je je klasse opsplitsen, net zolang je maar 1 rede kunt bedenken.
>> Ozzie, het is niet dat je een klasse niet mag aanpassen. Als je dat uit het skimmen hebt gehaald kun je niet skimmen en raad ik je aan het artikel maar eens helemaal te lezen.
Eeejj... jongeh! Niet zo agressief he! BAM!! Verrekte mongol!!
Hehehe ;-)))
Dat was niet wat ik bedoel. Er wordt in het algemeen altijd zo magisch gedaan over het aanpassen van een class. Op een manier van... als de class eenmaal klaar is, dan mag je er eigenlijk niet meer aankomen. Dat is wat ik bedoel.
Dan heb je dat tot nu toe verkeerd begrepen, ik heb daar namelijk nog nooit van gehoord. Steker nog, als je kijkt naar het aantal communities rond open source projecten en wat daar per dag veranderd gebeurd er juist het tegenovergestelde. Elke dag worden honderden dingen verbeterd, toegevoegd en gefixed.
Het probleem is echter dat zodra je 1.0.0 heb uitgegeven, je rekening moet gaan houden met backwards compatibility. Je kunt niet zomaar je public API(classes, methods en properties die gebruikt kunnen worden als je de library gebruik) gaan aanpassen, aangezien alle gebruikers van jouw library dan hun code moeten gaan aanpassen. Wanneer ze updaten naar 1.1.0 bijv. Daarom is er het zogenaamde Semantic Versioning uitgevonden, een standaard die aangeeft dat je alleen grote BC breaks (refactorings van de public API) mag doen wanneer je van 1.x naar 2.x gaat (de zogeheten major version update). Bi de minor version (bijv. 1.0.x naar 1.1.x) mag je alleen nieuwe features toevoegen en de release version (1.0.0 naar 1.0.1) mag alleen bugs fixen.
Dat was niet wat ik bedoel. Er wordt in het algemeen altijd zo magisch gedaan over het aanpassen van een class. Op een manier van... als de class eenmaal klaar is, dan mag je er eigenlijk niet meer aankomen. Dat is wat ik bedoel.
Maar wat Wouter al aangeeft, het heeft vooral te maken met het Backward compatible houden van je API. Alles wat je aanpast moet de oude situatie in stand houden, de bestaande implementatie moet blijven werken... :)
