Weblogs Forum - Teaching OO: Putting the Object back into OOD

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Teaching OO: Putting the Object back into OOD

27 replies on 2 pages. Most recent reply: Mar 14, 2006 7:32 PM by Urvashi Kaul

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 27 replies on 2 pages [ « | 1 2 ]

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: Teaching OO: Putting the Object back into OOD

Posted: Sep 11, 2003 9:18 AM

I agree with Trygve that the software conceptual model is important. This is what I was referring to when I invoked Brenda Laurel's insight that human engagement with software goes all the way to the structure. And Kent Beck has often said that bad structure shows all the way through to the human interface. And I agree that these are issues of conceptual models. I think you often use a popular word processor from Redmond, Washington as an example of how not to do things.

I will be giving a seminar on human/computer interface design in the Winter term here at North Central College. Don Norman's stuff is cool, and fun, but if you want something profound, thought-provoking and a bit more directly applicable to everyday software design tasks, read Jef Raskin's stuff. I think it underscores most of your points, and it will probably be my main text for the seminar. There is one point you made that I'd ask you toreconsider with respect to Raskin's view, and that is correctness. I'd agree with you that correctness were important if we could know what "correct" is. Design is about meeting wants; for us to conclude that they are needs is to overstep the ethics of design. Correctness, which begs a formal tie to our projection of users' mental models of the systems they are building, is out of line. Not all human psychology is formal or provable, but it is that psychology we aspire to serve. Our users are not automota.

Sam Griffith Jr.

Posts: 9
Nickname: staypufd
Registered: Sep, 2003

Re: Teaching OO: Putting the Object back into OOD

Posted: Sep 18, 2003 11:46 AM

Loved the article. I've come to many of the same conclusions over the years since 1986 when I first was exposed to OO development via Smalltalk.

It is nice to see the we are going back to the basics with this discussion of what we are really modeling. Instances and what roles they play at different times in their lifetimes. When viewed from different perspectives, they can be seen as class descriptions, role players, components, collaborators, function implementations, etc. Some are data centric, some are behavioral, some are controllers, some are monitors, etc. All are roles,... yet each has some state, may exist in a class heirarchy, or delegate cluster, etc.

Knowing all that, I like to recommend people learn a fully dynamic language and also a prototypical OO language as well. With that, we can create prototypes that play these roles, work together to implement the required functions and then later on cluster them in to classes and heirarchies. It also lets them model their systems in code exactly like you would do with the CRC instance you mention you hold up in the air.

When I teach design, I also focus my students on composition of instances and on Collaborations diagrams. I do that to stress instances and that the objects are working together and the roles they play. I find that that steers them towards better solutions than focusing on class diagrams and sequence diagrams.

It is also at this point that I find some students want to talk about those roles and interfaces, how they relate and do they relate to class vs. type issues. This also helps to clarify the idea that a role isn't a class and that interfaces are not types either. We then can discuse type vs. role. Type being a structural idea and roles being a behavioral idea. One example that may be given is that a man is a type of mammal, but a man plays a role of a cop at work and dad at home. His genetic structure doesn't change to be a different type, but his role does change in those different situations.

Anyway, to all who've posted before this and to James and Trygve thanks for the great reads in your books and papers and now this weblog.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Teaching OO: Putting the Object back into OOD

Posted: Sep 22, 2003 10:52 PM

There are some key things that are hard to wrap ones head around related to having implementations of something, but not classes in an OO world. In Java, interfaces feel like roles because while they are codified in the Class definition, they can also be added later via the java.lang.reflect.Proxy class. You can augment a class with a completely new role without it having been there to begin with.
<p>
However, this is not trivial. I am not sure whether it could be trivial to add a role as complex as some might contemplate. The ObjectSpace (now owned by Recursion Software) Voyager (java based) product, used/uses the terminology Facet to talk about dynamic changes to a class. You can add a Facet to an object and get a new object that works with 'instanceof' etc. They did a lot of introspection, and then wrote new bytecodes to dynamically compile a new object that included everything from the old object plus the new Facet information.
<p>
With this system, you get type safe objects, but still have infinite expansibility. Their examples are things like an HR system where people's titles, names, offices etc change, and the object needs to have the new/changed information attached. You could use a RDB and have a bunch of null columns. But, why not just have objects that have roles already defined, as you have suggested.
<p>
I'm a java fan, but I recognize some of the efforts going on in other languages. Alas I've also written a blog about my dislike of similar languages playing keepup.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Teaching OO: Putting the Object back into OOD

Posted: Nov 18, 2003 10:20 AM

> The realization of functions and sub-functions can
> conveniently be discussed with CRC cards. CRC cards are
> all about what objects *do* rather than about what they
> *are*. In fact, they look more like roles than like
> classes! (In my book, I said that "The CRC technique
> supports role modelling directly, since both focus on
> object responsibility and object interaction." I even
> considered renaming them RRC-cards, but thought this
> would be going too far out.)

Rebecca Wirfs-Brock bit-the-bullet:
Object Design: Roles, Responsibilities, and Collaborations

http://www.wirfs-brock.com/pages/resources.html

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Teaching OO: Putting the Object back into OOD

Posted: Nov 18, 2003 10:42 AM

> I will be giving a seminar on human/computer interface
> design in the Winter term here at North Central College.
> Don Norman's stuff is cool, and fun, but if you want
> something profound, thought-provoking and a bit more
> directly applicable to everyday software design tasks,
> read Jef Raskin's stuff.

design with scenarios and personas
Alan Cooper http://www.cooper.com/

uses-cases split responsibilities between system and user too soon, maybe task descriptions are a better place to start
Soren Lauesen http://www.itu.dk/people/slauesen/Papers/IEEEtasks.pdf

Eugene Coetzee

Posts: 1
Nickname: fadtired
Registered: Apr, 2004

Nice article...but

Posted: Apr 5, 2004 4:34 AM

Good article - but the more I read statements like : "We start to reduce complexity by grouping objects together into classes, which is in accordance with how most popular programming languages work.", the more I suspect that most of OO is "problematic" because we are doing it wrong and there is a fundamental misundertanding of OO languages.

Good OO starts with classes with their analogies as objects in the real world. Classes are not an afterthought or a way of capturing "simularities amongst different objects" How - prey thee, can an object be instantiated when there is no class definition for the object?

I don't really comprehend the distinction between a class and an object - and I probably never will. To me an object is an instantiation of a class. Period.

I suspect that there is also lot of confusion about interfaces, ABC's (abstract base classes) and what inheritance should be used for.

Dario Louzado

Posts: 1
Nickname: dlouzado
Registered: Apr, 2004

Re: Teaching OO: Putting the Object back into OOD

Posted: Apr 20, 2004 11:56 AM

Managers, using RUP devived processes, tend to control the way work is divided into smaller peaces. Use cases drive work partitioning. Ops... Function drives the structure.

This way, it will never be possible to scale organizations into multi-site development (in the spirit of "Organization Follows Location" org pattern).

This way, managers controls the development process (instead of developers). Also, architects does not have an active role on product control in this scenario.

Knowing OO core-concepts is fundamental to change this situation, putting the development process on the right hands(developers´) and enabling product control by the architects.

Very interesting article Coplien!

[]s

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: Nice article...but

Posted: May 4, 2004 5:06 PM

I would agree that there is a fundamental misunderstanding of programming languages.

I also think there are two schools of thought, and that there is an interesting tension between those schools of thought, and that your question relates to that dichotomy. As it turns out, the article also relates to that dichotomy but in a way that is perhaps not obvious. One is the inductive school: starting with particulars and generalizing. That school dominates the use case perspective. You go from responsibilities to objects and from there to classes.

The other school is the deductive school: start with generalizations that you now and working to the specifics. This is what one does in domain engineering. It is also supported by a class-first object-oriented development model.

If you start with classes and move to objects (which is what most practitioners do) you tend to limit yourself more to the deductive perspective. I think this is what we've been doing in software for the past ten or twenty years. The casualty, I believe, has been requirements. We make systems that may evolve well (given the chance) but which are poor at capturing user requirements (and which therefore lead into little incentive for evolution).

What I (and apparently others) have found is: when faced with this dichotomy, it's safer to go to the least common denominator, and that's objects rather than classes.

There are programming languages, like self[\b], that have objects and instantiation but which do not have classes. One can argue that the OO programming languages embedded in Lisp have much the same flavor: classes really exist only by convention.

When you say that you don't know the difference between classes and objects, I feel that you and I are on the same road to enlightenment :-)

Frank Sauer

Posts: 1
Nickname: fsauer
Registered: Feb, 2005

Re: Teaching OO: Putting the Object back into OOD

Posted: Feb 22, 2005 6:29 AM

Thank you for this excellent insight! All this reminds me a lot of what Martin/Odell called Multiple and Dynamic Classification in their OOAD book. Which brings me to my question about the use of Java interfaces as roles. By doing so, you are effectively saying that the set of roles an object can fullfil at any time is fixed and set at creation time of the object. In my opinion objects should be able to gain and lose roles as circumstances demand. For example, a Physician can also be a Patient if he happens to be admitted in his own hospital. As far as I know, no language supports this at the moment. In the Martin/Odell book they describe a technique called object slicing to implement this. Perhaps AOP can help us out here as well.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Teaching OO: Putting the Object back into OOD

Posted: Feb 23, 2005 5:02 AM

> In my opinion objects should
> be able to gain and lose roles as circumstances demand.
> For example, a Physician can also be a Patient if he
> happens to be admitted in his own hospital. As far as I
> know, no language supports this at the moment.

"If it walks like a duck and talks like a duck..."
Isn't this Dynamic Typing, as found in languages such as Python, Ruby, Perl, etc.?

will

Posts: 1
Nickname: billreyn
Registered: Jul, 2005

Re: Teaching OO: Putting the Object back into OOD

Posted: Jul 28, 2005 2:11 PM

I love your notion of 'roles' as interfaces and the idea that the world is not hierarchical. Seems to me that OO needs a re-think. It gets too complex in terms of hierarchical class structures and how they relate to real problems. My head spins when I try to combine interfaces, abstracts, protected, final, instantiation with implicit overloading. I cannot even understand what many OO buffs are on about when their language is unreferenced and without context. Lets face it - much is a sort of Asbergers
descent into narrow world views of their particular program - a bit like Wittgensteinien philosophy.
What we need is how to deal with complexity in a simple way. It can't be that difficult. OO is great for windows, circles, buttons but falls down a bit with human methods and properties because those can convolute and reverse themselves depending on a myriad of events.
We need a double genius to come up with something simpler than good old OOA. (at least remove most of the attributes, modifiers and accessors etc etc which result in spaghetti rational thinking)

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: Teaching OO: Putting the Object back into OOD

Posted: Sep 29, 2005 3:10 PM

I agree with the gist of your summary. However, beware of oversimplifying complex problems. Complex things are complicated, and discarding essential complexity actually increases the amount of accidental complexity.

OO isn't good for all designs. It is good for designs that tend to be based on "things" (rather than "how to" or on, say, relationships between things) that we classify. Given that classification is the essential property we're trying to emphasize in OOD, and given that complexity begs--at the very least--multiple classification, I have proposed what I proposed above for OOD. It is a better fit (better reduces accidental complexity) than the simpler, strict classification model of class hierarchies. That is, I have added some complexity (multiple classification) to achieve simplicity.

The moral is that one doesn't always simplify by simplifying. The stronger moral is that the goal isn't to simplify the design, but to shape the design in a way that requires the least energy to change. The simplest design doesn't always fit that criterion.

Urvashi Kaul

Posts: 2
Nickname: urvashi
Registered: Mar, 2006

Re: Teaching OO: Putting the Object back into OOD

Posted: Mar 14, 2006 7:32 PM

Very interesting article. In my opinion, most "accidental complexity" is not accidental. It is a direct by-product of the process we use in software development. It results from from abstracting too soon without enough information. In the same vein, problems with abstraction are not so much that people are eliminating information. What I perceive is
that they just don't have enough information. Most software projects are required to develop, or borrow "frameworks" prior to starting their application development. A lot of enterprise architects work on enterprise frameworks which are supposed to abstract at an enterprise level. The
process of doing frameworks first and the notion of
enterprise frameworks presumes abstraction in the absence of knowing all the particulars. There isn't much of a choice there. It is assumed that a deductive approach will
work and will promote coherence and reuse. The challenge is to show how the inductive approach would meet requirements as well as promote reuse (and reduce cost). This needs to be done in a business environment where the concept of reuse is very saleable - maybe even at the cost of "accidental complexity". In my mind, how the inductive approach should be implemented (through objects, roles etc.) is almot secondary to the pusuit of convincing the business community why we should give up a deductive approach that has been sold and marketed to management for so many years.

Regards,
Urvashi

Flat View: This topic has 27 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic