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 am working on a Selenium + java project where all Web Element in a class are declared as -

public class CheckoutPaymentConfirmpage extends WebPage{

public final Button btnPrintorder = new Button("//input[@id='but_Print']");
public final TextField txtpassword = new TextField("password", "//input[@id='pass']");

    // Some more elements here
    // Some page object methods here
}

Now when ever test need to access these elements they are directly invoked over the object of CheckoutPaymentConfirmpage class What ever little java (or OOPS) I know, has taught me that members should be as hidden as possible. Hence I would have had btnPrintorder and txtpassword declared private and would access them using getters or would have created methods in page object class to be used by tests.

But when I convey this to others they don't see much value in it as state of instance variable (i.e. btnPrintorder etc) would not be changed from one object to another for page object class (i.e. CheckoutPaymentConfirmpage etc)

Hence in this situation, is it ok to leave instance variable as public?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

Page Object elements should be private. The issue, especially with respect to the Page Object pattern, is that public objects expose their methods, not the page object's methods. If the page object's method would just be clickPrintButton(), there's not much difference, but imagine instead a printOrder() method that needs to click the button and wait for a confirmation message to appear. And even in the simple case, ask yourself what other methods can be applied to a Button object, and do you want the consumer of the CheckoutPaymentConfirmpage to use them.

share|improve this answer
    
This is a problem with how the objects are designed. The button should be smart enough to know that it is attached to a parent object, so that if the click method is invoked on it, the parent is notified and goes through the appropriate state transitions. Adding getters and setters, in any case, does not change any of the issues. –  Kaz Feb 13 '13 at 16:49
    
I yet prefer clickPrintButton(), method which might just do btnPrintorder.click(), instead of doing checkoutPaymentConfirmpage.btnPrintorder.click() through out the tests. And when I chain different methods from page object class I find tests more comprehensible but that may be personal preference. Thanks for your response Ross. –  Tarun Feb 14 '13 at 4:16
add comment

You misunderstand implementation hiding if you think that making members private, but providing getters and setters, is information hiding.

If I'm using your class, and I have a way of directly accessing a member via a getter, or overwriting that member with a setter, then it isn't information hiding. Your class is acting as a dumb container for members that I can manipulate quite directly.

Yes, the getter and setter can do some neat things, like trigger certain actions. Maybe the getters and setters can be rewritten to be remote procedure calls to a server in Russia. But those neat things are not information hiding. They don't hide how the class is implemented, only some details about how that specific member is implemented.

In any case, in decent programming languages, if you need that kind of abstraction for member access, you can just start out by leaving an ordinary member accessible, and then later add getter and setter methods which hook into the ordinary access syntax. That is to say, an assignment like obj.memb = foo actually triggers a setter, and evaluation of obj.memb triggers a getter. Getters-setters versus direct evaluation and assignment syntax is therefore only an issue of syntax, whereas implementation hiding has to do with semantics, and revolves around providing no access to members whatsoever. An object which hides its implementation can only be manipulated by methods on that object, none of which provide direct access to any members.

share|improve this answer
    
I think my argument on getters was not not a good example, please see my comment to Ross' response –  Tarun Feb 14 '13 at 4:20
add comment

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.