Open minds leads to freedom

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:

 1:class Order
 2:{
 3:    IOrderShippedNotificationPolicy _notificationPolicy
 4:    IOrderRepository _orderRepository
 5:
 6:    void Ship()
 7:    {
 8:        if (!CheckIfOkayToShip()) {
 9:            throw new InvalidObjectException();
10:        }
11:        UpdateQuantity();
12:        _orderRepository.Add(this);
13:        _notificationPolicy.Notify(this);
14:    }
15:}
16:
17:class OrderShippedNotifyByEmailPolicy : INotificationPolicy
18:{
19:    // The object that gets injected is implemented
20:    // in the infrastructure layer
21:    IEmailGateway _emailGateway
22:
23:    void Send(Order this)
24:    {
25:        // Create email here
26:        _emailGateway.Send(email);
27:    }
28:}

2. Or have an application service coordinate:

   1:class OrderService
   2:{
   3:    // _orderRepository and _orderShippedNotificationPolicy 
   4:    //  are injected dependencies
   5:
   6:    void ShipOrder(Order order)
   7:    {
   8:        order.Ship(); // in this case it only validates and updates quantity
   9:        _orderRepository.Save(order);
  10:        _orderShippedNotificationPolicy.Notify(order);
  11:    }
  12:}

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?

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?

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?

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.

   1:public static void removeCloseButton(Component comp)
   2:{
   3:    if (comp instanceof AbstractButton)
   4:    {
   5:        Action action = ((AbstractButton) comp).getAction();
   6:        String cmd = (action == null) ? "" : action.toString();
   7:        if (cmd.contains("CloseAction"))
   8:        {
   9:            comp.getParent().remove(comp);
  10:        }
  11:    } else if (comp instanceof Container)
  12:    {
  13:        Component[] children = ((Container) comp).getComponents();
  14:        for (int i = 0; i < children.length; ++i)
  15:        {
  16:            removeCloseButton(children[i]);
  17:        }
  18:    }
  19:}

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

• http://forum.java.sun.com/thread.jspa?threadID=630096
• http://forum.java.sun.com/thread.jspa?threadID=690852&messageID=4016833
• http://forum.java.sun.com/thread.jspa?forumID=54&threadID=501146
• http://forum.java.sun.com/thread.jspa?threadID=356373&messageID=1486015
• http://forum.java.sun.com/thread.jspa?threadID=5171154&messageID=9658560
• http://forum.java.sun.com/thread.jspa?threadID=765742&messageID=4366238

Hope you make use of those tricks in your projects .

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.</li

Have you ever been in any situation like those above?

Some days ago me and 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?

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.

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.

The majority of software developers have a language of choice. Some may chose their preferred language based on the paradigm it applies, others may evaluate if the language is static or dynamic, if it has weak / strong typing, nice and interesting language constructs (like closures, continuations) and other various criteria. My preferred language is Java (up to now, because I’m studying Python, and this language is becoming a good candidate to be my language of choice for a lot of reasons, but these will be part of another post ), because it’s a good OO language and it offers good opportunities to apply OOA/D, that is, to construct well-designed, maintainable, robust OO systems.
Therefore a problem can arise: if the developer tries to keep this preference for a specific language / platform in the organization. This can become a passion and every new project the developer is asked to give a opinion the choice will be his/her preferred language, because he/she believes it’s the best language of the world, because he/she got used to the language. If the developer participates in a open-source community and its company decides to chose a proprietary language, the fight with managers is even worse. So, always remember:

• The language of your choice might not be appropriate to solve a specific problem. You have to evaluate other languages / platforms to achieve the best results. It’s your routine as a software developer. Perhaps other language offers a better cost / benefit than your preferred language (You can solve your problem with fewer lines of code with a different language, for example).
• You are in a company to achieve results, not to program in Java, .NET, Python or anything else. Always have this in mind. Don’t let your passion hide your opportunities in a company.

Have you ever seen some situations like these on your development team?