views:

72

answers:

4

For illustration purposes let us say I'm building a simple blog application and have a class called Blog:

Class Blog(){
   __constructor(){
       connectToDatabase();
   }
}

Class BlogPost($id) extends Blog {
    public $title;
    public $body;
    etc.
}

The blogpost class can be instantiated as an object representing a particular blog post. But when I want to list all the records in the database I have to put that function somewhere else.

I could put it in the Blog class, but assuming I have many, many such functions that don't apply to a particular object, where should I put them?

Or maybe I'm writing a line to a log file. It seems silly to have a 'logfile' class containing a single function that writes a passed string to the text file.

Is it best practice to lump them all in some Utility() class, or should I create several classes such as util_commenting(), util_archives()? Just where should I store all those little stand-alone functions?

A: 

You could have a BlogPostRepository or a Database object, which can return all BlogPosts.

Sjoerd
A: 

That's a persistence layer object. Usually it's a data access object (DAO) or repository, not a utility or general function.

I would take that function connecting to a database out of your constructor. It does not belong there.

If I were writing this in Java, it might look like this:

public class Blog
{
    private Long id;
    private String title;
    private String body;
    private String author;
    private Date publishDate;
    // Other attributes and functions here.   
}

public interface BlogDao
{
    Blog find(Long id);
    List<Blog> find();
    List<Blog> find(Date begDate, Date endDate);
    List<Blog> find(String author);
    void saveOrUpdate(Blog blog);
    void delete(Blog);
}

There'd a class that implemented the BlogDao interface using whatever technology I wanted (JDBC, Hibernate, etc.)

duffymo
-1: The OP quite clearly does not specifically apply to DAO.
DeadMG
+1: And @DeadMG - your objection is nonsensical. If you have a better solution, by all means post an answer.
Don Roby
Did you not read the question, DeadMG? "But when I want to list all the records in the database I have to put that function somewhere else." A DAO is a perfectly good place to put that functionality.
duffymo
My apologies, I should have made myself clearer. The blogpost/database scenario is an example. I was referring to code that would not apply to an object.Maybe I'm writing a line to a log file. It seems silly to have a 'logfile' class containing a single function that writes a passed string to the text file.I just wondered what the best practice is for where to put all those stand-alone functions.
lewiswalsh
It's not silly if you're doing aspect oriented programming. If that single class is then used to advise every method in your app, I'd say that's not silly at all. My point is that you could spend the rest of the day coming up with specific examples like database access, logging, etc. and the chances are good that it's possible find a non-utility place for most of them. You sound like you haven't done enough with object-oriented programming yet. Keep reading.
duffymo
Thanks duffymo, and everyone. I've been coding successfully in OOP for a good five years and have a pretty decent grasp on it. The AOP approach is new to me but makes sense. I must confess I didn't ask the question to solve a problem more to see what different approaches people would come up with. I guess I can get a little pre-occupied with the elegance of the OOP structures.
lewiswalsh
A: 

Most of the time, free functions should just be put in a well-named namespace. If you look at the C++ standard libraries, there are a number of free functions in std (like sort, for example). You could create a blog namespace, with a blog class contained within (blog::blog) and then have other utility free functions to do with blogs in that namespace.

They don't need to go into any class and it's definitely NOT best practices to go for a singleton style.

DeadMG
+1  A: 

"Classes for Concepts" is a good aphorism to remember.

Try writing some stories/scenarios/use cases to describe how the system works.

You will likely find that the free functions fall end up in groups that are required to satisfy some of the stories.

I recommend Rebecca Wirfs-Brock's "Responsibility-Driven Design". There's a nice overview paper on her publications page.

Andy Dent
Thanks Andy, a good approach I should've remembered from my university days in those long, boring UML lessons!I certainly appreciate the push in Rebecca Wifs-Brock's direction, very interesting stuff that I think will take a few reads to really get my head around.
lewiswalsh