encapsulation VS development time
-
I was looking back at my first worthwhile project and I notices that I made a more than a few functions to separate my code as it was getting cramped. While it seems to do the job, it is harder to maintain and is far from the ideals of Object-Oriented Programming (OOP), especially the encapsulation aspect ! Refactoring the code seems attractive but the time expenditure doesn't seem to outweigh the advantages I'd have from fast maintenance and portability as it seems too project-specific. However, I'm looking for a general guideline so that I may approach the solution from a more distanced point of view.
Je vous salue du Québec !
-
I was looking back at my first worthwhile project and I notices that I made a more than a few functions to separate my code as it was getting cramped. While it seems to do the job, it is harder to maintain and is far from the ideals of Object-Oriented Programming (OOP), especially the encapsulation aspect ! Refactoring the code seems attractive but the time expenditure doesn't seem to outweigh the advantages I'd have from fast maintenance and portability as it seems too project-specific. However, I'm looking for a general guideline so that I may approach the solution from a more distanced point of view.
Je vous salue du Québec !
DynV wrote:
I'm looking for a general guideline
I have no experience with OOP effecting portability. That said, any decent (means not lousy) OO design that has minimal documentation is far easier to maintain/extend than spaghetti code. Furthermore any decent organized/structured non OO design that has minimal documentation is far easier to maintain ( extending might be different) than spaghetti code. For me the bottom line is, if you are at all suspicious about frequent requirements to "extend" the system OO is the way to go.
-
I was looking back at my first worthwhile project and I notices that I made a more than a few functions to separate my code as it was getting cramped. While it seems to do the job, it is harder to maintain and is far from the ideals of Object-Oriented Programming (OOP), especially the encapsulation aspect ! Refactoring the code seems attractive but the time expenditure doesn't seem to outweigh the advantages I'd have from fast maintenance and portability as it seems too project-specific. However, I'm looking for a general guideline so that I may approach the solution from a more distanced point of view.
Je vous salue du Québec !
If it's a persuading management thing then I'd always argue that if I left and someone else had to look after the code then it would be easier and more cost-effective with regards to training and hand-over for it to be written in a proper OO way. I'd also always argue that something written well is always easier to extend later on if needed, whereas something that isn't is more likely to cause problems later on. That last argument is always easier to argue if the system hasn't been running without problems for a while.