This content has been marked as final. Show 4 replies
I can only suppose that you haven't had the opportunity to work on a large system that involves tens of developers where multiple systems/apps exist and where multiple people are required to work on the same system.
Imagine if you will that your 'example' required 10 people to finish it on time and so there were 10 people all trying to work on and test a single method at once.
but on the other hand it's a waste of time on designStudies have shown that between application costs are between 100% up to at least 900% incurred during maintenance. So creating the initial application so it is easier to maintain can have a huge cost savings.
I believe other studies have shown that it easier to understand some problems versus large ones. So if the database code is in its own class and the bug that I must fix is a database bug then I don't need to figure out what 10,000 lines of other code is doing. Again this impacts maintenance.
OOP is one technology in the last 50 years that has been an overwhelming success. New 'technologies' come allow all the time (many per year) and almost all fail or have so few real use cases that they can be ignored. But not OOP. Given that vast acceptance of that versus the vast rejection of so many others it would suggest that OOP overall is very useful in the vast majority of cases.
Also is OOP your first programming paradigm? If not and you are used to a procedural language (C, Basic, etc) then getting to the point where you understand OOP takes time. It took me at least two years to start to grasp it.
In my experience, the solutions that seem so quick and easy in the beginning often rapidly become more and more complex as you add new functionality; good OO design and frequent refactoring will keep your application simple and flexible. Taking a little more time to create a more flexible solition will pay off as your application grows.
I do agree that it takes time to learn OO.
For as far as using up machine resources: premature optimizations is the root of all evil ... Or, a bit less harsh: don't worry about performance too much, rather worry about flexibility and readability, and use profiling and stress testing to optimize for performance.
892665 wrote:If you feel it's a waste of your time to do it that way, and you can create software that meets your requirements more quickly and more simply without using OOP, and if you're not working with a team who feel otherwise, then don't use OOP. It was never intended to be a panacea.
it's a waste of time on design (i experience a lot of problems solving simple stuff while putting them into oop style) and obviously a waste of machine resources.
As for wasting machine resource, no, it is certainly not "obvious" that this is the case. You definition of "waste" appears to be "using any more than the bare minimum necessary to accomplish the job." And by that definition, anything higher level than assembly is a waste. Computers are cheaper than the programmers that make them work. If it takes more CPU cycles and more RAM to execute a program because of the overhead of whatever higher-level programming constructs were used, but that program is easier for humans to develop, test, debug, maintain, and enhance than it would have been using lower-level constructs, then that's not a waste; it's resources well spent.