Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
do you have a public constructor? or can you allow the db interface layer to instantiate the objects directly –  ratchet freak Nov 2 '13 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? –  Buttle Butkus Nov 4 '13 at 23:07

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
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. –  Buttle Butkus Nov 4 '13 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 '13 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.

share|improve this answer
    
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 '13 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! –  Buttle Butkus Nov 4 '13 at 23:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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