koffice

Thomas Zander zander at kde.org
Tue Sep 29 14:09:53 CEST 2009


On Tuesday 29. September 2009 13.56.40 Dmitry Kazakov wrote:
> On Tue, Sep 29, 2009 at 2:28 PM, Thomas Zander <zander at kde.org> wrote:
> > On Tuesday 29. September 2009 13.15.54 Dmitry Kazakov wrote:
> > > Argh! =(
> > > You are beaking encapsulation! Isn't this a basic principle of
> > > object-oriented programming?
> > > There is an object (doc), and there is it's interface
> > > (undoLastCommand). And no calls to private members! (undo stack is
> > > private, right?) Why do
> >
> > you
> >
> > > use private members?
> >
> > The code is;
> >
> > m_doc->undoStack()->undo();
> >
> > undoStack is a public method, not a private member. There is no breaking
> > of encapsulation in this code.
>
> There is. The object, returned by undoStack(), *is* private. 

As soon as the public assessor was added, it stopped being private and thus 
all results of it becoming public have to be taken. Good and bad.

The good thing is that you can use it and don't have to create new methods, 
the bad is that KoDocuments public API states we use the QUndoStack, so we 
can't stop using that.

I think its just fine to decide in our API that we use and will continue to use 
the QUndoStack (or inherited). So I don't share your concerns and as we are 
indeed not breaking encapsulation due to that prior decision, its fine to use 
the code snipped pasted above.
-- 
Thomas Zander

Qt Developer Days 2009 | Save your seat - REGISTER NOW!
Munich, Germany: October 12th - 14th LAST CHANCE TO REGISTER!
San Francisco, California: November 2nd - 4th EARLY BIRD PRICING - SAVE $200!
For more info: http://qt.nokia.com/qtdevdays2009


More information about the kimageshop mailing list