

Ask HN: What is the state of the art in OOP? - olliesaunders

I used to do a lot of object-oriented programming and found myself reading up a lot on how to do it well.<p>When C++ was the dominant OOP language there was a very different set of best practices than have emerged since. Some of the newer ideas I know of are BDD, internal DSLs, and the importing of ideas from functional programming.<p>My question is: is there any consensus on the best way to develop object-oriented software today in the more modern languages such as C#, Ruby, and Python? And what are those practices? For instance, I rather like the idea of stateless objects but how many are actually using that in practice?<p>Or, is the state of the art to deemphasize the importance of OOP? This might be the case for some Python programmers but would be difficult for Rubyists.
======
jdlshore
State of the art is difficult to answer, given how faddish programming trends
can be. It's hard to separate the truly important ideas from the ideas that
are merely popular. I don't think any of the truly important ideas are all
that new. Here's my perspective from inside the Agile camp:

Things that are popular and important:

\- Refactoring

\- Test-driven development

\- Closures and first-class functions

\- Domain-driven design

Things that are important but not popular:

\- Evolutionary design (aka continuous design)

\- Refactoring beyond what's built into IDEs

\- Domain and business expertise

\- Conway's Law; small, close-knit teams; minimizing dependencies on other
teams

\- Minimizing maintenance costs over initial development costs

Things that are currently popular but likely to lead to pain:

\- Domain-specific languages, particularly internal DSLs

\- Behavior-driven development, particularly external DSLs like Cucumber

\- Storytest-driven development / acceptance test driven development

~~~
__Joker
Hey, Can you explain or point to rational for these assertions ?

~~~
jdlshore
It's all my opinion, of course. I'm not aware of any objective way to evaluate
these sorts of design techniques, and if you're looking for proof, you'll have
to look elsewhere. (But ask yourself what proof you have for any design
technique you hold dear.)

Here's a brief rationale for each one.

Important and popular:

\- Refactoring: Allows you to improve design as you learn.

\- TDD: Significantly reduces programmer error.

\- Closures + first-class functions: Enables new design abstractions which
reduce duplication.

\- Domain-driven design: Nothing really new here, but it's a useful way to
describe OO design that's finally making an impact on the legions of people
who programmed procedurally in an OO language.

Important but not popular:

\- Evolutionary design: The only technique I've seen that actually improves
code quality over the long term. See also
<http://martinfowler.com/ieeeSoftware/continuousDesign.pdf> (PDF)

\- Refactoring beyond what's built into IDEs: Most people I meet don't
significantly improve the design of their software when they refactor.
Instead, when they need big improvements, they rewrite (and call it
"refactoring"). I think that's because they don't really understand
refactoring, which involves a series of small, behavior-preserving steps, most
of which are not automated by IDEs.

\- Domain and business expertise: Provides context for trade-off decisions.

\- Conway's Law: I see the most defects and productivity problems at the
boundaries between teams. This makes team structure an architectural question
as well as a political question. When you have a large system, how do you
break it into parts and who works on what? A careless approach results in a
lot of cross-team communication, which leads to performance problems and
defects.

\- Minimizing maintenance costs: Most software spends more time in maintenance
than in initial development. See also <http://jamesshore.com/Articles/Quality-
With-a-Name.html>

Popular but long-term pain:

\- DSLs: Suffer the same problems that frameworks do, but worse: When your
needs diverge from the solution offered, you have to hack in kludgey
workarounds. They suffer from leaky abstractions, so when they don't work
right, it's time-consuming and difficult to figure out what's wrong. You're
locked into their syntax, so switching to an alternate approach is difficult
at best and requires a rewrite at worst.

\- BDD: Started out as "TDD with different words" and became steadily more
obsessed with automated english-language specifications, which adds cost over
TDD without adding significant value. The hope that business users will read
(let alone write) a BDD specification is a pipe dream in nearly all cases, and
programmers are perfectly capable of reading well-written code--which has the
additional benefit of being more precise than english. The "fluent" interface
many BDD frameworks use suffer all the DSL problems I just mentioned. External
DSLs like Cucumber gravitate towards slow and fragile end-to-end tests (see
next item) and also don't play well with refactoring tools, which is a
maintenance problem.

\- Acceptance test-driven development: [http://jamesshore.com/Blog/The-
Problems-With-Acceptance-Test...](http://jamesshore.com/Blog/The-Problems-
With-Acceptance-Testing.html)

~~~
__Joker
Thanks for the detailed answer. I always find it pretty difficult to
objectively assess these design techniques.

------
billitch
Smalltalk should be a very good source of inspiration, if you're looking for
an OOP reference i believe the smalltalk folks have things to say.

Being more of a lisper, I think stateless objects describe problems better
suited for functionnal style and pattern matching. Relying on the type system
of the implementation is a very unspecified aspect of a language. May be ok
though if you know it is fast.

Rubyists still have blocks and closures, bringing in a lot of functional
style, almost unnoticed.

The styles are complementary, finding the best one for the problem at hand is
the art of program designers.

------
jbarham
"Object-oriented design is the roman numerals of computing." - Rob Pike

------
bnastic
I'd take the risk of pointing out that the state of the art OOP is still to be
found in Smalltalk.

~~~
draegtun
I'd say CLOS (<http://en.wikipedia.org/wiki/Common_Lisp_Object_System>) &
Moose (<http://moose.perl.org>) myself.

However I do like Prototype based OO (<http://en.wikipedia.org/wiki/Prototype-
oriented_programming>) and especially its implementation in Io
(<http://www.iolanguage.com>)

~~~
billitch
Well, CLOS may be state of the art in very fine designed,exhaustively
redefinable, roll-your-own aspect oriented programming, and the most
exhaustive object oriented paradigm for the most fluid pragmatic language
ever.

But I doubt you'll find useful sources for programming style searching for it.

If you are implementing an object-oriented paradigm for your programming
language, it's a very recommendable source to discover what can possibly be
done with OOP.

~~~
draegtun
_But I doubt you'll find useful sources for programming style searching for
it._

How about AOP? (<http://en.wikipedia.org/wiki/Aspect-oriented_programming>). I
think both CLOS & Moose push you more towards this programming style.

------
StudyAnimal
Just 3 things that come to mind, I don't know if that is what you are looking
for. It is coming from more of a C# and Java angle, than a Ruby and Python
angle.

* People like Robert "Uncle Bob" Martin popularising and extending the ideas of Bertrand Meyer with i.e. SOLID principles, and design ideas focussed on quality and maintainability.

* Domain Driven Design, also in some sense a rehashing of old ideas but combined with some new ones as well.

* Service Orientation and Component Orientation could both be seen as extensions of OO to higher level design and architecture.

------
CyberFonic
I think OOP has become so mainstream as to become invisible. For example,
HTML5, DOM, SVG, etc are OO (although defined in terms of interfaces). When
you write JS code, you are mostly manipulating objects and relationships
between objects.

You mention Python, it allows you to write both OOP and FP code. Functions can
invoke methods on objects.

As for "state of the art" I'm learning more from reading open source project
code than by reading books. I find that different languages have evolved
different styles / patterns.

~~~
redthrowaway
I find Python's OOPiness has a tacked-on feel, with copy.copy and self.x
taking the place of more rational syntax. I've only looked at Ruby briefly,
but it seems to be both lispier and oopier than python in an intriguing way.
We'll see how I feel after using it in the real world for a bit.

~~~
beza1e1
What is tacked-on about this?

copy.copy: Who don't you "from copy import copy"?

self.x: It explicitly distuingishes between local variable and field access,
which is the Right Thing in my opinion.

I do not understand, what this has to do with OOP at all.

------
mlvl-spb-rus
Newspeak (a "heir" of Self and Strongtalk), Qi and Scala, with Newspeak being
the real "art" and Scala attracting more public, I think.

~~~
mlvl-spb-rus
Oh yeah, and Design Contracts (Eiffel-style) are still hot (and getting
hotter: we got them for C# and (in multiple implementations, one of which is
from Google) Java too now).

------
vicaya
Focus on interface rather than object.

Embrace explicit state with state machines and events.

------
leon_
After years of OOP I came to the conclusion that OO is no good. It has too
many problems with parallelism - you have to use way too many kludges to make
your shiny objects work in parallel.

For _me_ Data Oriented Programming is the future. My data does not need to be
intelligent. For that I have my central data processors. As soon as there are
no "objects" that need to talk to each other parallelism becomes so hassle
free.

The only case I still like OO for is UI programming.

~~~
andrew1
Do you have a link to what you consider to be a good
description/definition/tutorial of "Data Oriented Programming"?

~~~
stonemetal
Whenever I run across Data Oriented Programming it is almost always called
Data Oriented Design. You focus on your data and what transformation it needs
to undergo to become output. Noel's blog is probably the best source of
information for that style of programming I have seen.

<http://gamesfromwithin.com/data-oriented-design>

~~~
andrew1
Thanks, that's an interesting article.

