Slashdot Mirror

The guys at Naked Objects (http://www.nakedobjects.org/) have been singing a similar tune for some time now. Not the part about making business more like games, but about using "open-ended" and proper object oriented software that allows user interaction similar to games. I think they even used The Incredible Machine as inspiration.

Sounds like a similar rationale behind Naked Objects (http://www.nakedobjects.org/no-approach.html)

You're correct, of course. The principles should be simple. They should be fairly compact, and like all principles, they should come from the well of experience. The principles for good OO design are fairly simple:

Don't Repeat Yourself: knowledge should be represented only once in the system.

Tell, don't ask.

Classify objects in your systems by the messages they respond to, and the responsibilities they hold.

An object should only call features of: a: an object passed into it as an argument, b: an object it creates, or c: itself (I think this is the correct form of the "Law of Demeter")

Prefer short methods.

Apply design patterns according to the problems they are intended to solve.

When using design patterns, find the pattern that sets the context, this will help you identify other companion patterns that typically apply to the problem (or related problems).

Design your code to be tested, or better, write test code to help flush out the design.

Keep a nostril open for code smells, use refactorings and tests to fix the problem.

...

Always remember these are principles and not rules.

Now explaining those principles with code and narrative will fill up 700 pages if you give the whole history of how they came to be. Or you can just visit the pragmatic programmers' web site and read a bit less than 700 pages.

I also agree that the typical notion of encapsulation doesn't necessarily protect the data. When most people think of encapsulating they think of putting a barrier of functions between a data consumer and the provider (I was revolted when I first saw this in Java, I think C# and Delphi do this better with the first class notion of property). But the other meaning for encapsulation is "to embody" the data. I think that ends up being a more powerful concept when properly applied than publishing getters and setters for attirbutes that might as well be public. The idea that some other object must consume (get) the data is the first warning sign that the design is deviating from the OO way of thinking (OK, OK, paradigm, there I typed it again). When an object embodies the data, encapsulation can, in fact, protect it. But I was actually thinking that polymorphism provides a better way to ensure consistent handling of data in an OO system.

Ironically, MDA is closer to your concept of TOP than OOP is, as MDA is metadata-intensive and oriented to the creation of purpose-built syntaxes (modeling languages), although it is not specific to relational database access.

You might find this flabergasting, but I'm tempted to believe that relational databases aren't all that necessary any more. Most modern relational database hold nearly all of their data in memory. That's the only way they can achieve the performance they do. Take Oracle databases for example. In my shop the Oracle instances we run typically hold 98% of their data in memory (we have big Solaris boxen). So why not use some sort of memory snapshot system like Prevayler? The answer, of course, is that too many developers find this scary. The other argument against this is 'reporting tools.'

No, I'm not suggesting we all throw out our relational databases. But I do think there is life beyond relational data.

Also, I didn't build an example of a bad procedural system for this post. I apologize. As you know, that takes a lot of effort. Instead, as a consolation, have a look here: http://www.nakedobjects.org/section6.html Their discussion is actually about the pitfalls of task-oriented UI design, but their arguments apply to this discussion. Task-oriented UI design typically goes hand-in-hand with transaction script architecture and falls prey to the same issues (I'll even add an 'IMHO' to that). I think you'll like their spaghetti diagram a bit of the way down the page.

Thanks for the response, and the discussion.

Michael Murphree

I've been wondering what you might think of n-tier EJB / EDOC style systems. Those styles of systems are actually procedural designs (sad but true). They are task and table oriented, they just happen to be implemented in an OO language.

Well-designed OO code does not degenerate into spaghetti, any more than well-designed procedural code does. So much depends on the quality of the people creating the code that we often forget that the tools they use are less relevant than the skills they leverage.

If there is a consistency to OO design, I have not seen it and/or OO fans don't agree on what it is.

You've written a whole site on "Procedural-Relational Patterns" as a response to the GoF Design Patterns, so you must know that your statement here just sounds like you're ranting. I'll concede that I haven't always seen design, analysis, or architectural patterns applied consistently, but that again comes down to people.

My take on OO? Well it depends on what view of the system you take. You can take an OO conceptual design and implement it in a procedural architecture with an OO language (the typical approach for EJB). You can go completely OO from the UI (NakedObjects)to the underlying language (Java) to the database (I prefer O/R mapping to OO databases myself). This often works quite well in keeping the code small and understandable. I have a background in Pascal but Java is currently my language of choice as I find I'm more productive with it. And no, I don't particularly like EJB.

You mentioned Extreme Programming, a practice which orients the developer to producing small, loosely-coupled, tightly-cohesive modules. And if the code isn't that way the first time you create it, it adds a set of practices that aid the developer it putting it into that condition.

This has little to do with "incremental hacking" but rather factors human cognitive progression (we gradually understand a problem and its solution) into the software creation process. You can apply agile processes to procedural or functional programming just as easily, although you'd be hard-pressed to find an "agile" book with C, Pascal, or COBOL examples in them.

You group code mostly by tasks or events, and a normalized relational database becomes the river that connects all the individual tasks/events.

So how many times must you encode the rules for "contributing" to the river consistently? Relational data constraints often cannot handle complex decisions based on individual values in a record or a set of related records. Business consistency must then be enforced with code in every task accessing the data. You must repeat code, or at best, explicitly call it without fail, to ensure 'the river' does not become polluted. In cases like this, OO languages provide more powerful tools to represent this knowledge and ensure its consistent application.

Of course, there's no guarantee that a given developer will design with these tools (have a look under the covers of your average large EJB application and you'll see what I mean).

Happy coding (or, seeing as how I work on Compuware's OptimalJ, happy generating (grin)). BTW: MDA != OO, although you can produce one with the other.

Michael Murphree

there is a new holiness cult around using objects the divine-ordained way -- aspect-oriented programming, Law of Demeter, MVC bad, and the like.

there is a new holiness cult around using objects the divine-ordained way -- aspect-oriented programming, Law of Demeter, MVC bad, and the like.

Many of the problems with the currently popular software design antipatterns like MVC are that they throw out all of the advantages of true Object Orientation in their zeal to re-invent the 1970's style data processing in OO languages. The NakedObjects folks have an approach that makes it much easier to code in a truely object oriented fashion. This results in more natural, behaviourly complete, objects that are easier to understand, test and refactor. Although this doesn't solve all of the problems that Livschitz mentions, it definitely mitigates the common problems that developers who use OO languages experience and reduces bugs for some of the same reasons that Livschitz cites because it solves the same problems.

there is a framework where they believe in exposing the business objects inside the app to the end user. Kinda like spreadsheet / powerpoint but the real deal.

The inadequacies of debugging (not just the dubuggers themselves) as a method of ensuring quality is why methodologies like agile programming and extreme programming are garnering so much interest from developers. It's also why there has been an explosion of tools that can help with the creation of good software with fewer bugs, easier maintenance and a better chance of actually solving user problems. In the Java world, there is junit, mockobjects and log4J , that can all be used with ant so that tests can be automatically run with every build and source control systems can be automatically updated. One approach is the Naked Objects framework, which is a combinination of a design methodology and tools in one package that has advantages like the easy rapid prototyping and automatic user story docuemtation.

For example if you were using the Naked Objects framework to create a system, you might take the following approach (simplified here for posting):

1. Start with an Exploration phase, which includes:
   1. Meeting of developers, administrators and end users to discuss the nature of the problem and brainstorm possible ways to implement the solution.
   2. Create a rough prototype immediately (Frameworks like Naked Objects makes rapid prototyping like this easy).
   3. Go back to the meeting, have everybody play with the code and make more suggestions and changes. Demonstrate the prototype frequently to elicit feedback.
   4. Repeat (often) till people are mostly happy with the results.
   5. This prevents the all-to-common situation where a written specification results in excellent software that doesn't actually solve any of the problems that the users have.
2. Specification Phase:
   1. Use what you've learned to write a specification that includes lots of special case scenarios (use-cases, user stories etc.)
3. Delivery Phase:
   1. Throw out all of the code you've already written... maybe keep the class and method names, but no actual functional code
   2. Write the tests FIRST. This includes unit tests, acceptance tests and corresponding documentation.
   3. Write the code to implement various user stories and test frequently.
   4. Auto-generate user training manual, which is based on the acceptance test code.
   5. Deploy to beta testers and be amazed at how happy they are with the product and how few bugs there are.

4. Notice that approaches like this emphasize getting the design right and doing constant testing to ensure that the code that is delivered actually does the job that is expected of it. Debugging is rarely required when such methodologies are used, though profiling can be of some use.

The inadequacies of debugging (not just the dubuggers themselves) as a method of ensuring quality is why methodologies like agile programming and extreme programming are garnering so much interest from developers. It's also why there has been an explosion of tools that can help with the creation of good software with fewer bugs, easier maintenance and a better chance of actually solving user problems. In the Java world, there is junit, mockobjects and log4J , that can all be used with ant so that tests can be automatically run with every build and source control systems can be automatically updated. One approach is the Naked Objects framework, which is a combinination of a design methodology and tools in one package that has advantages like the easy rapid prototyping and automatic user story docuemtation.

For example if you were using the Naked Objects framework to create a system, you might take the following approach (simplified here for posting):

1. Start with an Exploration phase, which includes:
   1. Meeting of developers, administrators and end users to discuss the nature of the problem and brainstorm possible ways to implement the solution.
   2. Create a rough prototype immediately (Frameworks like Naked Objects makes rapid prototyping like this easy).
   3. Go back to the meeting, have everybody play with the code and make more suggestions and changes. Demonstrate the prototype frequently to elicit feedback.
   4. Repeat (often) till people are mostly happy with the results.
   5. This prevents the all-to-common situation where a written specification results in excellent software that doesn't actually solve any of the problems that the users have.
2. Specification Phase:
   1. Use what you've learned to write a specification that includes lots of special case scenarios (use-cases, user stories etc.)
3. Delivery Phase:
   1. Throw out all of the code you've already written... maybe keep the class and method names, but no actual functional code
   2. Write the tests FIRST. This includes unit tests, acceptance tests and corresponding documentation.
   3. Write the code to implement various user stories and test frequently.
   4. Auto-generate user training manual, which is based on the acceptance test code.
   5. Deploy to beta testers and be amazed at how happy they are with the product and how few bugs there are.

4. Notice that approaches like this emphasize getting the design right and doing constant testing to ensure that the code that is delivered actually does the job that is expected of it. Debugging is rarely required when such methodologies are used, though profiling can be of some use.

Yep, I can see the slashdot headline now: "Pimp OS uses Naked Objects foundation"...

Hmmm, I'm looking at the screenshot which is posted on the article, and I'm a little amused...

Customer?
Communication?
ChildBenefitScheme?!?!
Case?
Payment?
Officer?

I mean, I can understand that a PimpOS or a SlutOS would want to be object oriented and all. But isn't keeping a record of all your activities going to get you into trouble in most places?

I suppose that the developers are located in Nevada or Amsterdam or someplace.

I posted my reply just before yours, so you probably didn't see it when you posted yours :)

Naked Objects is a Java framework designed to allow developers to get back to the central ideas of true Obect Oriented design and development, which, naturally includes proper OO User Interfaces.

Even though so many developers use OO languages, they often end up with designs that harken back to the bad old days of data processing - data fed into procedure oriented programs. OOUI is in an even sadder state. Most deisgns seem to use the UI to cloak what's going on in the underlying object model (if there is one). It's especially ironic when you realize that some of the few programs that acutally use truly OOUI's are the Integrated Development Environments that those same developers use to create those horrible UI's. Can't they even see what's right in front of them?

Current design philosophy ends up giving the users horrible interfaces that just get in the way of actually getting the job done. Even worse, this process oriented view of the world treats the users as slaves to our machines that can do pattern recoginition better than the machine can. The Naked Objects approach, views the users as problem solvers and provides several different ways to accomplish a task. You've seen it before in spread sheets, drawing programs and IDE's. Naked Objects brings this level of expressiveness to every program and frees the user to be creative rather than just some cog in a machine.

So throw off your GUI and expose your business objects for the world to manipulate! Rejoice in the Naked Objects philosophy and free yourself of all that cruft weighing you down. So run free and let your objects swing in the breeze and... er, um... you get the idea :)

Be sure to study the Lisp de-facto standard UI system, CLIM 2.0, closely. It's great for complicated GUI systems for OO Lisp projects.

Alsom, be aware that the best GUIs tend to be the ones that let the user do most anything your underlying program code can, and combine things in unexpected ways. Make sure to read up on Naked Objects

One extreme programming tool written in Java which I haven't seen mentioned here is that of Naked Objects. I had play with it the other day and thought it quite a neat idea.