I'm firmly with Kent here: OO programming is not about simulation. You
are not modeling real world items. You are making code easier to
maintain and making parts of code that have to do with one another be
near one another.
If you spend all your time trying to make your objects into real world
things you're actually doing simulation, not programming. As a person
who's actually done simulation, I'll state that 's not really a great
way to structure code. You spend a lot of time arguing about highly
abstract responsibilities of each object in your system, as well as
how much it will actually model the real world. Neither one is
especially helpful, as neither one is addressing the Why of OO
programing. The Why of OO programming today is: To make code more
maintainable/usable and to group and to use data in such a way the
human mind can easily grasp all the abstract data types that a program
operates on.
OO programing came from simulation people. They used a language
(Simula) to do simulation. It allowed each object to have behavior
linked to its type. They were simulating combat and needed to model
the behaviors of all the objects (ships) when they all interacted
together.
Other people saw this (Smalltalk), then copied the system (which they
were incidentally using to build Smalltalk at first), but not to
simulate real world objects, but to instead better group functions
with the data that those functions operate on. Objects could be
created on the fly in there system. They first coined the term "Object
Oriented Programming". They real novel thing they did with all of this
was to build the first windowing GUI's and mice into a programming
language. They were not modeling anything in the real world, they were
putting all the components and methods pertaining to building a little
square on the screen into a class, or all the methods pertaining to a
mouse input into a class.
When Bjarne Stroustrup made C++, he copied some of the ideas in order
to make a better type system, where the functions that operated on a
type were put together with the data into an abstract data type by his
preprocessor (C++ was a preprocessor for many years before it was a
compiler). In his own words:
"Object-oriented programming is programming using inheritance. Data
abstraction is programming using user-defined types. With few
exceptions, object-oriented programming can and ought to be a superset
of data abstraction."
The key feature of object is *that you make types* (and you put the
methods with the type, as part of the type). That you can do
polymorphism. Etc.
OO is not a glorified simulation system, and you will feel pain if you
overemphasize the generalization "Model objects on real world
objects". Objects do have to have an idea (Cohesion). It is just, that
idea doesn't have to be congruous with something you can walk over to
and pick up in the real world.
Often it feels like the "Model objects on real world objects" is how
people are taught so they get the idea of an object. Actually
designing all code that way is a needless proscription that really
really hurts many projects.
--Michael
On Fri, Feb 15, 2008 at 8:38 AM, Kent Johnson <[EMAIL PROTECTED]> wrote:
> Tiger12506 wrote:
>
> > I like things to be explicit, and don't care for the level of
> > abstraction common in MVC. I know it seems naive, but I like to be able to
> > model object designs after tangible things, and to me, a View does not know
> > how to keep a state or execute methods because it does not exist. A
> > Controller does not exist alone of the model, and without the view it fails
> > to work.
>
> I agree that this is a naive view, for the same reason I objected to
> Alan's "find the nouns" approach to OO design. For me considerations of
> cohesion, encapsulation, DRY, testability, and any required reuse or
> flexibility are far more important to design than correspondence with
> tangible objects.
>
> Kent
>
>
> _______________________________________________
> Tutor maillist - Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor
>
--
Michael Langford
Phone: 404-386-0495
Consulting: http://www.RowdyLabs.com
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
