behaviour vs. data first
in [OOP]
|
Prev: Informatics 2010: 1st call extension - 30 April 2010
Next: The Eiffel Compiler tecomp version 0.22 released
From: raould on 9 Apr 2010 18:25 hi, "The Structure and Interpretation of the Computer Science Curriculum" http://www.ccs.neu.edu/scheme/pubs/jfp2004-fffk.pdf the way i read it claims that OO starts with data, but i was under the impression that at least some self-labeled OO approaches start with behaviour, roles, interfaces, and such. furthermore, i thought even non-OO approaches often start by working out interfaces rather than a data structure. ?
From: Dmitry A. Kazakov on 10 Apr 2010 03:01 On Fri, 9 Apr 2010 15:25:17 -0700 (PDT), raould wrote: > "The Structure and Interpretation of the Computer Science Curriculum" > http://www.ccs.neu.edu/scheme/pubs/jfp2004-fffk.pdf > > the way i read it claims that OO starts with data, but i was under the > impression that at least some self-labeled OO approaches start with > behaviour, roles, interfaces, and such. From the paper: "A functional programmer begins with the definition of types and then defines functions on these types. An object-oriented programmer defines classes and adds methods to these classes." As if they were unaware that class is a type and method and function is same. The paper perfectly illustrates lack of connection between education and industrial software development. > furthermore, i thought even > non-OO approaches often start by working out interfaces rather than a > data structure. I think this is one of the problems with education. We work out interfaces, because speaking more generally, we design each program in general, assuming its components rather generic than applied to a concrete case. So, the term behavior, an envisage rather than a rigid data construct. So, a radically different way of software decomposition. This is the key factor in software design, which allows to accommodate to various changes during the program life-time (requirements drift, bug fixes, optimizations). All OOPL are designed to support this kind of generic programming. How to teach students generic programming, when they do not yet understand just programming? That is the real challenge, not even mentioned in the paper. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Daniel T. on 10 Apr 2010 08:30 raould <raould(a)gmail.com> wrote: > "The Structure and Interpretation of the Computer Science Curriculum" > http://www.ccs.neu.edu/scheme/pubs/jfp2004-fffk.pdf > > the way i read it claims that OO starts with data, but i was under the > impression that at least some self-labeled OO approaches start with > behaviour, roles, interfaces, and such. furthermore, i thought even > non-OO approaches often start by working out interfaces rather than a > data structure. After a quick skim of the references to "object-oriented" in the paper, I think you are correct that it seems to confuse OO with relational databases.
From: raould on 10 Apr 2010 18:12 On Apr 10, 9:30 am, r...(a)zedat.fu-berlin.de (Stefan Ram) wrote: > When you call a selector (method, function, member) of an > interface, it often will accept arguments, and each of these > arguments designates a value, and values I deem to be »data«. > So can one explain interfaces without also speaking of data? dunno if you read the paper, but my interpretation was that they are not defining the types, they are defining the actual internals of the records, which is a different thing. you can define apis with types, without knowing what the internal details of those types are. sincerely.
From: Daniel T. on 10 Apr 2010 20:01
ram(a)zedat.fu-berlin.de (Stefan Ram) wrote: > raould <raould(a)gmail.com> writes: > > > the way i read it claims that OO starts with data, but i was under the > > impression that at least some self-labeled OO approaches start with > > behaviour, roles, interfaces, and such. furthermore, i thought even > > non-OO approaches often start by working out interfaces rather than a > > data structure. > > When you call a selector (method, function, member) of an > interface, it often will accept arguments, and each of these > arguments designates a value, and values I deem to be �data�. The arguments designate interfaces (types,) not values. |