

Enterprise Java is not Object-Oriented - jganetsk

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.<p>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.<p>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.
======
bdittmer
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.

~~~
jganetsk
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.

~~~
fb
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.

------
toddc
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.

------
sirsean
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.

~~~
thomanil
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. :)

~~~
prodigal_erik
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).

------
Edinburger
Beans can certainly encourage
<http://martinfowler.com/bliki/AnemicDomainModel.html>

------
mikhailfranco
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'.

------
CyberFonic
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.

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

