Posts Tagged programming

Bean Validation – Emmanuel Bernard on JSR 303

JavaLobby released an interesting interview with Emmanuel Bernard, the spec lead of of JSR-303: Bean Validation..

One of the important goals of the Bean Validation spec is, as Emmanuel Bernard says, is

to provide a default runtime engine that is used to validate the constraints around the domain model, in Java.

The development team decided to use annotations to express the constraints applied at the domain model. They argued that with annotations the constraints are put directly at the properties in the code, expressing the constraints associated with the property.

I highlighted some interesting parts of the interview:

Bean Validation lets you standardize the way you declare the constraints. So an application developer will just know one way to declare constraints, and just forget about all the different models. There’s no duplication around the validation on the layers.

If you think about a constraint, a constraint is really some kind of an extension of the type system.

Bean Validation lets you validate an object graph using the @Valid annotation. Basically saying, ‘Well, when you validate this object, make sure the associated object is validated as well.’ By the way, even if Bean Validation is primarily annotation focused, there is the equivalent in XML.

Any framework that is having a need to use validation, to apply validation, can either use the runtime engine of Bean Validation or go extract the metadata and play with that. So the user declares it once, in one place, and every framework in the Java space can actually go and either apply the validation routine …

You can listen the podcast of the interview also. It’s very noteworthy to read or listen the interview and see what’s next on validation in Java. Before the Bean Validation API become public to all of us, which framework do you use to validate constraints on the Java platform?

Tags: , , ,

Joshua Block on How to Design a Good API & Why it Matters

In this talk (recorded at Javapolis), Joshua Block presents guidelines about how to design good APIs. I highlighted what i think are the most important parts of the talk:

  • Functionality should be easy to explain: If it’s hard to name, that’s generally a bad sign
  • Good names drive development
  • Be amenable to splitting and merging modules (If names are nasty, take a step back and make things easy to describe)
  • When in doubt, leave it out
  • You can always add, but tou cannot take it out
  • Implementation Should Not Impact API
  • Always omit implementation details
  • Inhibit freedom to change implementation
  • Don’t let implementation details “leak” into API (For example: Serializable, hash functions)
  • Minimize Accessibility of Everything (This maximizes information hiding)
  • Public classes should’nt have public fields
  • API should be easy to learn, read and use: It should be consistent, it’s a little language
  • Documentation matters (Example: Method contract between it and it’s clients)
  • Think of preconditions, postconditions, side-effects
  • Don’t Transliterate API’s
    • What’s the problem it solves?
    • What shoud abstractions did it use?
  • Don’t Make the Client Do Anything The Module Could do
  • Throw Exceptions to Indicate Exceptional Conditions

When you see the talk, post your comments here.

Tags: , , , ,

DomainDrivenDesign: Domain Services or Method on an Entity?

There has been too much discussion on the DDD list regarding where to put the business logic control, whether in a service or entity. Being more specifically, in order to ship an order, the followthings should happen:

  1. Validate that the order can be shipped
  2. Update quantity
  3. Set the status to shipped
  4. Save the order
  5. Send an email to the customer that the order has been shipped

So, nickgieschen suggested the following C# implementations:

1. Everything in the domain:

2. Or have an application service coordinate:

There’s been a lot of replies also. I highlighted the interesting ones:

“The advantage of the latter scenario is that you’re calling _orderRepository. Save in the application layer, which I prefer since it’s easier to see the transactional control. The problem with the latter scenario is that it seems it’s putting things in the application layer which don’t need to be there. The action to Ship() seems to me an atomic, domain centered action and should therefore sit in the domain. I consider the application layer to be like a thin domain facade as defined by Fowler. That is, it is only there to direct/coordinate domain activities. Like I said, Ship() seems like it should be considered one activity, and therefore coordination from a service layer shouldn’t be necessary.”

“The way I look at it – what needs to go into Ship() is the stuff that _must_ happen before shipping can happen. And shipping can happen without the notification part. You only have a rule that says “send a notification to the customer upon shipping the order”. You don’t have a rule that says “make sure the customer gets the notification or there are no shipments”.

“So, perhaps as a rough, preliminary rule we can say anything which affects the state of the domain should go be placed in the domain. (Of course, the application layer can affect the state of the domain, but only by using domain items to do so maybe think of it as the Law of Demeter among layers.) The email doesn’t have any meaning within the domain – it’s simply a reflection of the domain.

“Notificitation of an order and the order itself is two separate concepts.”

“This could as easily be implemented using AOP.”

I think DDD advocates are a little bit extremists with some concep
ts, like repository. I wouldn’t have designed it on the domain layer, because I want transactional control on the application service layer. I think the domain has to deal with its particularities, not with sending email or adding things to a repository, even being decoupled of theirs implementations (the domain has a reference only to interfaces). So I prefer the latter approach. And you? What are yout thoughts about this design? How would u have designed it? Everything on the domain or have an application service coordinating the activities?

Tags: , , , ,

Is Java on a evolutionary dead end way?

Artima is running an article where Bruce Eckel talks about about Java’s objective on backwards compatibilities and the problem of combinatorial complexity when you combine a new feature in every possible way with the other language features already present.

It’s the combinatorial complexity that you get when you combine a new feature in every possible way with the other language features. The combinatorial complexity can produce horrifying surprises, typically after the feature is added when it’s too late to do anything about it.

It’s clear Eckel is mentioning the Java closures’ proposals to become part of the language on the Java 7 and the major improvements occured when Java 5 appeared.

If Java is unwilling to break backwards compatibility, then it is inevitable that it will acquire both unproductive complexity and incomplete implementation of new features. I’ve made the case in Thinking in Java 4e that Java Generics are only a pale imitation of real generics, and one of the more appealing suggestions for closures is an incomplete implementation of true closures, but it would actually be preferable to a complete implementation because it produces clearer, more straightforward code.

I particularly agree with him, when he also says

Fundamental new features should be expressed in new languages, carefully designed as part of the ecosystem of a language, rather thanbeing inserted as an afterthought.

He also considers Scala as an alternative for the Java language. Eckel also declares

Java values backward compatibility over the clarity of its abstractions.

I don’t agree with him at this later point, the Collections’ framework is an example of good API design rules with a lot of well designed abstractions by Joshua Block, separating things that change from things that stay the same.

And you? What do u think about it? Should Scala be considered as an exit for Java?

Tags: , , , ,

Strongly Java typed safe delegates

This great post explores an interesting Java implementation about using the delegate programming feature, in a type safe way. Delegate is a form of function pointer, commonly used to implement callbacks. It specifies a method to call, which is dispatched in runtime. From Wikipedia, we have:

The short definition is that delegation defines method dispatching the way it is defined for virtual methods in inheritance: It is always the most specific method which is chosen during method-lookup – Hence it is the original receiver entity which is the start of method lookup even though it has passed on control to some other object(through a delegation link, not an object reference). Delegation has the advantage that it can take place at run-time and affect only a subset of entities of some type and can even be removed at run-time. Inheritance on the other hand typically targets the type rather than the instances and is restricted to compile time.

We almost know weakly typed Java delegate implementations, relying upon Strings to delegate to named methods. This way, it lets you mistype the method name easily and it also does not not allow method completion in the IDE. Alex shows us a type-safe Java delegate implementation, which enhances readibility and supports code completion on the IDE, using the cglib dynamic proxy facility. The article is very worth reading. As a developer on a daily basis I’ve never seen a concrete use of this programming feature, despite being very interesting. Have you ever used the delegate feature?

Tags: , , ,

Swing tips and tricks

Some days go I was given the task to customize the Java Swing widgets for a project in our company. The default look and feel of a JDialog, specifically, has the Java logo trademark icon on the upper corner left, the close button on the right one and the title panel is painted according to the default MetalLookAndFeel probably. As an example, we have something like this:

We wanna have an option to change the title’s panel color, to remove the close button and not to have the Java trademark logo showing on the panel. The final JDialog should look like this:

I’ve thought it was a nearly difficult task, because I had to override a default look and feel and some hidden properties, sometimes difficult to find. Shame on me. Searching through some forums, I’ve found some interesting tips and tricks about how to customize a the entire dialogs of a Swing application, even without creating a look and feel or overriding an old one.

For your knowledge, here are some overridden properties to make the JDialog seems like the latter above. These properties let you define new colors for the active caption of your widgets, other font colors, custom family types and much more (for other properties see through the documentation API or the forums below).

UIManager.put(“activeCaption”, Color.BLUE);
UIManager.put(“activeCaptionText”, Color.WHITE);
UIManager.put(“InternalFrame.titleFont”, new Font(“Arial-12-i-2”, Font.BOLD, 11));
Border cuverdBorder = new LineBorder(new Color(210, 210, 210), 2, true);
dialog.getRootPane().setBorder(cuverdBorder);
dialog.getRootPane().setWindowDecorationStyle(JRootPane.PLAIN_DIALOG);
JDialog.setDefaultLookAndFeelDecorated(true);
JFrame.setDefaultLookAndFeelDecorated(true);
dialog.setUndecorated(true);

As a little example, below is the Java code to remove the close button from the panel’s title. This little code snippet below traverses the component hierarchy, passed as a parameter, in a recursive method.

Here are some Sun forums I’ve searched so far to find the possible helps for this solution:

Hope you make use of those tricks in your projects :-).

Tags: , ,

How Hard Could It Be? Five Easy Ways to Fail

Pedro da Ros has pointed me an interesting article from Joel Spolsky about ways software projects go wrong. Five Easy Ways to Fail shows us five step-guide to ensure software failure:

  1. Mistake No. 1: Start with a mediocre team of developers
  2. Mistake No. 2: Set weekly milestones
  3. Mistake No. 3: Negotiate the deadline
  4. Mistake No. 4: Divide tasks equitably
  5. Mistake No. 5: Work till midnight.

    Have you ever been in any situation like those above?

    Tags: ,

Reducing the distance between programming and project management

Some days ago me and [info]bpfurtado were talking about different areas of interest on software development and the distance created by programmers in not involving themselves on another interesting (for me :-)) areas, such as process management, requirement analysis, change control processes, etcetera.
Programmers tend to create a barrier between their tasks and other areas on software development, they prefer to be more specialist. Most of them don’t like to participate on requirement analysis discussions, design sessions, development of test cases. They prefer to code instead of being involved on such activities.
When you work on a software development company, you must have interest at the *big thing*, you need to have the whole vision of your area. People around will put better eyes on you, if you show these interest.
Nowadays at my company I’m participating in activies like use case requirement analysis and programming, because I wanna be involved in the best of both worlds. I wanna increase my analysis and programming skills. It was my decision to participate part time on requirement analysis and the rest on programming activities. I think it’s very important to have this vision and consequently it makes you a better professional. And you? Dou you like to be involved not only in programming tasks?

Tags: , ,

Method Refactoring

[info]bpfurtado has raised an important question concerning some odd practices in software programming. People who code applying the same paradigm to all computer languages, thinking the only difference between programming languages are all about their syntax and grammar. These kind of code generate a lot of bad consequences, like the one I will focus at this post.

Sometimes I see people writing methods like “doX&Y&Z”, reflecting more than one responsability inside a method. Clearly this kind of design isn’t focused on reuse and maintenance, because people who code this way don’t even know such practices, characterized in OO programming. Methods must be cohesive, that is, “a cohesive method is responsible for one and only one well-defined logical task”.

Such a method could be factored into three little private methods, named “doX”, “doY” and “doZ”. To one public method is given the responsability to coordinate the tasks between the three methods. Talking about the former approach, how can you reuse one of the computation inside the “big” method? It’s impossible. So, reuse and maintenability is better achieved in the latter approach.

It occurs that people start programming in a language without knowing the paradigm it applies. So, people need to change their mind to produce better code, otherwise real big projects will continue to suffer the same problems we are tired of hearing nowadays.

Tags:

Interview with Grady Booch

Interesting interview with Grady Booch, an IBM fellow who developed the first drafts of OOP and the Booch Method, which was a precursor to UML. In this interview, he explains why most companies are wrong in doing what they called SOA. Moreover, he says why UML was created and what he does now at IBM. Very nice.

Tags: