Enterprise Java is not Object-Oriented | Hacker News Reader

Enterprise Java is not Object-Oriented

13 pointsjganetsk11 comments

I've been working on a medium-size Java application for the last 2 months. We make use of the Spring framework, which implements many of the Enterprise Java APIs, and replaces some with alternatives. Using this framework correctly requires conforming to various conventions on structuring your code.

It seems that these conventions preclude the benefits of OOP, namely abstraction and information hiding. The vast majority of classes fit into one of two categories: Beans and singletons. A Bean is just a record: a group of members all publicly accessible via getters and setters. The singletons are all just code without data. Not a single class has a non-trivial constructor.

I understand that Spring provides many benefits, such as easy testability, aspect-oriented programming, and removing lots of boilerplate. I don't question this. My question is: can we still call this object-oriented programming? I could see this entire application being written in OCaml, with functors, with some clever preprocessor that generates code to wire all the functors together. It would work just as well as OO code, maybe even better. And even then, the advanced features of the type system (those that provide abstraction and information hiding), would not really be utilized.

Two points:

1. Does it matter? If it works and it's reliable (Spring has always fulfilled both of these requirements for me) then who cares what you call it?

2. You could build the same system in OCaml but good luck finding developers to work on it. Plus I don't know what kind of "enterprise" (database/web services/etc) support it has.

If it works, and is not object-oriented, then we should reevaluate the relative worth of OOP. I do agree that mainstream programming languages are valuable because of number of developers working with it, and "enterprise" support. So, maybe the next such programming language should not be OO. Maybe it should be functional.

It is not very object-oriented the way HE used it, but, being a long time Spring user I can assure you that it is a case of misuse. Spring does not force you to use setter injection (it supports constructor injection) and it certainly does not force you to use anaemic domain model (although many people are doing it). A fool with a tool is still a fool, I'd say.

Spring and J2EE are modular, not object oriented to any great degree. One can implement more OO further down the chain, such as in model objects, of course, and in other custom subsystems but the overall J2EE/Spring model is a hybrid of procedural/imperative and some OO.

a good counterpoint to your idea is: Would You Bet $100,000,000 on Your Pet Programming Language? http://prog21.dadgum.com/13.html

--Don't worry, as for myself, I see only questions, and answers that only bring more questions.

I have to use Spring at work in a pretty large Enterprise Java environment, and our setup is not as you describe.

Despite Spring's message of conformity, it doesn't actually force you to program everything as singletons and beans.

I concur. I also use Spring at my dayjob, without the problems the OP describes.

Spring is really useful for setting up the underlying infrastructure/plumbing/cross cutting concerns of a system - however, you don't have to use it for all your domain logic too. Don't drink the dependency injection cool-aid. :)

I like dependency injection for wiring together configured singletons (such as factories). What I don't like is a trivial constructor and then injection via setters. Constructors should produce objects ready for use, and Spring tolerates doing it that way (though it seems to prefer setters).

Beans can certainly encourage http://martinfowler.com/bliki/AnemicDomainModel.html

You are correct.

OO is too complex for the enterprise, because the requirements are simple and the deadlines are short. If you use complex OO hierarchies, you are going to over-engineer the solution, because it really does not require all that OO flexibility. You will also make things impossible to debug or maintain, and blow your deadlines. You need just enough OO to implement common patterns, but if I see more than that, I assume the programmer is new to real-world enterprise software development. Most enterprise software is just glue, and it is not spelled 'glOO'.

It has been said that Fortran and Cobol programmers can write Fortran / Cobol programs in any advanced language. Bit like the C programmers using C++ where they only use "//" for comments.

It is possible to architect and write enterprise software using OOP, but it takes talented and dedicated OO-ADP (analysis-design-programming) team to pull it off. Most projects don't have the time-frames to accommodate such an ambitious goal. Hence the adoption of Spring / J2EE, et al. Frameworks are always a compromise compared to carefully crafted systems.

Please, Spring is NOT J2EE (in a good sense) ;)

Reply on news.ycombinator.com