![]() |
Show Changes |
![]() |
Edit |
![]() |
|
![]() |
Recent Changes |
![]() |
Subscriptions |
![]() |
Lost and Found |
![]() |
Find References |
![]() |
Rename |
![]() |
Administration Page |
![]() |
Topic Locks |
| Search |
History
| 4/24/2008 11:04:11 PM |
| 60.48.224.6 |
| 11/16/2007 3:07:23 PM |
| 72.44.57.149 |
| 11/16/2007 3:06:29 PM |
| 72.44.57.149 |
| 11/16/2007 3:06:10 PM |
| 72.44.57.149 |
| 11/16/2007 3:05:42 PM |
| 72.44.57.149 |
![]() |
List all versions |
Why bother with objects and components at all? The purpose of objects is to provide encapsulation and implementation reuse. With code generation, we reuse the requirement or design and not the code. It doesn’t matter if code gets duplicated and spread about because a human won’t be maintaining it. Objects and components are a human artefact for versioning and managing work among developers. They exist to help us humans deal with software complexity. Let’s use computers to deal with software complexity instead.
Object-oriented middle-tiers are generally terrible because they normalise your access to the data you want and create massive inefficiencies. For example, you may only want to access one property of an object but most systems will make you retrieve all the properties of the object in order to avoid an explosion of combinatorics. This creates a massive waste of data access and memory allocations.
Using a computer to search and calculate all the data interdependencies and optimise data access means we can get radically better performance than a hand-crafted object-oriented middle-tier. Worrying about object design is like worrying about which register gets used on a microprocessor!