Monday, 21 February 2011

Abstracting

==========
Code Complete (Steve McConnell)
- Highlight Loc. 5558-63  | Added on Thursday, February 17, 2011, 06:27 AM

On programming projects, the abstractions are not ready-made the way Shape is, so we have to work harder to come up with clean abstractions. The process of distilling abstract concepts from real-world entities is non-deterministic, and different designers will abstract out different generalities. If we didn't know about geometric shapes like circles, squares and triangles, for example, we might come up with more unusual shapes like squash shape, rutabaga shape, and Pontiac Aztek shape. Coming up with appropriate abstract objects is one of the major challenges in object-oriented design.
==========

Your abstractions need to model the domain accurately. I worked on a project where the abstractions didn't model the domain correctly, and it caused us terrible problems. It was a blotter application used in a bank for Credit Default Swaps. When we added new functionality to handle unwinds, we didn't understand that an unwind was an event on an existing deal. In our abstraction, we modelled the unwind as a separate deal.

As we came to understand the business better we realized that we had painted ourselves into a corner. It made adding new functionality incredibly frustrating and difficult, with really convoluted code required to bridge the gap between our model and reality.

If your map doesn't accurately represent the territory, you will either take longer to reach your destination, or lose your way entirely.

No comments:

Post a Comment