Здравствуйте, LuciferMoscow, Вы писали:
_>>2. _>>потом был вопрос в каких случаях надо применять интерфейсы, а в каких абстрактные классы LM>А в чем разница?
Хммм...мне тоже интересно. Такое ощущение, что это вопрос по Шарпу, а не по СиПиПи
Здравствуйте, LuciferMoscow, Вы писали:
_>>2. _>>потом был вопрос в каких случаях надо применять интерфейсы, а в каких абстрактные классы LM>А в чем разница?
Ну вообще вопрос по шарпу больше. В шарпе запрещено множественное наследование (интерфейсов можно), так что разница есть.
_>>4. есть ли тут ошибка: _>>
_>>class A{
_>>public:
_>> A& operator+ (A a);
_>>};
_>>
_>>я говорю, что нету, что компилироваться будет. _>>он говорит, ок, компилироваться будет, а работать не будет _>>я говорю, что можно и так сделать, что работать будет.. а он НЕТ НЕТ НЕТ... LM>Он прав. Возврат ссылки на локальную переменную.
Так возвратит же this, и все работать будет. Или я уже совсем си++ забыл?
Здравствуйте, ilya_ny, Вы писали:
_>1. _>один нарисовал квадратик, другой взял у него бумажку, подумал немного, и рядом подрисовал прямоугольничек и спращивает : "что от чего порождено ? а нарисуй-ка нам классы!" _>я говорю, что квадратик порожден от прямоугольничка, на что третий мужичек сразу и говорит : "а не фига вы, молодой человек, ооп не знаете" _>после этого третий ничего не произнес до самого конца собеседования.
Здравствуйте, Me_, Вы писали:
_>>>4. есть ли тут ошибка: _>>>
_>>>class A{
_>>>public:
_>>> A& operator+ (A a);
_>>>};
_>>>
_>>>я говорю, что нету, что компилироваться будет. _>>>он говорит, ок, компилироваться будет, а работать не будет _>>>я говорю, что можно и так сделать, что работать будет.. а он НЕТ НЕТ НЕТ... LM>>Он прав. Возврат ссылки на локальную переменную.
Me_>Так возвратит же this, и все работать будет. Или я уже совсем си++ забыл?
Ну да. Вернет this. Все нормально. Возврат ссылки даст написать так: a+b = 1; что не есть гут
но в целом вроде вполне работоспособно
Здравствуйте, Ulin, Вы писали:
U>Ну да. Вернет this. Все нормально. Возврат ссылки даст написать так: a+b = 1; что не есть гут U>но в целом вроде вполне работоспособно
Тогда скорее ошибка в том, что возвращается неконстантная ссылка
Здравствуйте, Ulin, Вы писали:
U>Здравствуйте, fessa, Вы писали:
F>>Здравствуйте, ilya_ny, Вы писали:
F>>может, эта статья прояснит ответ 3-го мужика
F>>http://www.objectmentor.com/resources/articles/lsp.pdf
U>Э-э, а разве нельзя сказать, что квадрат ЯВЛЯЕТСЯ частным случаем прямоугольника?
...
No! A square might be a rectangle, but a Square object is definitely not a Rectangle
object. Why? Because the behavior of a Square object is not consistent with the
behavior of a Rectangle object. Behaviorally, a Square is not a Rectangle! And it
is behavior that software is really all about.
...
Советую всё же прочитать статью. Если трудно на английском — можно поискать и на русском...
Здравствуйте, fessa, Вы писали:
F>... F>No! A square might be a rectangle, but a Square object is definitely not a Rectangle F>object. Why? Because the behavior of a Square object is not consistent with the F>behavior of a Rectangle object. Behaviorally, a Square is not a Rectangle! And it F>is behavior that software is really all about. F>...
А вот про поведение ничего сказано не было на собеседовании. Если основываться только на формах — то наследование прямоугольник->квадрат — абсолютно правильно.
Здравствуйте, Me_, Вы писали:
Me_>Здравствуйте, LuciferMoscow, Вы писали:
_>>>4. есть ли тут ошибка: _>>>
_>>>class A{
_>>>public:
_>>> A& operator+ (A a);
_>>>};
_>>>
_>>>я говорю, что нету, что компилироваться будет. _>>>он говорит, ок, компилироваться будет, а работать не будет _>>>я говорю, что можно и так сделать, что работать будет.. а он НЕТ НЕТ НЕТ... LM>>Он прав. Возврат ссылки на локальную переменную. Me_>Так возвратит же this, и все работать будет. Или я уже совсем си++ забыл?
Если так, то отрыв рук — самое мягкое что следует делать за такое. += и + разные вещи, а человек,который будет сопровождать ЭТО должен догадыватся, что какой-то "умник" ТАК переопределил +
Me_>А вот про поведение ничего сказано не было на собеседовании. Если основываться только на формах — то наследование прямоугольник->квадрат — абсолютно правильно.
А зачем рассматривать абстрактную модель сферической лошади в вакууме —
кому нужны классы, которые работают не так, как от них ожидается?
"All derivatives must conform to the behavior that clients expect of the base classes that they use."
Me_ wrote: > > Мне кстати как-то тоже попался интересный интервьюер. Он не знал зачем > нужно слово virtual перед функцией — был уверен, что оно только для > того, чтобы в классе-потомке эту функцию можно было переопределить, типа > на обычную фун-цию слово override поставить нельзя (по шарпу > собеседование). Я уж не стал его расстраивать
Еще раз, чтобы я до конца понял. Вы считаете что в C# можно
переопределить фунцию которая не определена как virtual? И еще этим
гордитесь?
Может как-нибудь попробуете это сделать сами для начала? Или можно
просто спецификацию почитать, тоже помогает.
V>Еще раз, чтобы я до конца понял. Вы считаете что в C# можно V>переопределить фунцию которая не определена как virtual? И еще этим V>гордитесь?
Хмм, а уж не у вас ли я собеседовался?
Вы что-нибудь слышали про ключевое слово new? и про его применение в отношении функций?
V>Может как-нибудь попробуете это сделать сами для начала? Или можно V>просто спецификацию почитать, тоже помогает.
Прежде чем давать подобные советы, стоит хотя бы попробовать проделать это самому, вам не кажется? А то складывается впечатление, что вы не читали даже предупреждения компилятора, не то что спецификацию
Здравствуйте, LuciferMoscow, Вы писали:
Me_>>Так возвратит же this, и все работать будет. Или я уже совсем си++ забыл? LM>Если так, то отрыв рук — самое мягкое что следует делать за такое. += и + разные вещи, а человек,который будет сопровождать ЭТО должен догадыватся, что какой-то "умник" ТАК переопределил +
Me_ wrote:
> Вы что-нибудь слышали про ключевое слово new? и про его применение в > отношении функций? >
слышал конечно, но new != override. А разговор был именно про него —
"типа на обычную фун-цию слово override поставить нельзя" (ваши слова).
Так вот на обычную функцию слово override поставить таки нельзя. Хотя
new конечно можно.
> Прежде чем давать подобные советы, стоит хотя бы попробовать проделать > это самому, вам не кажется? А то складывается впечатление, что вы не > читали даже предупреждения компилятора, не то что спецификацию
читал конечно и то и другое, именно поэтому и возмутился.
Здравствуйте, vpedak, Вы писали:
V>слышал конечно, но new != override. А разговор был именно про него — V>"типа на обычную фун-цию слово override поставить нельзя" (ваши слова). V>Так вот на обычную функцию слово override поставить таки нельзя. Хотя V>new конечно можно.
Ясно, мы не поняли друг друга.
"типа на обычную фун-цию слово override поставить нельзя" — это я как процитировал своего интервьера, т.к. про new ему скорее всего ничего известно не было.
Здравствуйте, Me_, Вы писали:
F>>"All derivatives must conform to the behavior that clients expect of the base classes that they use."
Me_>Так где в нашем случае нарушается это правило?
Цитата из вышеприведенной статьи:
At this point in time we have two classes, Square and Rectangle, that appear to work.
No matter what you do to a Square object, it will remain consistent with a mathematical
square. And regardless of what you do to a Rectangle object, it will remain a mathe-
matical rectangle. Moreover, you can pass a Square into a function that accepts a pointer
or reference to a Rectangle, and the Square will still act like a square and will remain
consistent.
Thus, we might conclude that the model is now self consistent, and correct. However,
this conclusion would be amiss. A model that is self consistent is not necessarily consis-
tent with all its users! Consider function g below.
void g(Rectangle& r)
{
r.SetWidth(5);
r.SetHeight(4);
assert(r.GetWidth() * r.GetHeight()) == 20);
}
This function invokes the SetWidth and SetHeight members of what it believes
to be a Rectangle. The function works just fine for a Rectangle, but declares an
assertion error if passed a Square. So here is the real problem: Was the programmer who
wrote that function justified in assuming that changing the width of a Rectangle leaves
its height unchanged?
Clearly, the programmer of g made this very reasonable assumption. Passing a
Square to functions whose programmers made this assumption will result in problems.
Therefore, there exist functions that take pointers or references to Rectangle objects,
в этом контексте все верно, но опять же — нужно сразу указывать пределы абстракции базовых классов. Не было обговорено, что прямоугольник имеет методы изменения своего размера, а предусмотреть всё — невозможно.
На собеседовании надо было уточнить функционал этих двух классов, такого однозначного ответа типа "вы не понимаете ООП" быть не может.
В данном случае все вполне нормально.
