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