Re: OOP/OOD Philosophy

> >> OOD helps you to organize and represents the information. All people
> >> makes a mental design to resolve a problem and then programs the
> >> solution. In OO terms one first designs an OO solution and then programs
> >> it in an OO language (or not :) ).
> >
> > But non-OOD is also design. Non-OOD focuses more on deriving the
> > algorithms, while OOD focuses more on the data, although the two
> > intersect. One can derive data from the algorithms/relations and vice
> > versa. So, given two different ways of doing something, and a former
> > way that is clearer and more direct, why use the latter? If it's an
> > issue of flexibility/re-usability, what's the thinking behind that?
>
> Really, the goal is not so much to reuse things as to seperate the things
> that change a different times, to make them easier to change. We start with
> the limitations of people and create languages that those people can use.
> If you watch the evolution away from OO and towards things like AOP and
> lightweight frameworks, it is part of an ongoing process towards the
> seperation of "things that change rarely" from "things that change
> frequently."
>
> The obvious first efforts were the function libraries that would come with a
> language. We all knew that there had to be a way to produce the square root
> of a number. That mechanism is older than computer science (although many
> implementations exist). The fundamental definition doesn't change very
> often so it is easy to place something like SQRT() in a math library and be
> assured of its longetivity. That's procedural.
>
> What OO gave us was a way to abstract that thinking a bit more... to look at
> the activities of our applications and find those activities that are,
> themselves, fundamental and rarely changing. If we allow those activities
> to operate on interfaces, and not on actual items, we can seperate these
> fundamental activities (rarely changing) from the implemented objects
> (frequently changing).

In my domain one often cannot know ahead of time what will change. In
physics, chemistry, etc., one may be able to determine such because God
does not change the laws of physics very often, but not in most of the
business and intellectual property domains where the rules are set by
(seemingly) capricious managers, marketers, owners, and lawmakers.
Interfaces need tweaking as often as implementation.

I too seek techniques that are change-friendly; but OO does not appear
to fit that bill. Maybe if one sticks in enough indirection it might,
but then you are batteling layers and layers of interfaces that are
uglier than being closer to the implementation would be.

-T-

.

Loading