Re: UML IS REALLY IMPORTANT .... or not?

On Jul 20, 2007, at 3:06 PM, email@hidden wrote:

If you really want to take advantage of Java, start treating it

more like Objective-C and less like C++.

I like that. But then I find Java's techniques for getting the

flexibility of Objective-C are a little obtuse (nested classes and

all of that), whereas Objective-C seems cleaner, even through it's

rather obtuse preprocessor-style syntax.

Forget types. The types of objects aren't nearly important as the
functionality they implement. -pc

Well, yes and no. A type is only characterized by the functionality
that it provides so they are really synonymous. And given that
notion, there's a whole lot you can derive about the correctness of
the software.

Perhaps it would take more time and space than this list provides, but the basis of Objective-C is that any object can have methods that respond to arbitrary messages.

While the signature of Obj-C methods supports the use of typed parameters for its methods, the important thing is that all parameters are named and there is nothing keeping you from attempting to send any kind of named/typed parameters to any method on any object. It might work or it might fail, but there is a freedom to this kind of architecture that is discouraged in most typed languages.

A simple example of doing this is Java might look like this:

public void method1(Map message);

There's nothing here that's going to tell you at compile time if your message is valid unless it's not a Map. In fact, the only thing that might fail here is if method1 decides to throw an exception. If method1 needs to defer part of its processing to another method, you simply use the same form:

public void method2(Map message);

Won't this be less efficient? Maybe. Slightly. Your mileage may vary. It does keep you from having to extract parameters in method1 that only method2 cares about.

But I think the useful part is being able to pass and obtain references to any object that may/may not be passed to the method without having to refactor a method signature, often importing new specialized classes with their own getters and setters and coming up with a reasonable parameter order that is consistent with similar types of methods.

When all your high-level methods have an identical parameter signature -- especially something that stores arbitrary Object references -- you begin to develop a method writing style that no longer places restrictions on the types and number of parameters to expect. Extending a class from "typeless" interfaces, saves you the trouble of having to completely map out your class/method hierarchies ahead of time. You are now free to use/require whatever inputs you need without having to recode/recompile everything.

But doesn't all this mean a lot more Runtime debugging? Yes. This is the nature of a dynamic language. Get good at it. Give yourself useful and informative exception handling routines. Start doing entity based logging. Learn how to read stack traces -- they tell you exactly where the error happened.

It also means that your method implementations can provide forgiveness and default parameter values when older parameters (or none) are used.

When all top-level objects start to look and behave in a similar way, you end up with a much simpler class hierarchy. Classes are easier to write because they all use the same method signature (fewer unique signatures to remember). Programming becomes easier. Objects become more interchangeable because they no longer have to fit together uniquely. And when you discover that all your objects need some additional parameters for context (say an authentication token, or a reference to a particular database) these values are added and propagated automatically without hardly changing any code at all.

I expect that this approach terrifies a lot of people. A lot of developers get upset about "too many moving parts". But this is the nature of dynamic applications and this kind of thing happens to you all the time in the Real World. I say go with the flow and embrace programming techniques that support this style of programming.

Focus your tool requirements on things that make your application accountable at Runtime instead of hoping for the best at compile-time. Typed constructs want you to decide on your final architecture now, and don't offer many routes to refactoring your code later when your requirements are changed, rescaled, or totally turned inside out and upside down. Having code that can roll with the changes is more valuable to me in the long run. -pc