Comments on Carlo Pescio - blog: Your coding conventions are hurting you

We have [at least] two ways to fix this. The simpl...

2012-02-03T09:49:42.191+01:00

We have [at least] two ways to fix this. The simplest way is to identify a decent domain concept, like SalesCategory (since cargoes are grouped by a category known to the SMS). So our code would be like (using Java and short variable names):

SalesCategory sc = new SalesCategory( cargo ) ;
EnterpriseSegment es = sc.getEnterpriseSegment();
Quantity q = cargo.quantityBooked( es ) ;
Boolean ok = sc.mayAccept( q ) ;

I've kept the book terminology and signatures. Having a class nicely scales to the most reasonable evolutions, like asking for how much could be actually booked when a cargo is rejected, etc.

The second way to fix it goes much deeper. Of course, the most "natural" place for those functions is the Cargo itself. We don't want to put them there because those responsibilities are not strictly part of "our" application domain. They're placed on a boundary with the sales management system. Well, that's a linguistic problem, isn't it. It's because we look at the problem through the rather narrow perspective of statically typed languages with closed classes. So a different solution is to allow objects to be supplemented when needed. This is possible (in limited ways) in objective C, in C# (with extension methods), and soon in Java 8 as well (http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf).
Stretching the idea a little, we come into the concepts of subjet-oriented programming, and ultimately in the realm of aspect-oriented programming. Stepping on the philosophical soapbox for a moment, Alan Kay used to say that he expected Smalltalk to be just a step in an evolutionary chain, something other people would improve upon, but that didn't happen. I actually consider AOP+OOP the next step, providing much of the flexibility that we currently lack. I see no problem in having my cargo enhanced with more responsibilities (methods) when used within the context of the Booking Application.
A theme I'd like to discuss at some point: mainstream languages keep reinforcing the idea that in order to separate the artifacts (source files) we have to separate the run-time instances (objects). That's a byproduct of languages and technologies, and it's not inherent in a paradigm.

Trying to answer your question now: I use services in some of my architectures, meaning the SOA notion of services. The interface of those services (which are usually called from remote systems) is not OO, because I'm doing services, not distributed objects. The implementation of those services, however, is usually OO, not procedural. Even the infrastructure of those services is OO, as there is much to be gained from that. So, in a word, no, I do not agree, sorry :-).

An in-depth discussion of DDD and some of its choi...

2012-02-03T09:49:30.244+01:00

An in-depth discussion of DDD and some of its choices would take at least an entire (long) post, so I'll try to avoid theory and go straight to the practice. That is, I'll take a couple of examples from the DDD book and tinker with them.
(the answer turned out so long anyway that I had to split it into two comments :-)))
Example 1 (simple)
"For example, if an application needs to send an e-mail, some message-sending interface can be located in the infrastructure layer and the application layer elements can request the transmission of the message. This decoupling gives some extra versatility. The message-sending interface might be connected to an e-mail sender, a fax sender, or whatever else is available." (page 73, unfortunately is not on google books)
So one may proceed with an EmailSender or FaxSender service. Sorry, that sucks :-). There is a nice OO abstraction there, waiting to be found. It's called MailBox, or OutBox if we're only concerned with sending.
Now, we can easily contend that I'm just fiddling with words here, but I'm not. The reason I want OO concepts to emerge is that it's way more natural to add responsibilities to an OO concept like the MailBox than to the EmailSender. Because in practice, you'll also want to configure the mailbox. You want to know the current state (queued messages, failures, whatever). You may want to specify a callback function to be called when some message has been delivered. Etc etc.

Lest someone thinks that I'm making this up, let's move forward a few pages (181 and following, it's partially on google books http://books.google.it/books?id=7dlaMs0SECsC&lpg=PP1&dq=domain%20driven%20design&pg=PA181#v=onepage&q&f=false but most of it is missing)
An external Sales Management System is wrapped by a service, called AllocationChecker. The initial responsibility seems function-like: given a cargo, how much of this type of cargo may be booked?. After a short discussions, however, the allocation checker takes on two responsibilities:
- deriveEnterpriseSegment(Cargo) [which provides a way to translate concepts from the SMS domain into our own concepts]
- mayAccept( Cargo, Quantity)

Now, are we seriously going to ask an AllocationChecker to deriveEnterpriseSegment? It just doesn't fit. Moreover, a few pages down the AllocationChecker is potentially becoming stateful so that it can cache the enterprise segments. Besides, the service is crying to be an object: it's taking a Cargo on every call (feature envy).

Thanks for an illuminating article on naming. Rea...

2012-02-02T13:22:09.159+01:00

Thanks for an illuminating article on naming.

Reading your article made me think of domain-driven design and "Services" in particular. From my understanding, services are typically stateless and inherently procedural in nature.

Would you agree that these should not follow your naming rules, and that even when working within the OO paradigm there are parts of the system that are best modelled procedurally, by using services, for example?

Just a couple of days ago I was watching a video b...

2011-10-12T17:12:26.114+02:00

Just a couple of days ago I was watching a video by Kevlin Henney on infoQ (http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-in-Java, from 39:00) where he covers your point about finding good names.

Yeap, I guess I'd have to redesign JSF from th...

2011-10-02T20:16:38.888+02:00

Yeap, I guess I'd have to redesign JSF from the ground up :-) to fix that. Of course, one could start by wondering why we can't just rename EditableValueHolder into "input" and start from there...

In fact, the JSF is a perfect example of "bad abstraction" (in the sense of my "cut the red wire" post) where concepts have been abstracted to the point where they bear little resemblance with the problem domain. It's not impossible to fix, but a complete overhaul would be needed...

Looking for bad examples in Java, just found java...

2011-10-01T08:35:53.975+02:00

Looking for bad examples in Java, just found

javax.faces.view.EditableValueHolderAttachedObjectHandler

I think even you can’t help it.

I would quibble about your grammar complaints--the...

2011-09-30T16:42:32.408+02:00

I would quibble about your grammar complaints--there's a long tradition and a consistent system underlying names like "MarshalByRefObject". ("We marshal these objects by reference." becomes "This is the marshal-by-reference style of marshaling.", which becomes "These are marshal-by-reference objects." The original is probably the call-by-value/call-by-reference distinction.)

Other than that, great article. Anything to avoid another AbstractKeywordRemovalInitiatorFactory....

Couldn't resist: IEnumerator -> Position, F...

2011-09-28T23:34:23.933+02:00

Couldn't resist: IEnumerator -> Position, ForwardPosition, SlidingPosition, IncrementalPosition...

Position.value() looks good to me.

wouldn't one assume that the single purpose...

2011-09-26T23:01:50.305+02:00
wouldn't one assume that the single purpose of these classes is to hold the definitions of the lexical grammar and the syntax?
---
No, unless one thinks of a class as a data structure. The behavior / responsibility of a class is exposed through meaningful methods like Check, BuildExpressionTree, etc etc for a Syntax class.

The issue with Controller is well known: you easily end up with a godlike-class controlling a lot of stupid classes. That's why so many people preach about having a skinny controller and a fat object model: because most people tend to do exactly the opposite (you never have to preach something people are already keen on doing). Unfortunately, all the logic you put in a controller is usually not reusable (controllers are normally highly customized).

I began this post with a quote from Alan Kay, one of the founding fathers of OOP. I think that whoever is honestly interested in appreciating the nuances of object orientations should spend some time pondering on early works like that. I certainly did, both because of age :-) and because I don't subscribe to the notion that being "modern" means rejecting the past :-).

As an aside: I failed to mention that I don't consider procedural programming intrinsecally "wrong" or "evil". I expect some properties from procedural code, and different properties from OO code. For instance, procedural code is often structurally simpler compared to OO code, has less delocalized plans, etc.
What I consider wrong is claiming that something is OO when it is, in fact, procedural. Fake OO code gives me the worst of both worlds. That's evil :-).

If you were to rename Lexer to LexicalGrammar or P...

2011-09-26T21:43:14.478+02:00
If you were to rename Lexer to LexicalGrammar or Parser to Syntax, wouldn't one assume that the single purpose of these classes is to hold the definitions of the lexical grammar and the syntax? That is, as opposed to actually being classes that do something.
Or would that be a result of procedural thinking as well?

Honestly, I can't seem to find the issue with names like Parser or Controller. Maybe I just have a wrong concept of what Object Oriented Programming actually entails. If so, I would honestly like to be educated on the subject.

Maybe I don't think Procedural Programming is Very Evil, as some OOP-preachers seem to say, and hence am not disgusted by names like IEnumerator.

Sliding Window...well after got it, it seems obvio...

2011-06-10T17:08:24.948+02:00
Sliding Window...well after got it, it seems obvious :S!!
Just as marginal note...maybe a SlidingItem could be good if we don't wanna change the interface and furthermore it can remind us that we are visiting a collection :)

2011-06-10T17:06:57.846+02:00
This comment has been removed by the author.

Note: I'm not claiming this is the "perfe...

2011-06-05T10:08:54.075+02:00
Note: I'm not claiming this is the "perfect" name. It's a reasonable name that is not overly focused on the procedural aspect of moving.

That said: a very common name for (c) in my previous picture is "moving window" or "sliding window" because it represents a window over a larger data set / sequence. Now, the difference between (b) and (c) is that the window is restricted to a single value. So, SlidingValue seems like a sensible name.

As an aside, a SlidingValue class would suggest a different interface. It's ugly to ask a SlidingValue for its Value :-), it should BE a Value.

About your question: sometimes, that's the natural consequence of single implementation inheritance. The (mild) pressure to add mixins or traits (not C++ traits) to SII languages is coming out directly from this kind of discomfort.
Having an interface in place is also handy for testing, and you may not want to inherit from the abstract class in that case.
Sometimes, however, the interface-abstract-concrete layering is just the consequence of blindly following "rules" and putting interfaces everywhere, without a real need. Context, as always, is the key :-)

I'm not confident i'll ever find out the n...

2011-05-28T20:38:03.334+02:00
I'm not confident i'll ever find out the names so if the author will give the solution I really appreciate :D
As a side thought, I was thinking about your statement "an interface can't really do stuff". So many times I see different project that separate interfaces from an abstract base class implementation that in the end is required as a base to each interface implementors, something like have a Figure as interface and then an AbstractFigure as an abstract class that factors common base implementation and then concrete figures derived from AbstractFigure. What do you think about that?

mmm i discarded cursor 'cause it's really...

2011-05-04T19:58:08.887+02:00
mmm i discarded cursor 'cause it's really similar to iterator (well I knew the solution had to be harder :)

But even after your picture I can't figure out how to name something that provide access to an element in a sequence and can move forward.

Honestly I can't find a name even for c) (it reminds me of "slice" but it's not the answer, I know. Maybe I'm so tired my brain is off anyway)
For now I give up...but I will try again in a more relaxed moment.

In reverse order: Anonymous : feel free to improv...

2011-05-04T15:41:21.084+02:00
In reverse order:

Anonymous : feel free to improve my wording :-)

Previous Anonymous: cursor, or the slightly more precise/verbose ForwardCursor, is indeed a reasonable option (it was also my first idea when I thought of alternative names for IEnumerator). Some would say that -or is not much better than -er (in some languages there is in fact no difference) but I still like Cursor more.

Fulvio: this may seem too much "dead poet society" :-)), like "stand on your desk to see things in a different way", but I actually think that the (traditional) choice of "head", "iterator", "cursor" etc comes from focusing too much on that thing that moves, and too little on the underlying value.

Consider this picture: it seems like most people think of (a) when presented with the concept, focusing too much on that little thing on top, and their choice of names is heavily influenced from that.

What if you draw it like (b)? Does that suggest you any alternative?

Since we're playing with this little problem, what if I change the picture (and therefore the concept) to (c)? Does it remind you of something? It's a known structure in computer science, used (with different names) in a few algorithms but also in operating systems (also at the kernel API level). A good name for (c) may suggest a good name for (b), which after all is a special case of (c).

(of course, it's much easier to turn off our brain and call it an IEnumerator, or an iterator, despite the fact that by itself is not enumerating or iterating at all; curiously enough, I've lately discovered that the wikipedia page on iterator includes a similar critic of name :-)

About the constraint checker: this is not the kind of exercise that you can solve with an educated guess :-). You actually have to design that thing to really understand the forcefield and come up with good names. Still: why is not a Constrained object checking its own constraints? Why is a checker needed at all (note that I've subtly, but intentionally, moved from IConstrained to Constrained, because an interface can't really do stuff :-).

umh, Object think-er, sound sooo like procedural ;...

2011-04-30T12:49:22.105+02:00
umh, Object think-er, sound sooo like procedural ;-)

IEnumerator -> Cursor?

2011-04-26T21:21:24.940+02:00
IEnumerator -> Cursor?

mmm well, about IEnumerator, the only image I can ...

2011-04-26T19:49:39.962+02:00
mmm well, about IEnumerator, the only image I can think of it's the head (IEnumerator) to read a magnetic tape (the sequence).

For ConstraintChecker, I have to think about it a little more, but some hints could be useful...

what is triggering a "checker"? I believe a change of state inside the object. (Am I right?)

What is the difference between a checker and a Constrained? the constrained is an object subjected to contraints, the checker (from a procedural thinking view) has the responsibility to validate constratints.

mmm i'm a little bit confused on this part of the story...

Guys: thanks :-) Fulvio: I'll start with the ...

2011-04-26T16:37:03.321+02:00
Guys: thanks :-)

Fulvio: I'll start with the simple stuff. Compiler construction is often approached with an half-hearted OO approach, where a recursive descendent parser is built using inheritance, but after that, it's all procedural programming.
However, it's quite simple to fix, basically like Peter Coad said: remove the -er, look for the "managed" object and put the responsibilities there.
Lexer -> LexicalGrammar
Parser -> Syntax
etc.
About the million dollar question, I'm afraid I don't know any. Maybe I'm spending too little time reading code :-).
About the exercises:
ForwardStride sort of loses part of the responsibility (providing the current value). I'd suggest that you try drawing a picture of the sequence and of that "thing" you are trying to name. Not a UML diagram, but a visual representation of the concept. See if you get a reasonably precise picture and if that reminds you of something :-)
The ConstraintChecker requires an overall design, you can't just try a name without assigning responsibilities. Hint: what is triggering a "checker"? What is the difference between a checker and a Constrained?

Some interesting and true facts, thanks for an ent...

2011-04-23T17:57:05.348+02:00
Some interesting and true facts, thanks for an entertaining and educative read

Naming classes and methods the right way (ie, the ...

2011-04-22T14:17:35.730+02:00
Naming classes and methods the right way (ie, the OOP way) is really something I still find rather hard. Your article was both informative and entertaining (3 cheers for the OT!).

Ok, risking a public mortification, I try to do th...

2011-04-22T11:32:33.869+02:00
Ok, risking a public mortification, I try to do the exercises :)

IEnumerator -> ForwardStride

ConstraintsChecker -> ConstraintsSatisfaction

Exercises apart, thanks for the post. I haven't managed to read most of the 'classics' yet, I really need to improve my time management :S
But let me ask a one billion question...Is there just one software that can claim to be Object Oriented (obviously I'm talking about something with public evidence)? Even in Design Patterns there are many of them called something-or (mediator, iterator, decorator, visitor) that resemble functional programming with 'fancier constructs'. Many areas of computer science have a solid background theory based on functional decomposition (I'm thinking about compiler construction, for instance, where Parser, Lexer, ASTBuilder are main concept).
Sadly, it seems that a lot of OO gurus have taken this path :(

Oop is fine as long as you don't allocate them...

2011-04-21T20:38:47.230+02:00
Oop is fine as long as you don't allocate them (see Google's recommendations) and don't activate method code iwhen retrieving values (kills performance). Also, avoid dependencies to classes of the same or higher level or your code will corrupt. Oh, and keep things simple, the KISS principle.