OO CFML Design Question

[Clarke Bishop]

I am trying to think through a design question, and I'm hoping you
might be able to point me in the right direction.

I am accessing a blog via an API. I want to be able to create various
data objects like Blog, Post, and Comment.

But, shouldn't the objects be abstracted and encapsulated separate
from the actual blog API?

So, I think I need a blogAPIgateway to wrapper the actual blog API. Is
this right?

But then, which object is created first and then creates other
objects? I think I'd have to create the APIgateway first, then have it
create, read, or update the other data objects. Is this right?

Thanks for your guidance and for putting up with all my questions!

Clarke

[Sean Corfield]

You're overthinking things trying to reach the "perfect" OO design. No
such design exists. Every choice you make will have different
tradeoffs.

You haven't given us much information about this blog API: Does it
exist already? What data format does it use? (XML, JSON, something
else)

If you're designing the API yourself, start there and don't worry
about implementation (stub the implementation for testing). Build a
client app and make sure the API works well for clients. Write lots of
tests!! In fact, consider using a TDD approach and writing the tests
for the API _first_ so you can get a sense of what using the API would
be like, _then_ write the API with stubs, then start to implement the
API methods for real. Don't strive for a perfect design, try different
things and let it evolve organically under a strong set of tests.

It might be that the most effective design is a single CFC that
encapsulates "blog" - you might not need "post" or "comment" to exist
independently.

Consider how your data store might affect your implementation. In a
document store (CouchDB, MongoDB), you'd probably have a document for
each blog post but the comments and tags would be embedded in that
single document type (i.e., a comment cannot exist outside the context
of a blog post). The blog would (mostly) be just a simple collection
of posts, with perhaps a document to describe the overall blog (title,
about, etc).

Hope that helps?

[Clarke Bishop]

Thanks Sean! You're probably right about me overthinking this. It's just
that I'm trying to think it through some before I write too much code.

Here's some more information. The initial use case is that I want to import
Wordpress content into Hubspot's blog. Hubspot already has a blog API
(http://docs.hubapi.com/wiki/Blog_API_Methods )that uses either XML or JSON.
I'm planning to use XML as that's more comfortable for me, and I don't think
it really matters.

I have already written test code that calls all the api functions, and now
I'm looking to organize that code in a way that will be flexible. I don't
know exactly what all I'll need to do, so I'm trying to design in as much
flexibility as I reasonably can.

Your comments definitely helped! If you see anything else from what I've
added, please let me know.

Also, your message triggered another question. You talked about a "single
CFC that encapsulates "blog." In CFML would that look like a struct for
blog. Then, inside the blog struct there would be an array of posts where
each post was a struct. Or, would you still make separate blog, post, and
comment objects that would be created and encapsulated in the single CFC?

Thanks again for all your help!

Clarke

Hope that helps?

--
You received this message because you are subscribed to the Google Groups
"Object-Oriented Programming in ColdFusion" group.
To post to this group, send email to coldfu...@googlegroups.com.
To unsubscribe from this group, send email to
coldfusionoo...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/coldfusionoo?hl=en.

[Sean Corfield]

On Thu, May 26, 2011 at 11:53 AM, Clarke Bishop
<cbi...@resultantsys.com> wrote:
> Thanks Sean! You're probably right about me overthinking this. It's just
> that I'm trying to think it through some before I write too much code.

That's what TDD is all about :)

Making sure you don't write code without a good sense of what it
should look like, by virtue of having written tests to describe how it
should behave and how it should be structured.

> I'm looking to organize that code in a way that will be flexible. I don't
> know exactly what all I'll need to do, so I'm trying to design in as much
> flexibility as I reasonably can.

Ah, you're violating the KISS / YAGNI principles. You're over-designing.

Build the simplest thing that works and evolve from there, as you need
it. All the Agile folks will tell you the same thing.

By "trying to design in as much flexibility as [you] reasonably can"
you're over-thinking by definition.

> Also, your message triggered another question. You talked about a "single
> CFC that encapsulates "blog." In CFML would that look like a struct for
> blog. Then, inside the blog struct there would be an array of posts where
> each post was a struct. Or, would you still make separate blog, post, and
> comment objects that would be created and encapsulated in the single CFC?

You're mixing implementation and design issues.

How do you want people to be able to manipulate what you're building?
Do you need comment objects to exist separate from blog post? Why?

My suggestion was mainly for a single CFC as the API for the blog but
now you've provided more information, I'd probably identify the blog
posts as the most important entity and model those (a Post.cfc) and
treat the comments as an attribute of those (unless experience later
determines they need to be modeled separately, which I doubt, on a gut
level). Based on what you've provided so far, I'd probably lean to a
BlogSettings.cfc, a Post.cfc and a BlogService.cfc that orchestrates
operations. But I wouldn't build them until my tests indicated I
needed them to make the system work.

The main thing to remember is that there's very little business logic
in a blog so there's very little to model, which means you don't
really _need_ many objects. Objects are good for modeling important
business entities that have state-plus-behavior but if you turn
everything into an object, you end up with Java (and why are so many
new languages coming along based on the JVM that programmers are
flocking to? That's right, to get away from Java :)

Read this page of quotes from Alan Kay: http://en.wikiquote.org/wiki/Alan_Kay

In particular:

"Simple things should be simple, complex things should be possible."

"Actually I made up the term "object-oriented", and I can tell you I
did not have C++ in mind." -- and I think this applies equally to Java
:)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Baz]

Hey Clarke,

Shouldn't the objects be abstracted and encapsulated separate

from the actual blog API?

Yes, that's how I would go about doing it. Business objects like Blog, Post, and Comment, should be modeled without any consideration for where or how they are persisted, nor include code to persist themselves (at a minimum, because the API will likely need additional objects or parameters not encapsulated in your object). 

So, I think I need a blogAPIgateway to wrapper the actual blog API. Is
this right?

That's what I would do. That way you can comfortably adjust it when the API changes, or swap it out if you decide to use your own db. I would have it be a singleton saved in the application scope and instantiated only once. I would call it BlogGateway or BlogDAO.

But then, which object is created first

It doesn't matter, but one way is to load the BlogGateway at app startup. Or you could use Coldspring to help you manage dependencies and lazy-load your singletons.

 

[which object] then creates other objects?

The BlogGateway could potentially create the business objects (Blog, Post, Comment) - certainly the business objects should not create the BlogGateway. Another way would be to create your business objects in the controller or service, then pass them into to your blogAPIgateway as necessary. You can create them with a straight createObject(), or have a factory (either custom, or Coldpsring, etc.) create them for you.

 

I think I'd have to create the [BlogGateway] first, then have it

create, read, or update the other data objects. Is this right?

That's right, or:

load(Post)  , save(Post), delete(Post)  <-- business objects created in controller/service and passed into gateway

or:

load(PostID), save(Post), delete(PostID) <-- business objects created in gateway

You can also have non-crud methods in there to run queries, searches, etc. No need to separate those out if you don't want to; whatever makes sense with how the API is laid out or your model is structured.

Hope that helps,

Baz

[Clarke Bishop]

This is very helpful – Thanks!

 

   Clarke

 

From: coldfu...@googlegroups.com [mailto:coldfu...@googlegroups.com] On Behalf Of Baz
Sent: Thursday, May 26, 2011 9:59 PM
To: coldfu...@googlegroups.com
Subject: Re: [coldfusionoo] OO CFML Design Question

 

Hey Clarke,