I have a baseClass where I do not want public setters. I have a load($id) method that will retrieve the data for that object from the db.

I have been using static class methods like getBy($property,$values) to return multiple class objects using a single database call. But some people say that static methods are not OOP.

So now I'm trying to create a baseClassCollection that can do the same thing. But it can't, because it cannot access protected setters. I don't want everyone to be able to set the object's data. But it seems that it is an all-or-nothing proposition. I cannot give just the collection class access to the setters.

I've seen a solution using debug_backtrace() but that seems inelegant. I'm moving toward just making the setters public.

Are there any other solutions? Or should I even be looking for other solutions?

  • do you have a public constructor? or can you allow the db interface layer to instantiate the objects directly Nov 2, 2013 at 23:40
  • The constructor is public, taking an integer $id to load the object from the db. I think the core of my problem is that I want to load multiple objects with one db query. I need something that can get the data, then instantiate a bunch of the target object. But how can I give a class that power without making methods public to every class? Nov 4, 2013 at 23:07

2 Answers 2


Your Domain class (let's say a Book class) loads itself from the DB? I'd rather avoid that, because this way you mix up the domain model with persistence code.

However, to your question: what I've seen in some frameworks in Java is that they define a public interface (in your case defining getters), and the implementation class has only, let's say, package accessibility. The receiver of the instance sees only the interface and thus can only access the getters, while the creator has full control over it. This requires to have different packages with different visibility, which is probably hard to maintain.

Another way could be (if you are not developing a framework) to make the setters public, but define a general design rule like "Setters may be used by DAOs only". It must be possible to define and communicate such a simple rule to your team to make it work on a long term.

  • I'm experimenting with different methods of loading and right now I have several co-existing. All of my properties are non-public, but many classes have public get/set. Sometimes I havec onstructors that take a db id for existing data and 0/null to create new. Sometimes I have a static method that can save multiple data entities at once. Sometimes I have an object save() method. This is all still pretty new to me. Nov 4, 2013 at 23:03
  • @ButtleButkus for persistence, you probably should take a look at the DAO pattern. I often use a simplified version of it (without interfaces), because almost every time you are not going to change that.
    – Andy
    Nov 5, 2013 at 11:10
  • Static methods aren't automatically non-OOP. If they improve encapsulation or reuse value, they're probably fine. In general, the interface to a class includes all the routines that work together to carry out that class's work, even if they are static or non-member. Scott Myers wrote a DDJ article on non-members, for example.

  • Different languages have different levels of support for access restrictions. In C++, you could use the named constructor idiom, but make the static construction members (e.g., static baseClass newClass(...)) private. Then no one can create instances of baseClass. Then make the baseClassCollection a friend of baseClass and baseClassCollection will be able to create baseClass instances from the database using the named constructor.

  • I personally avoid static methods for two reasons: 1) they are harder to test in unit tests and 2) they often indicate that encapsulation is not correct. Think of those two: static: Book.loadFromDB() and non-static: new BookDAO().loadFromDB(). The latter is definitely the better option and there is no need to make it static.
    – Andy
    Nov 3, 2013 at 10:56
  • I was using a lot of static methods for loading multiple objects. You don't have to use public setters. You can do one database call and load thousands of objects. If I use an object.loadFromDB(), then I have to call it on each one. The OOP solution would seem to be a collection class whose loadFromDB() method would achieve the same result. But then I have to make the setters of the base class public to everyone! Nov 4, 2013 at 23:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.