InfoQ Homepage Presentations Panel: Objects On Trial
Panel: Objects On Trial
51:32
Summary
Michael Feathers, Brian Foote, Richard P. Gabriel, Joshua Kerievsky, Eliot Miranda and Dave Ungar put Objects on trial and found them guilty for not living up to their promise.
Bio
Michael Feathers is an Agile pioneer. Brian Foote is Senior Scientist at the Refactoryand. Richard P. Gabriel has been a researcher at Stanford, Distinguished Engineer at Sun and IBM. Joshua Kerievsky is the thought leader behind Industrial XP. Eliot Miranda is a Smalltalk VM implementor and was technical lead for VisualWorks. Dave Ungar received the 2009 Dahl-Nygaard award, and is an ACM Fellow.
About the conference
QCon is a practitioner-driven conference designed for team leads, architects and project management. The program includes two tutorial days led by over 80 industry experts and authors and three conference days with 18 tracks and over 80 speakers covering a wide variety of relevant and exciting topics in software development today. There is no other event in the US with similar opportunities for learning, networking, and tracking innovation occurring in the enterprise software development community.
Dec 23, 2011
Community comments
So, in summary?
by Melle Koning,
Re: So, in summary?
by raj n,
Re: So, in summary?
by David Smith,
It has always worked for me and Startrek
by George Ludgate,
So, in summary?
by Melle Koning,
Your message is awaiting moderation. Thank you for participating in the discussion.
- just do not make the OO model too complex
- strive for readability, because beauty is in the eye of the next programmer who needs to change your code.
- generics can be hard.
- OO beauty should not get in the way of performance
More one liners that can be taken from this trial? So far Like thumbs up.
Re: So, in summary?
by raj n,
Your message is awaiting moderation. Thank you for participating in the discussion.
Code Reuse is an illusion - Pattern Reuse is more practical
It has always worked for me and Startrek
by George Ludgate,
Your message is awaiting moderation. Thank you for participating in the discussion.
There are several reason OO has not lived up to its promises and none of those are due to the approach. We still teach our CompSci students in a functional manner. They then use object oriented programming languages to do modular programming and not OO systems development. This is the most pervasive approaches out there. Those that succeed in OO develop an analysis model of the problem domain as perceived by the humans working in that domain. You can do this in small pieces or all at once. It does not matter as the whole is a sum of the parts. Then you teach the computer to understand the world the same way the humans understand it to be. “Data” in Startrek understands the world the same way as the humans in each episode – I believe anyway. His world model is gathered in pieces just like the crews’. Thus this approach works perfectly for waterfall or any of the agile approaches. No refactoring - as the world does not change just because you look at small pieces of it, one at a time. The problem that you first encountere when you try to teach the world model to the computer is that the OO languages do NOT support describing such a model. They have no formal relationship construct nor state transition capability (as a start). So you have to start to make these constructs up yourself and this means there are a huge number of ways of doing it leading to you never being able to re-use code from other developers. You can form components by grouping together classes but how big is a component?? This latter question sinks the approach as no two developers agree on the size. As I said above, functional development is the norm today using OO languages. More and more features are added to support this approach – most of which are not needed for OO. Unless training changes OO never will reach its promised level.
Re: So, in summary?
by David Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
The community reuses a ton of libraries daily ('java.*', "org.apache.*') very successfully. In the companies I have worked for we have been quite successful at reuse in our frameworks. The problem is poor designs. Embrace immutability and prefer composition over inheritance. I haven't seen a third party application framework that doesn't encourage the opposite, so write your own -- it doesn't have to be J2EE.