Help

Somehow, this silliness got linked by InfoQ. It's not really worth the effort of fisking this post, but I'm bored so I'll go ahead and do it anyway.

Active Record is a well known data persistence pattern. It has been adopted by Rails, Hibernate, and many other ORM tools.

Actually Hibernate does not implement the ActiveRecord pattern. If you really feel the need to classify it according to Fowler's taxonomy, Hibernate is a DataMapper.

There is a 1:1 correspondence between tables and classes, columns and fields. (Or very nearly so). It is this 1:1 correspondence that bothers me. Indeed, it bothers me about all ORM tools. Why? Because this mapping presumes that tables and objects are isomorphic.

Well, this may be the case with ActiveRecord, but Hibernate and most other ORM solutions are a good deal more flexible in this regard. Indeed, one of the primary goals of any ORM solution is to allow objects and tables to be non-isomorphic to the extent that this makes sense.

From the beginning of OO we learned that the data in an object should be hidden, and the public interface should be methods. In other words: objects export behavior, not data. An object has hidden data and exposed behavior.

Bizarre statement. Objects are stateful, and one of the main purposes of the methods of an object is to export that state (data) to the world.

Data structures, on the other hand, have exposed data, and no behavior. In languages like C++ and C# the struct keyword is used to describe a data structure with public fields. If there are any methods, they are typically navigational. They don’t contain business rules.

I don't believe that the word data structure implies anything at all about behavior. Certainly it does not imply no behavior.

Thus, data structures and objects are diametrically opposed. They are virtual opposites. One exposes behavior and hides data, the other exposes data and has no behavior. But that’s not the only thing that is opposite about them.

Whoah! Diametrically opposed! Really?

On the contrary, most people I know would view an object as a package of:

  1. a data structure, and
  2. functionality that operates upon that data structure.

The data is an intrinsic part of the object; not its diametric opposite.

Algorithms that deal with objects have the luxury of not needing to know the kind of object they are dealing with.

This is not true.

The old example: shape.draw(); makes the point. The caller has no idea what kind of shape is being drawn.

Correct; the old example makes the point perfectly: the caller knows very precisely that the type of thing it is drawing is a Shape.

algorithms that employ objects are immune to the addition of new types ... objects are not immune to the addition of new functions ... Algorithms that use data structures are immune to the addition of new functions ... algorithms that employ data structures are not immune to the addition of new types ... Those portions of the system that are likely to be subject to new types, should be oriented around objects. On the other hand, any part of the system that is likely to need new functions ought to be oriented around data structures.

This is all predicated upon a false dichotomy between Objects and Data structures. In truth, there is no need to orient ourselves toward one view or the other in any particular part of the system.

Rather, we take advantage of subtyping (inheritance/polymorphism) when we design our object model. By carefully design of the type hierarchy, we allow our system to accommodate the introduction of new types and new behaviors.

Again, note the almost diametrical opposition. Objects and Data structures convey nearly opposite immunities and vulnerabilities.

Repeatedly asserting a false dichotomy does not make it true.

The problem I have with Active Record is that it creates confusion about these two very different styles of programming.

There is only one style of programming.

A database table is a data structure. It has exposed data and no behavior.

Correct.

But an Active Record appears to be an object.

Correct. An ActiveRecord is an object.

It has "hidden data", and exposed behavior. I put the word "hidden" in quotes because the data is, in fact, not hidden. Almost all ActiveRecord derivatives export the database columns through accessors and mutators.

There appears to be a deep confusion here about exactly what is supposed to be hidden. It is not state, nor data, that must be hidden, it is implementation details. Not the same thing at all.

And products like Hibernate certainly do not require that database columns be exported via accessors and mutators. Persistent attributes may be private if appropriate. State (data) can be hidden or exposed depending upon what is required by client code.

Indeed, the Active Record is meant to be used like a data structure. On the other hand, many people put business rule methods in their Active Record classes; which makes them appear to be objects.

Again with the false dichotomy.

This leads to a dilemma. On which side of the line does the Active Record really fall? Is it an object? Or is it a data structure?

It is both. There is no line.

This dilemma is the basis for the oft-cited impedance mismatch between relational databases and object oriented languages. Tables are data structures, not classes. Objects are encapsulated behavior, not database rows.

The impedence mismatch is between the different modelling constructs available in the two paradigms.

The problem is that Active Records are data structures. Putting business rule methods in them doesn’t turn them into true objects.

On the contrary, a data structure, together with business rule methods is the very definition of an object.

In the end, the algorithms that employ Active Records are vulnerable to changes in schema, and changes in type. They are not immune to changes in type, the way algorithms that use objects are.

Any object-oriented code is vulnerable to changes in the type system. To argue that algorithms that use objects are invulnerable to changes in type is absurd in the extreme.

You can prove this to yourself by realizing how difficult it is to implement an polymorphic hierarchy in a relational database. It’s not impossible of course, but every trick for doing it is a hack. The end result is that few database schemae, and therefore few uses of Active Record, employ the kind of polymorphism that conveys the immunity of changes to type.

Nonsense. Traditional data modelling has powerful, elegant methodologies for modelling subtyping, and modern ORM solutions like Hibernate are easily able to map between the relational and object-oriented approaches to subtyping.

So applications built around ActiveRecord are applications built around data structures. And applications that are built around data structures are procedural—they are not object oriented. The opportunity we miss when we structure our applications around Active Record is the opportunity to use object oriented design.

Persistent classes embody inheritance relationships and subtyping. There are many opportunities to take advantage of object oriented design priniciples. If your ORM solution doesn't support inheritance, get one that does.

Applications should be designed and structured around objects, not data structures. Those objects should expose business behaviors, and hide any vestige of the database. The fact that we have Employee tables in the database, does not mean that we must have Employee classes in the application proper.

The fact that we have employees in the business domain, and a notion of Employee in our business domain model implies that we will almost certainly have an EMPLOYEE table and Employee class in the object-oriented and relational realizations of this model.

We may have Active Records that hold Employee rows in the database interface layer, but by the time that information gets to the application, it may be in very different kinds of objects.

This is extremely unlikely. Both the relational schema and the object model are representations of the same entities that exist in the business domain. These entities exist in all layers of the application, from the user interface, all the way back to the database.

I am not recommending against the use of Active Record. As I said in the first part of this blog I think the pattern is very useful. What I am advocating is a separation between the application and Active Record. Active Record belongs in the layer that separates the database from the application. It makes a very convenient halfway-house between the hard data structures of database tables, and the behavior exposing objects in the application.

Oh wonderful. This stuff was all just an excuse for more useless layerism? Please, enough layers already!

So, in the end, I am not against the use of Active Record. I just don’t want Active Record to be the organizing principle of the application. It makes a fine transport mechanism between the database and the application; but I don’t want the application knowing about Active Records. I want the application oriented around objects that expose behavior and hide data. I generally want the application immune to type changes; and I want to structure the application so that new features can be added by adding new types.

The application should be oriented around the business domain model. Objects are an implementation detail.

26 comments:
 
08. Nov 2007, 22:46 CET | Link
Sakuraba
As I said in the first part of this blog I think the pattern is very useful. What I am advocating is a separation between the application and Active Record. Active Record belongs in the layer that separates the database from the application.

So the author of this blog post is advocating to separate persistence logic from the rest of the application. But how the F is he then going to design a web-app for that application? How does he e.g. create some CRUD pages if he does not want to propagate the /fields of the domain objects (= rows of the tables) to the web layer? How will he handle validation of those fields?

Personally I think it is the best thing to spend a lot of time on JPA entities to structure them in the absolute best way possible. Entities will be used all around the appliction and the less the application knows about the entities, the more boilerplate code will be necessary to achieve what a well thought mapping could have solved in the first place.

Separating these aspects is only gonna make it worse IMO.

ReplyQuote
 
08. Nov 2007, 23:03 CET | Link

The fundamental tenet of Object Orientation is that the state of an object is not exported out through the public behavioral API.

one of the main purposes of the methods of an object is to export that state (data) to the world

Actually, this is incorrect. One of the main purposes of methods on an object is to invoke messages (behavior) and possibly, though we won't know or care due to encapsulation, change the internal state of that object.

But, given that the state is encapsulated, I don't really care if it changes. Just that the message I've dispatched on the object has triggered the desired behavior.

The primary purpose of encapsultation is that an object manages its state for itself and clients of the object shouldn't care or know what that state looks like, how its represented or be able to access it directly to change it.

I disagree with your understanding or interpretation of OO.

 
09. Nov 2007, 00:37 CET | Link
The fundamental tenet of Object Orientation is that the state of an object is not exported out through the public behavioral API.

You got the whole encapsulation thing backwards. Read this: http://www.dbpd.com/vault/9809date.html

 
09. Nov 2007, 02:23 CET | Link
Toby
You got the whole encapsulation thing backwards.

Maybe not? Read this: http://www.pragprog.com/articles/tell-dont-ask

 
09. Nov 2007, 02:37 CET | Link
Read this: http://www.pragprog.com/articles/tell-dont-ask

I just read it. The author's main point is:

you should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do.

Nothing I disagree with here. This does /not/ say that an object should not expose its state.

It certainly does not prove that a persistent entity cannot be an object! I can certainly add methods to my entities which make decisions on the basis of their state. In fact, that is what I do, and what I'm arguing is the correct thing to do.

It is the author of the original article who argues (incorrectly) that this is impossible.

 
09. Nov 2007, 02:45 CET | Link
The fundamental tenet of Object Orientation is that the state of an object is not exported out through the public behavioral API.

Nonsense. Objects expose state to their clients. Otherwise ... what is the state for? If the clients could never detect the state of the object, it would be effectively stateless, and hence effectively not an object.

What you've done is you've misunderstood the definition of /encapsulation/. Encapsulation is about hiding /implementation details/.

As a result you're confusing two totally different issues:

  1. does the object expose its state?
  2. does the object expose its own internal representation (implementation) of its state?

The answers are of course to 1 and preferably not to 2.

Of course, an object /abstracts/ its own internal representation of its state, through a well-defined interface, but that does not mean it never exposes its state.

You've muddled state with instance variables, just as the author of the original article did.

 
09. Nov 2007, 03:05 CET | Link

Oh, question for the people who think that object orientation means never exposing state: does this mean that /you personally/ would never write a getAddress() method on your Employee class?

Because if you can't answer yes to this question, I'm forced to conclude that you don't /actually/ believe what you're arguing here.

 
09. Nov 2007, 03:23 CET | Link
Joshua E Cook

Alan Kay states that one of the properties of his definition of OOP is “protection and hiding of state-process.” It’s easy to gloss over the word “state-process” and presume he just meant “state,” but to me that means that what is being hidden is the way in which an object’s retained state determines its behaviour.

The other properties he mentions are “messaging, local retention, ... and extreme late-binding.” The only indication of an object’s state from the perspective of a client is how the object responds to a message. That is, an object’s behaviour is an observable, external representation of its state.

 
09. Nov 2007, 04:24 CET | Link

LOL. I think that was the funniest persistence post. Ever. The original author sure sounds a bit confused with the ideas behind objects, polymorphisms, and encapsulation.

 
09. Nov 2007, 04:49 CET | Link
javakid

the only silly one here is you for being so ignorant!

 
09. Nov 2007, 05:08 CET | Link

There is a lot to be argued wrt the original post, but debating Object Orientation fundamentals with Robert C. Martin is just hilarious.

This comment

The original author sure sounds a bit confused with the ideas behind objects, polymorphisms, and encapsulation.

really made me laugh out loud.

I know that I'm making an argument by authority, but one shouldn't treat the guy that coined the Single Responsibility Principle as a random blogger!

Anyway, back to the subject at hand, I believe Robert Martin did indeed make a mistake in bundling together Active Record, Data Mapper and Row Data Gateway, to stick with Fowler's categorization (which I find useful). They are different and have different applicability.

But, OTOH, Gavin's:

I don't believe that the word data structure implies anything at all about behavior. Certainly it does not imply no behavior

is just silly.

 
09. Nov 2007, 05:11 CET | Link
Vincent

He, He It's funny to see what happens when people are forcefully looking for ways to disagree.

 
09. Nov 2007, 06:36 CET | Link
John "Z-Bo" Zabroski | johnzabroski(AT)yahoo.com

Gavin King is simply trying to tease away the assumptions that are contained in Robert Martin's blog entry. I appreciate it. I am 23 years old, and I have found the OOP education I received in high school, college and some books to be incredibly /not useful/ and tangled in assumptions that limited my thinking. Now, modeling notions are not wrong, but /modeling notions are more or less useful/. The more assumptions and prejudices one's knowledge accumulates, the less free one is. I've heard various /definitions of an object that limited my thinking freedom/.

The first definition I heard of an object was that it was /data and methods/. However, /data and methods/ has an assumption that all methods should be member functions. It also directs away attention from the primary objective: maintainability. Objects are more maintainable when they encapsulate implementation details. There are four levels of specification: defined, implementation-defined, unspecified, and undefined. Usually, in TDD (Test-Driven Development)or BDD (Behavior-Driven Development) the spec is spelled out in unit tests. In Cleanroom Software Engineering, the spec is spelled out with assertions and controlling scope to determine what side-effects are merely implementation defined. In either testing paradigm, the goal is to hammer down what is defined and what is merely arbitrary. Doing so enhances maintainability and lets the maintenance programmer correctly refactor code, teasing away assumptions that were placed in the code, usually due to project schedule pressure.

My next definition of an object was that an object is defined by what it does, not how it does it, paraphrasing Allen I. Holub. Holub also wrote a very controversial article, /Getters and setters are evil/, that was expanded and revised in his book /Holub on Patterns/. Allen basically proselytizes tell-don't-ask, although he goes much further than that be emphasizing problem decomposition using CRC (Class-Responsibility-Collaboration) Cards. However, even Allen acknowledges this /Message-oriented programming/ restriction can be too limiting in some cases, and recommends getters and setters are extremely practical wherever you place your boundary layers. Specifically, wherever side-effects are necessary for practical reasons.

/Message-oriented programming/ isn't very different from /data and methods/ from an architectural extraction viewpoint; it's just adding a layer of indirection where the data can only be manipulated through messages. In fact, in well-designed systems, /message-oriented programming/ is essentially dual to /data and methods/. We're not advancing the description of the external problem application domain, and we're not advancing a reflective architecture for re-use of effort and separation of concerns and explicit flow of data for fine-grained security. The difference between /message-oriented programming/ and /data and methods/ is wrist gestures and handy poses.

Additionally, the /data and methods/ definition of an object often interferes with maintainability because it does not always make sense for a method to be bound to data. In practice, I've learned non-member friend functions can enhance encapsulation, decrease coupling and increase cohesion. Moreover, binding methods on a structural subtyping basis (like Java interfaces) also does not always capture the external problem domain in the DRY-est manner. The Java interface notion is a limited form of generic programming championed by Alexander Stepanov and David Musser because it limits constraints that can be placed on types. When organizing the structure of code, it's more likely we never want to organize things using static interfaces. Static interfaces are extremely limiting; coding decisions are rarely ever static. That's why metaprogramming and computational reflection is so essential to addressing many organizational concerns.

The next definition of an object is All You Can Do Is Send A Messsage, or the Actors model. This is actually a pretty useful model, because it minimizes state and maximizes state-process by using processes to enforce explicit data flow, thereby allowing the creation of well-defined containers for untrusted software. Again, this is basically /message-oriented programming/ except it reduces locks, a concept that I consider external to the definition of an object. However, it also doesn't say anything explicitly about security. So, this definition of an object provides a model that is useful for concurrency but could use some improvements for security; the Actors model doesn't really saying anything about the environment it runs in.

The final definition of an object is a pure capabilities model, and that defines what is trusted code and what is untrusted code in each operating environment. That gives us increased leverage to define who gets to do what to our computers or /business systems/. Come to that, visibility modifiers like public, protected and private are also represent static interfaces and perhaps limiting, although perhaps limiting in a good way: some things should probably be strictly consistent from system to system to promote testability; We have enough unit tests to write, even if we can pay $50K US for a tool to automate a bunch of the tests. Still, these visibility modifiers present their own problems for properly testing code and versioning systems, particularly when using third-party libraries (more untrusted code).

Now, I have a bone to pick with this:

Robert Cecil Martin said: A database table is a data structure. It has exposed data and no behavior.

Gavin King said: Correct.

I do not understand either Robert Cecil Martin or Gavin King on this point; both seem rather silly to me. Going back to E.F. Codd, it seems like the unique feature of the relational model is that it is a closed system: it can store the definition of its own structure (so-called internal data dictionary) and also store the rules for enforcing so-called row-level security, column-level security and cell-level security. All of these definitions and rules are contained within the database itself, and thus we can say the database can defend itself. A properly designed database schema defines a very rigid and uncompromising way for users to interact with it. Any side-effects caused by the persistence layer writing to a relational data store are valid; we've ensured /data correctness/ through our schema. The application therefore should not be subvertible.

Object-oriented /modeling/ in general is subjective, as I've just shown above by tracing through various views of an object, but the relational model is not. When should you use composition and when should you use inheritance? I can't provide you a mathematical answer; it is subjective. OOP is merely intuitively appealing, whereas the relational model is calculative: the distinction between a normal schema and a denormalized schema is clear. Therefore, I can provide consistent modeling principles for you to practice relational modeling, but I can't do this for object-oriented modeling. At best, I'll point you to some principles Robert Cecil Martin wrote about, or I'll point you to Martin Fowler's /Analysis Patterns/.

Whew, I almost exhausted the character count.

Have a good day, Gavin! :)

 
09. Nov 2007, 07:12 CET | Link
But, OTOH, Gavin's: "I don't believe that the word data structure implies anything at all about behavior. Certainly it does not imply no behavior" is just silly.

Really? Then please find me a definition of the term data structure that says a data structure cannot define its own behavior.

Actually, don't bother, I'm not interested in getting into an argument over the meanings of words with you, especially not when you're totally ignoring the use of the term in the context of the original article!

In the original article, the author explicitly declares that Active Records are data structures. /Clearly/ Active Records in Ruby, or entities in Hibernate can have behavior. So either:

  1. data structures can have behavior, or
  2. entities (Active Records, if you prefer) are not data structures

It's up to you. Either way, the article is absurd.

 
09. Nov 2007, 07:15 CET | Link
I know that I'm making an argument by authority

Yes, you are. Make a real argument instead.

 
09. Nov 2007, 08:17 CET | Link
John "Z-Bo" Zabroski | johnzabroski(AT)yahoo.com
Really? Then please find me a definition of the term data structure that says a data structure cannot define its own behavior.

I remember talking to my friend about the title of Niklas Wirth book, /Algorithms plus Data Structures equals Programs/. The title is significant. In 1976, the title reflected a common view of program organization. Recently, books on this classical subject would be titled, /Data Structures plus Algorithms equals Programs/. I then told my friend: But that's an incomplete view, and we're not done yet evolving. I then explained that many data structures and algorithms are subservient to /data flow/ first. One of life's most disagreeable tasks -- waiting in line -- is the delightful subject of queues (quoting Leonard Kleinrock). Sometimes a surrogate function or fully encapsulated object is necessary when data flow is more important than structure. Mainly, I think this applies to places where policy is maintained rather than mechanism improved. I think structure is where mechanistic advances can take place.

This is something I only thought about when doing a software architecture extraction on a code-base with an undocumented architecture and a lot of copy-and-paste programming resulting in Rogue Tile bug patterns. I couldn't rewrite the application from scratch because there was not sufficient documentation and it was not cost-effective to use a domain expert. I had to break down the application piece by piece, and some of the most important information pertained to data flow. It seems as though people underestimate the importance of analyzing data flow in design, or they realize it but understate it. For instance, when I read /Analysis Patterns/, I often felt Martin Fowler was /understating/ the importance of data flow when explaining how these object analysis patterns came about.

 
09. Nov 2007, 09:59 CET | Link
Yes, you are. Make a real argument instead.

If you ask so nicely, how can I refuse. My opinions:

  • There is no One True Architecture. Specifically wrt persistence, all patterns in PoEAA can be useful at times. Tool support is important.
  • Close coupling between DB and Model is bad. I'll expand on that later.
  • I'm weary of Active Record à la Rails, because of the last point, but it may be useful at times.
  • I think a Data Mapper based on Hibernate, maybe exposed through a thin DDD-like repository, is a very widely applicable architectural choice. It represents a sweet spot on the Complexity vs. DB-Coupling scale.
  • Getting back to Robert Martin's article, I think that using Active Record (the pattern or the framework) as a glorified DTO between a persistence layer and the model is a very weird choice.
  • As I've mentioned, I think he wasn't clear when bundling Hibernate, Data Mapper and RDG with Active Record.
  • His use of data structure seemed pretty clear to me. He was referring to procedural-style data-separated-from-behavior. This is often accompanied by a type case test on the functions that handle those structures. Think of his use of Data Structure as a definition, not a characterization (the term is very broad) and re-read the article.
  • This is in contrast to mainstream OO modeling, where behavior resides on objects and typecases are replaced by polymorphism.
  • The issue of whether a (semi)automated mapping between a relational schema and an OO model impacts on the flexibility of said model to the point of limiting the designer is a complex question. I don't think there is a simple Yes or No answer. You said
This is extremely unlikely. Both the relational schema and the object model are representations of the same entities that exist in the business domain. These entities exist in all layers of the application, from the user interface, all the way back to the database.

And I think this is a valid point (possibly the best you've made in this post, IMHO), but it does not answer the question once and for all (see my first point).

To summarize, I think Robert Martin's points regarding persistence are arguable, but his understanding of object orientation is beyond reproach. Not only because of who he is (the argument by authority that you so disliked), but based on what he wrote on the article itself. From my POV, your qualification of a statement as bizarre is very likely to result from some difficulty in communication.

Good night.

 
09. Nov 2007, 12:04 CET | Link

Some of your points are valid. But Bob clearly indicates in his discussion of data structures that he's talking about them as they appear in C

 
09. Nov 2007, 12:04 CET | Link
His use of data structure seemed pretty clear to me. He was referring to procedural-style data-separated-from-behavior. This is often accompanied by a type case test on the functions that handle those structures. Think of his use of Data Structure as a definition, not a characterization (the term is very broad) and re-read the article.

Well that's fine. He can define /data structure/ to mean anything he pleases. But it is then /incumbent upon him/ to demonstrate that ActiveRecords or Hibernate entities are data structures and not objects. Which he did not even try to do. And I think that any effort to do so would be doomed to failure. What property of objectyness is not satisfied by a Hibernate entity? It has state, behavior, inheritance, it is encapsulated, it is an instance of an abstract data type, etc.

Instead, he simply /asserted/, absent of justification, that an ActiveRecord is a data structure, and left the rest of us guessing as to why that might be the case. And that's why the post was silly.

 
09. Nov 2007, 17:45 CET | Link
Paul Beckford

Hi Gavin,

Wow... How many years working on an ORM solution and you still don't know what and Object is?

This is the problem with hybrid OO languages like C

 
09. Nov 2007, 22:57 CET | Link

The fundamental flaw I see with the original article is the premise that behavior versus data structure is a black or white quality. Bill Venners points out that it is really a spectrum and that most objects are a blend of the two qualities: Service-Oriented Objects

Also, just to clarify Holub's position a bit: According to his view, having a getAddress() method could be good or bad, it all depends on the return type. String getAddress() would be bad, Address getAddress() would be fine. In his prescription, method arguments and return types should be domain objects (abstractions), not strings and ints and such. At the boundary layers, e.g. in the UI, it is okay to pull out all the strings and ints to diplay them (although he discusses some alternative patterns to avoid this too).

 
10. Nov 2007, 00:55 CET | Link
Wow... How many years working on an ORM solution and you still don't know what and Object is?

Nice one, Paul. I don't know what an object is. Right.

This from the guy who argues here and here that we should use HashMap to model our entities.

And FYI, I learned OO from SmallTalk. I have never been a C or C++ developer.

 
10. Nov 2007, 07:46 CET | Link
Objects expose state to their clients. Otherwise ... what is the state for?

Alan Kay was quoted before. You can find the full interview by Stefan Ram here: http://userpage.fu-berlin.de/ram/pub/pubjf47ht25Ht/dockayoopen Alan Kay coined the term

 
10. Nov 2007, 08:19 CET | Link

(sorry, the blog software swallowed the url)

Alan Kay coined the term object-oriented decades ago and I don't see a reason to redefine it now. He was also the co-author of Smalltalk.

Either this is a practical joke or you are absolutely ignorant.

10. Nov 2007, 11:15 CET | Link

My thoughts about OO is an abstractive concept being implemented in SmallTalk, C/C++, Java the concept matters.

Am not considering myself an 00 guru but I did some minor work with. What I would notice is that historically ppl never agreed upon concepts interpretation. But what really chokes me that some guru tries to get us back to the dark days and resist the changes just because they can't achieve any real interpretation of the concepts and with the hero attitude they decide Am gonna go my way! and throw us back to the days of Stringifie everything!.

While someone presenting a genius idea of throwing out of the window objects, ORMs, and all the artifacts your cherishing for the sake of “back to basics” with hashmaps let me think! Oh I have some genius Idea me too! At run time get the ddl, parse it, some templating, generate objects, let's do some AOP/DI acrobatics and introduce behavior on them, wire everything in XML and your done with your killer framework.

Back to 2003 I meet some sweetie framework called Hibernate and it was a revelation, present it to co-workers and that's what we are all using now! I feel fine I have grown without handicaps or child illness and now enjoying the bittersweet taste of JPA.. Gavin, we need more on the road to keep us walking!.. Yes he's my hero! and definitely I don't know what an Object is. Am Glad hibernate do, jsf do, EL do, Seam do, and do it right! I no longer have to care!

With my best wishes of a cold wake up far from hash-ing :)

Daoud AbdelMonem Faleh

 
18. Nov 2007, 23:26 CET | Link

Robert Martins views on OO are always interesting, the guy knows his stuff.

Having said that I do think that, as a DDD advocate, exposing some state is part of life. Ultimately if you are writing a CRUD system then you have to expose some aspects of your objects, for example to the GUI components and to the persistence framework.

Take displaying your objects. You could actually have your domain objects get passed an interface that they would render them selves onto. Think this is ridiculous, fine, but many don't. I personally don't go for that sort of approach, but it is valid.

Anyway this is a big topic, but I would point people at Martin Fowlers excellent post on when getters are not actually evil (which boils down to the same thing): http://martinfowler.com/bliki/GetterEradicator.html

Post Comment