Здравствуйте, LuciferMoscow, Вы писали:


_>>1.
LM>Абстрактный класс CShape(чисто виртуальный метода Draw) и производные от него CSqure,etc
нет. он имел в виду, что есть какая-то лажа с именно квадратом и прямоугольником..
но что именно я так и не знаю

_>>2.
_>>потом был вопрос в каких случаях надо применять интерфейсы, а в каких абстрактные классы
LM>А в чем разница?
???

_>>4. есть ли тут ошибка:
_>>

_>>class A{
_>>public:
_>>  A& operator+ (A a);
_>>};
_>>

_>>я говорю, что нету, что компилироваться будет.
_>>он говорит, ок, компилироваться будет, а работать не будет
_>>я говорю, что можно и так сделать, что работать будет.. а он НЕТ НЕТ НЕТ...

LM>Он прав. Возврат ссылки на локальную переменную.
вот это он так подковырнуть хотел. на что я ответи, что в самом тьупом случае можно завести глобалную переменную и возвращать ссылку на нее... и все работать будет — цель достигнута

Здравствуйте, Me_, Вы писали:

Me_>Здравствуйте, Ulin,

Me_>в этом контексте все верно, но опять же — нужно сразу указывать пределы абстракции базовых классов. Не было обговорено, что прямоугольник имеет методы изменения своего размера, а предусмотреть всё — невозможно.
Даже если он не имеет этих методов на момент постановки задачи, никто не может поручится, что эти методы не будут добавлены впоследствие в процессе поддержки. И тогда это нарушение LSP аукнется весьма пренеприятнейшими багами, и, возможно, весьма дорогой к тому моменту, переделкой всей иерархии...

Me_>На собеседовании надо было уточнить функционал этих двух классов, такого однозначного ответа типа "вы не понимаете ООП" быть не может.
Согласен, однозначно утверждать о незнании ООП в данном случае рано. Неплохо было бы попробовать подвести соискателя к подводным камням, imho они тут не самые очевидные...

Здравствуйте, ilya_ny, Вы писали:

_>Здравствуйте, LuciferMoscow, Вы писали:
LM>>Он прав. Возврат ссылки на локальную переменную.
_>вот это он так подковырнуть хотел. на что я ответи, что в самом тьупом случае можно завести глобалную переменную и возвращать ссылку на нее... и все работать будет — цель достигнута
multithreading.

Здравствуйте, ilya_ny, Вы писали:


_>4. есть ли тут ошибка:
_>

_>class A{
_>public:
_>  A& operator+ (A a);
_>};
_>

_>я говорю, что нету, что компилироваться будет.
_>он говорит, ок, компилироваться будет, а работать не будет
_>я говорю, что можно и так сделать, что работать будет.. а он НЕТ НЕТ НЕТ...

извиняюсь...
сейчас вспомнил — там СТАТИЧЕСКИЙ оператор +, поэтому никаких this возвращать нельзя было.
ну а наш диалог с ним остается в силе

Здравствуйте, ilya_ny, Вы писали:

_>Здравствуйте, LuciferMoscow, Вы писали:


_>>>1.
LM>>Абстрактный класс CShape(чисто виртуальный метода Draw) и производные от него CSqure,etc
_>нет. он имел в виду, что есть какая-то лажа с именно квадратом и прямоугольником..
_>но что именно я так и не знаю

то что прямоугольник порожден от квадрата следует из того, что квадрат можно описать одним свойством
длина его стороны(a), а у прямоугольника появляется новое свойство — длина другой стороны (в). Итого прямоугольник наследуется от квадрата с появлением дополнительного своего свойства.

Здравствуйте, fomiha, Вы писали:
F>то что прямоугольник порожден от квадрата следует из того, что квадрат можно описать одним свойством
F>длина его стороны(a), а у прямоугольника появляется новое свойство — длина другой стороны (в). Итого прямоугольник наследуется от квадрата с появлением дополнительного своего свойства.
ООП должен облегчать жизнь программисту, не так ли?

Допустим, нам нужно нарисовать квадрат и прямоугольник на экране. Для этого создадим метод Draw().
Т.к. фигуры двухмерные, то нам прийдется использовать длину и ширину в обоих случаях, но для квадрата это будет одно и то же значение. Теперь вопрос: что должно быть базовым классом, если мы не хотим писать код Draw() дважды (вынос кода Draw() в функтор будем считать наглым читерством, т.к. для общего случая на входе будет длина и ширина раздельно)?

P.S. Квадрат нельзя описать одним свойством, т.к. без знания, что с этим свойством делать, квадрат не нарисуется И это знание как раз заключено в методе Draw().

However, let’s assume that we are not very concerned with memory efficiency. Are
there other problems? Indeed! Square will inherit the SetWidth and SetHeight functions. These functions are utterly inappropriate for a Square , since the width and height of a square are identical.”.

Какой ужас Наверное инициализировать объект в конструкторе и оставить только методы GetWidth() и GetHeight() не позволяет религия

Ох, как же я тебя понимаю, особенно, когда интервьюер сидит у тебя над душой, тут вообще полметра амплитуда

Здравствуйте, LuciferMoscow, Вы писали:

LM>Здравствуйте, ilya_ny, Вы писали:

_>>Здравствуйте, LuciferMoscow, Вы писали:
LM>>>Он прав. Возврат ссылки на локальную переменную.
_>>вот это он так подковырнуть хотел. на что я ответи, что в самом тьупом случае можно завести глобалную переменную и возвращать ссылку на нее... и все работать будет — цель достигнута
LM>multithreading.
ilya_ny, Вы поняли, что Ваш хак летит в трам-тарары?

Здравствуйте, Sh1ZoID, Вы писали:

SZI> В скором времени собираюсь менять место работы, а значит, таскаться по собеседованиям. Собеседований, как таковых, я не боюсь, т.к. уверен в своих знаниях, но вот когда мне говорят фразу типа: "вот вам небольшое задание, вы должны его сделать за пол часа", кисти моих рук начинают колебаться с амплитудой 5-10см, не зависимо от сложности задания. И когда я сожусь за комп, я не то, что сообразить ничего не могу, я по клавишам-то с трудом попадаю(серьёзно!) . Это для меня самое страшное на собеседовании!!!

Выпей полбаночки пивка перед собеседованием
Пей новопассит, валерьянку, ходи почаще на собеседования, перестань циклиться на том что "если сюда не возьмут — повешусь".

SZI> Так вот собственно вопрос...не будет ли не корректным с моей стороны попросить пройти этот этап собеседования каким-нибудь другим путём? Если это допустимо, то что можно предложить в замен?

Будет некорректным. В замен — другая контора с другими подходами.

SZI> ЗЫ Два раза я напарывался на это, причём оба раза провалился с крахом!!! А после одного из них, я настолько, извините за выражение, "обделался", что даже не смог вспомнить, что вызов метода через IDispatch::Invoke называется поздним связыванием!!!

Это фигня, я и сейчас не знаю этого термина. Хотя и знаю как эта штука работает.

Здравствуйте, Ulin, Вы писали:

Me_>>в этом контексте все верно, но опять же — нужно сразу указывать пределы абстракции базовых классов. Не было обговорено, что прямоугольник имеет методы изменения своего размера, а предусмотреть всё — невозможно.

U>Даже если он не имеет этих методов на момент постановки задачи, никто не может поручится, что эти методы не будут добавлены впоследствие в процессе поддержки. И тогда это нарушение LSP аукнется весьма пренеприятнейшими багами, и, возможно, весьма дорогой к тому моменту, переделкой всей иерархии...

Так функционал нужно определять до написания кода, а не после, иначе любую архитектуру нужно будет потом переделывать.

Вот например у нас есть множество видов бойцовских собак. Предназначенных именно для драк, не для чего-либо еще. Мы с чистой совестью создаем базовый класс пса, имеющего определенный набор характеристик, касающихся именно драк, наследуем от нее разные породы: овчарки, боксеры и тп. И тут кому-то в голову приходит добавить в базовый класс функцию "повилять хвостом", к scope-у нашей задачи совершенно не относящейся, а у боксера хвоста нет. Всё, получается, наша иерархия не отвечает новым требованиям, нужно все переделывать.

Здравствуйте, LuciferMoscow, Вы писали:

LM>Если так, то отрыв рук — самое мягкое что следует делать за такое. += и + разные вещи, а человек,который будет сопровождать ЭТО должен догадыватся, что какой-то "умник" ТАК переопределил +

operator+ совсем не обязан иметь семантику "оператор сложения".
Вспомни про operator<< для потоков, который возвращает неконстантную ссылку.

Здравствуйте, LuciferMoscow, Вы писали:

LM>Здравствуйте, ilya_ny, Вы писали:

_>>Здравствуйте, LuciferMoscow, Вы писали:
LM>>>Он прав. Возврат ссылки на локальную переменную.
_>>вот это он так подковырнуть хотел. на что я ответи, что в самом тьупом случае можно завести глобалную переменную и возвращать ссылку на нее... и все работать будет — цель достигнута
LM>multithreading.

TLS.

Здравствуйте, Sh1ZoID, Вы писали:

SZI>Здравствуйте, Козьма Прутков, Вы писали:

КП>>А так мне кажется лучше над собой поработать: нет ничего страшного в решении задачек, допущении ошибок и т.д.
SZI> Только вот как заставить понять это моё подсознание?!?! Йога?

Достигается упражнениями...

Здравствуйте, LuciferMoscow, Вы писали:

LM>Здравствуйте, Me_, Вы писали:

Me_>>Здравствуйте, LuciferMoscow, Вы писали:

_>>>>4. есть ли тут ошибка:
_>>>>

_>>>>class A{
_>>>>public:
_>>>>  A& operator+ (A a);
_>>>>};
_>>>>

_>>>>я говорю, что нету, что компилироваться будет.
_>>>>он говорит, ок, компилироваться будет, а работать не будет
_>>>>я говорю, что можно и так сделать, что работать будет.. а он НЕТ НЕТ НЕТ...
LM>>>Он прав. Возврат ссылки на локальную переменную.
Me_>>Так возвратит же this, и все работать будет. Или я уже совсем си++ забыл?
LM>Если так, то отрыв рук — самое мягкое что следует делать за такое. += и + разные вещи, а человек,который будет сопровождать ЭТО должен догадыватся, что какой-то "умник" ТАК переопределил +
execve, с чем Вы не согласны?

Здравствуйте, execve, Вы писали:

E>Здравствуйте, LuciferMoscow, Вы писали:

LM>>Если так, то отрыв рук — самое мягкое что следует делать за такое. += и + разные вещи, а человек,который будет сопровождать ЭТО должен догадыватся, что какой-то "умник" ТАК переопределил +

E>operator+ совсем не обязан иметь семантику "оператор сложения".
E>Вспомни про operator<< для потоков, который возвращает неконстантную ссылку.
Не обязательно, но скорее всего человек сопровождающий код будет надеятся на некоторое поведение данного оператора.
Верю, что ты можешь привести пример, когда это не так.

P.S. Ссылку на книгу Саттера и Александреску давать надо?

Здравствуйте, Sh1ZoID, Вы писали:

SZI> ЗЫ Два раза я напарывался на это, причём оба раза провалился с крахом!!! А после одного из них, я настолько, извините за выражение, "обделался", что даже не смог вспомнить, что вызов метода через IDispatch::Invoke называется поздним связыванием!!!

Зачем ты приходишь на собеседование? С людьми поговорить, себя показали. Не взяли тебя --- им же хуже.

С тобой происходят не самые страшные вещи, история знает примеры и пострашнее.

Мне кажется надо начать делать по психологической устойчивости:
1. Занятся спортом, в котором надо принимать решение за доли секунды (игровые виды подойдут)
2. Шахматы (блиц)
3. Преферанс на деньги (руки задрожали будто кур я воровал, будто сел играть я в самый первый --- похоже, да?)
4... (думаю понятно что я имею в виду)

В целом владение собой это это очень полезное качество по жизни и на работе, и оно также может оценивается на собеседовании.

Здравствуйте, LuciferMoscow, Вы писали:

E>>operator+ совсем не обязан иметь семантику "оператор сложения".
E>>Вспомни про operator<< для потоков, который возвращает неконстантную ссылку.
LM>Не обязательно, но скорее всего человек сопровождающий код будет надеятся на некоторое поведение данного оператора.

Точно так же, как и для operator<<

LM>Верю, что ты можешь привести пример, когда это не так.

nonstd::cout + "Hello, world" + nonstd::endl;

LM>P.S. Ссылку на книгу Саттера и Александреску давать надо?

Конечно. Желательно на введение или на содержание.
P.S. Ссылку на что именно?

Здравствуйте, Sh1ZoID, Вы писали:

SZI> В скором времени собираюсь менять место работы, а значит, таскаться по собеседованиям. Собеседований, как таковых, я не боюсь, т.к. уверен в своих знаниях, но вот когда мне говорят фразу типа: "вот вам небольшое задание, вы должны его сделать за пол часа", кисти моих рук начинают колебаться с амплитудой 5-10см, не зависимо от сложности задания. И когда я сожусь за комп, я не то, что сообразить ничего не могу, я по клавишам-то с трудом попадаю(серьёзно!) . Это для меня самое страшное на собеседовании!!! Так вот собственно вопрос...не будет ли не корректным с моей стороны попросить пройти этот этап собеседования каким-нибудь другим путём? Если это допустимо, то что можно предложить в замен?

SZI> ЗЫ Два раза я напарывался на это, причём оба раза провалился с крахом!!! А после одного из них, я настолько, извините за выражение, "обделался", что даже не смог вспомнить, что вызов метода через IDispatch::Invoke называется поздним связыванием!!!

Не волнуйся!
Через 2-3 собеседования у тебя это пройдет

Здравствуйте, Alexey_ch, Вы писали:

A_>ООП должен облегчать жизнь программисту, не так ли?

A_>Допустим, нам нужно нарисовать квадрат и прямоугольник на экране. Для этого создадим метод Draw().
A_>Т.к. фигуры двухмерные, то нам прийдется использовать длину и ширину в обоих случаях, но для квадрата это будет одно и то же значение. Теперь вопрос: что должно быть базовым классом, если мы не хотим писать код Draw() дважды (вынос кода Draw() в функтор будем считать наглым читерством, т.к. для общего случая на входе будет длина и ширина раздельно)?

Считаю что метод draw должен быть виртуальным и принадлежать абстрактному классу (что-то типа Фигура) от которого должен наследоваться квадрат, но никак не квадрату. И каждый класс должен его сам реализовывать. Да и цель этой иерархии может быть вовсе не в рисовании. И при появлении новых фигур так удобнее (напр. добавляем параллелограмм — наследуем от прямоугольника с добавлением свойства "угол между сторонам").

A_>P.S. Квадрат нельзя описать одним свойством, т.к. без знания, что с этим свойством делать, квадрат не нарисуется И это знание как раз заключено в методе Draw().

почему нельзя ))
свойство одно — длина стороны
а методов сколько хошь можно напридумать ))

Здравствуйте, fomiha, Вы писали:

F>Считаю что метод draw должен быть виртуальным и принадлежать абстрактному классу (что-то типа Фигура)
+1, но мы уходим от первоначального вопроса, а там только квадрат и прямоугольник.

F>от которого должен наследоваться квадрат, но никак не квадрату.
Даже если оба класса унаследованы от абстрактной Фигуры с виртуальным Draw(), можно не писать код рисования дважды, унаследовав квадрат от прямоугольника.

A_>>P.S. Квадрат нельзя описать одним свойством, т.к. без знания, что с этим свойством делать, квадрат не нарисуется И это знание как раз заключено в методе Draw().
F>почему нельзя ))
F>свойство одно — длина стороны
Потому что следуя такой логике можно унаследовать прямоугольник от круга У него тоже "одно свойство".