Calling methods in getters and setters is a dangerous practice. It can be acceptable for minor things in some cases, your example is a good one of an acceptable case. The reason it's a dangerous practice is because it exposes object state outside the object and moves the reasoning of that state outside the object as well. For extremely simple cases it can be easier to just have a method called as part of the process, but this will create more potential side effects and increase the difficulty of using your object. A better solution would be separate
Show() methods rather than setting a property on the object.
The reason explicit methods would be preferred is that you are now telling the object what to do rather than asking. In the case of visibility it probably doesn't change much, but it's good to get in the habit of following this pattern for more complicated procedures. As an example if you were to add paging functionality, you don't want to ask the object what page its on, increment the result and tell it to go to that page. You just want to tell your object go to the next page, let the object itself handle calculating the next page, handling if there isn't a next page, or anything else that might be needed. The proper object oriented approach is to keep the state of an object encapsulated as possible and only expose methods that are things that the object should do.