This post is a reply to Kent Tong’s post about scala’s getters and setters: http://agileskills2.org/blog/2010/01/applying_scala_to_solving_real_1.html:
You may also use the @BeanProperty annotation to generate Java-compatible getters and setters instead of weird methods with space and equal signs:
http://www.scala-lang.org/docu/files/api/scala/reflect/BeanProperty.html
The object oriented programming paradigm involves developers to design code as classes. Classes associate data and behavior into one single abstraction.
That’s OK, but… how should one design code that only has behaviour or that only has data?
Is the class abstraction still the good one for cases where there is only behaviour? In this case, provided I use the Java language, I would design behaviour as static methods of final classes which cannot be instantiated. Is it then still OK to talk of classes? I think it’s not. The Scala language gives two answers to this problem: objects and functions. Objects are real singletons, and should be used to define behaviour or processes. Functions are like methods, but they are member of nothing, they are not associated to any class.
Is the class abstraction still the good one for cases where there is only data? A C-like structure would suffice in this case. And for people who want to benefit of encapsulation, use simple classes like JavaBeans. Without any other method than getters and setters. Or some immutable classes.
With respect to separation of concerns, is it right to put behaviour and data in the same abstraction? Doesn’t this make the OO design difficult? Most people fail to think correctly about behaviour when they design subclasses. They only think about the data. For more insights about this, see the real implications of the Liskov Substitution Principle (which is, IMO the most important principle of OO design).
And, if having to associate behaviour, why wouldn’t I design a ‘data class’ and a ‘static methods class’? Wouldn’t this make it easier to adhere to better OO design rules?
I’m bored of having to use different environments for development, testing, integration and production. Either I must have the complete production stack on my development computer – this uses a lot of resources, or I must use different tools.
For example, when I develop Java web applications, I often test my applications with either Tomcat or Jetty, then deploy on a production-quality JEE server, like Glassfish, WebSphere, WebLogic etc. And in many cases, it doesn’t work well, because the web containers of these JEE servers are not always the ones I used for development.
I believe there should be a Java WebContainer Embedding standard API which should be used in JEE servers to embed JEE web containers. This API would provide all services a JEE container needs to manage web containers.
Using OSGI, it would even be possible to use, in one single JEE server and for each web application, a web application specific web-container. I’d find it very useful to be able to tell the application server what web-container should be used for each of my web-applications.
Such applications would permit one to use the same web container through the complete development cycle.
This principle may also be used for any other JEE service providing container.
This week at my client’s offices, I discovered, with another IT consultant from a concurrent firm, a strange behaviour of ServletContextListeners.
The specification doesn’t state much about them. They are classes which implement the ServletContextListener interface, and they are instantiated with their default constructor during the webapp loading, in the same order as specified in the web.xml.
The specification doesn’t state if the listeners are first all instantiated then all executed or sequentially instantiated and executed one-by-one. That’s the point I’d like to discuss.
First of all, I’d like to mention the fact that I used the Jetty web container for development and test.
In the application, I had two listeners A and B, and listener B depended on the initialization of A. Thus, in web.xml, I first declared listener A then listener B.
Listener A actually was a Spring ContextLoaderListener, and listener B‘s constructor initialized its private variables with beans declared in the Spring application context. Listener B‘s constructor was expecting (as well as I did) that the Spring application context had already been initialized. But that was not the case. Actually, Spring’s ContextLoaderListener does initialize the application context in the contextInitialized() method. Thus listener B‘s constructor could not initialize B‘s variables, which stayed with their default null value. And the application did not work.
This was the method sequence I identified:
A‘s constructor. Does nothing special.B‘s constructor. Fails because Spring’s context is not initialized.A‘s contextInitialized() method. Initialized Spring’s application context.B‘s contextInitialized() method. Tries to further initialize B, relying on the failure-less execution of B‘s constructor.I expected another sequence:
A‘s constructor. Does nothing special.A‘s contextInitialized() method. Initialized Spring’s application context.B‘s constructor. Shouldn’t fail.B‘s contextInitialized() method. Tries to further initialize B, relying on the failure-less execution of B‘s constructor. Should work.The workaround to this issue is easy: simply initialize B‘s variables in B‘s contextInitialized() method. That may not be really important, as finally the application works, but I think there is in fact an important issue: B‘s constructor should initialize B. As I designed B to be immutable, this was the only place where I could initialize B‘s variables. Now, using the workaround, B isn’t immutable any more. I’m really not happy with this.
What I’d like to point out is that the specification is not quite precise about the sequence of method calls in context listeners, and this doesn’t help make good design. I usually find Jetty to be a well-designed web container, but here I believe Jetty’s developers made a mistake. Which I think is easy to correct.
I can’t tell if Tomcat has the same issue.
Sometimes, specifications should give more details about their implementation. This is even more important if the specification states about code that should be executed in a given sequence or if the implementation has a impact on the ability left to the developer to make good design.
One thing many developers forget about OO design is the purpose of classes.
A class consists in the association of data structure and behaviour! Many people forget the behaviour.
This is really important when defining class hierarchies and applying the Liskov Substitution Principle (LSP).
Behaviour is at least as important as data structure. But it becomes complicated to analyse the behaviour of a class hierarchy and that’s why most programmers don’t care because they don’t know about broken behaviour in class hierarchies.
I’m convinced that the use of domain specific languages and the growing focus on user behaviour and abstractions’ (the implementation of business concepts using classes) behaviour will make all of us more aware of this concern.
This was a debate I had with another developer at the YaJug (Luxembourg Java User Group).
My opinion is that they always have to be executed especially in production environments. But wait: argument checks usually throw IllegalArgumentException, which inherits from RuntimeException, and which usually is not checked. This means that such an exception usually steps back the stack without handling the initial issue. In fact, it does. So, why should one mind about argument checking, if in any case the issue is not handled?
Well, I think early failure detection is really important, and validating arguments before executing method arguments permits to detect illegal program states that may or will produce failures. What is really important in production environments is to ensure that data state remains valid. It is easier to keep data state valid if no bug is allowed to produce undetected side effects, especially in complex applications. This also makes debugging easier, as the effects of the bug will stay limited if it’s detected early. This also permits to save some computing ressources, as code execution is limited once the invalid argument is detected.
What is against the use of argument validation: the use of ressources that these imply. This is about the same reason for which assertions are disabled in production environments.
Do you have any other pros/cons about method argument validation???