For what it’s worth, in my experience about the only different between OOP and old-school structured imperative programming is that OOP design revolves around semi-atomic, opaque chunks of data, with limited sets of operations that are allowed on a given type of data. In contrast, non-OOP imperative programming typically revolves around a hierarchical breakdown of the task into subtasks implemented as procedures, which the programmer invokes sequentially and passes smallish, transparent bits of data to.
The two are essentially isomorphic, but one or the other may be more natural depending on how well your problem domain decomposes into either 1) a series of subtasks or 2) a collection of self-contained data with a limited range of sensible actions.
For instance, procedures like C’s standard string functions would be more natural in an OOP system because they define a limited set of sensible operations on a fragile data structure, whereas things like Singleton objects and static methods in OOP languages are a hack for things that are more sensibly non-OOP.
Most other details about OOP (like inheritance) will inspire more religious wars than anything else.
OOP proponents usually claim that structured programming projects become too complex for any individual or group to manage at around 100,000 lines of code, but the only references my Google-fu was able to dig up for that claim are twenty-some years out of date:
C. Jones, Programming Productivity, McGraw-Hill, New York, New York, 1986.
C. Jones, Editor, Tutorial Programming Productivity: Issues for The Eighties, Second Edition, IEEE Catalog No. EHO239-4, IEEE Computer Society Press, Washington, DC, 1986.
For what it’s worth, in my experience about the only different between OOP and old-school structured imperative programming is that OOP design revolves around semi-atomic, opaque chunks of data, with limited sets of operations that are allowed on a given type of data. In contrast, non-OOP imperative programming typically revolves around a hierarchical breakdown of the task into subtasks implemented as procedures, which the programmer invokes sequentially and passes smallish, transparent bits of data to.
The two are essentially isomorphic, but one or the other may be more natural depending on how well your problem domain decomposes into either 1) a series of subtasks or 2) a collection of self-contained data with a limited range of sensible actions.
For instance, procedures like C’s standard string functions would be more natural in an OOP system because they define a limited set of sensible operations on a fragile data structure, whereas things like Singleton objects and static methods in OOP languages are a hack for things that are more sensibly non-OOP.
Most other details about OOP (like inheritance) will inspire more religious wars than anything else.
OOP proponents usually claim that structured programming projects become too complex for any individual or group to manage at around 100,000 lines of code, but the only references my Google-fu was able to dig up for that claim are twenty-some years out of date:
C. Jones, Programming Productivity, McGraw-Hill, New York, New York, 1986.
C. Jones, Editor, Tutorial Programming Productivity: Issues for The Eighties, Second Edition, IEEE Catalog No. EHO239-4, IEEE Computer Society Press, Washington, DC, 1986.