Amplifying on what moritz said, it is important for you to develop your own opinions and go off of them, then monitor the results. That will help you learn, and will help ensure that your designs implement the ideas in them fairly well. Furthermore in programming there are trade-offs in every decision, which means that you can construct arguments for or against opposed approaches. As you analyze your own experience, focus on what those trade-offs are. Then when you're faced with a new situation you'll be in a better position to say, "These are the ways we could go and I would prefer to do X because it is what I have done before."

With this in mind, what are the trade-offs in having search methods as class methods of the class of thing that you are searching for? The benefit is simplicity. When every class has a second class that is about how to search for those things, it becomes easy to create a twisty maze of classes, all alike. The drawback that it isn't semantically clean, and requires your class to know about all of the different ways it might be stored and organized. Conceptually that is the wrong place to put that information.

Good programmers can fall on either side of the fence. For instance if you look at the world of object relational mappers, DBIx::Class puts search methods in the object's class, while Rose::DB::Object puts searching in a manager class (but grudgingly provides the ability to create search methods in the object's class).

My personal opinion is that if you anticipate storing objects in multiple places in multiple ways, then have searching be in a different class. That will give you the flexibility to add new ways of searching in new places that require different kinds of information. If you know the data will always be stored in just one way in just one place, I would be personally inclined towards not creating a new class for the search method. Though I have no trouble using code that went the other way instead. (I do prefer Rose::DB::Object over DBIx::Class.)