что то я не в курил, в топике вроде как взаимоисключающие параграфы:
После превышения лимита, приглашения отправляются, но ваши друзья будут видеть такое сообщение: «The Google+ project is currently working out all the kinks with a small group of testers. If you're not able to access Google+, please check back again soon.»
И ниже Ваш друг получит письмо, и тот же текст на скриншоте :)
Я не исключаю варианта, что так будет лучно, но всё зависит от того, что должно получится в итоге.
На примере, допустим вы можете нарисовать контур и закрашеный контур. В случае использования интерфейсов, вам придется либо делать общий метод вашего Drawer-объекта для закраски, либо использовать интерфейс IPaintable.
А теперь допустим, вы используете алгоритм заливки, который одинаков для круга и эллипса, но отличается для квадрата (т.к. квадрат закрасить можно более простым алгоритмом). В таком случае интерфейс paintable вам либо придется описывать дважды, либо делать отдельный Drawer для прямоугольника.
Тут мы приходим к тому, что надо бы сделаеть класс с абстрактным методом реализирующий интерфейс IPaintable, от которого наследуем и Ellipse и Circle, реализующие IDrawable, но выглядит все это уже досточно громоздко.
Если заранее известно, что Circle и Ellipse будут отрисовываться, то часто бывает лучше объявить абстрактный метод Draw предка Circuit и реализовывать его в наследниках.
С одной стороны очевидно, что круг — это частный случай эллипса, поэтому я выбрал первое.
Таким образом образом получается:
Ellipse->setHeight(height);
Ellipse->setWidth(width);
public class CCircle extends CEllipse
{
public function setRadius(Size);
{
parent::setHeight(Size)
parent::setWidth(Size)
}
}
То есть именно то излишество, за что ругают ООП.
Наследовать эллипс от круга тоже плохой вариант, так как придется переопределять кучу методов, что тоже будет крайне не оптимально.
Так что скорее склоняюсь к третьему варианту, CEllipse и CCircle разные предки какого-нибудь CCircuit.
Чертовы дизайнеры, чем они руководствовались, когда делали эти кнопки? IMHO старый тулбар был удобнее, меньше вариантов было щелкнуть в пустое место между кнопками.
Для комплекта не хватает примеров по замыканиям;
Так же нет описания передачи ссылок на функции, процедуры и методы;
Не указано, что нельзя задать дефолтное значению типу Variant;
И да, упущена такая штука, как VarArrayOf
А как вы добъетесь того, что на предметах, которые ближе к точке съемке боке несколько иное? Вы же никак не можете восстановить расстояние до каждой точки на снимке.
Забавно, с утра пораньше видел данную новость на другом ресурсе. В комментах не приминули запостить это же изображение.
Всё ждал, когда оно появится здесь.
Ну разумеется. И очень часто. Мы вот нашли фотку в интернете (тут прилагается 640x480), можно нам её на баннер 6x3?
А еще есть любители своей мыльницой отфотографировать что-нибудь со впечатаной датой снимка. А потом удивляются, что убрать дату с 50 снимков — это стоит денег.
Внимание! в Opere кнопки Share почему-то нет.
После превышения лимита, приглашения отправляются, но ваши друзья будут видеть такое сообщение: «The Google+ project is currently working out all the kinks with a small group of testers. If you're not able to access Google+, please check back again soon.»
И ниже Ваш друг получит письмо, и тот же текст на скриншоте :)
На примере, допустим вы можете нарисовать контур и закрашеный контур. В случае использования интерфейсов, вам придется либо делать общий метод вашего Drawer-объекта для закраски, либо использовать интерфейс IPaintable.
А теперь допустим, вы используете алгоритм заливки, который одинаков для круга и эллипса, но отличается для квадрата (т.к. квадрат закрасить можно более простым алгоритмом). В таком случае интерфейс paintable вам либо придется описывать дважды, либо делать отдельный Drawer для прямоугольника.
Тут мы приходим к тому, что надо бы сделаеть класс с абстрактным методом реализирующий интерфейс IPaintable, от которого наследуем и Ellipse и Circle, реализующие IDrawable, но выглядит все это уже досточно громоздко.
Таким образом образом получается:
Ellipse->setHeight(height); Ellipse->setWidth(width); public class CCircle extends CEllipse { public function setRadius(Size); { parent::setHeight(Size) parent::setWidth(Size) } }То есть именно то излишество, за что ругают ООП.
Наследовать эллипс от круга тоже плохой вариант, так как придется переопределять кучу методов, что тоже будет крайне не оптимально.
Так что скорее склоняюсь к третьему варианту, CEllipse и CCircle разные предки какого-нибудь CCircuit.
Так же нет описания передачи ссылок на функции, процедуры и методы;
Не указано, что нельзя задать дефолтное значению типу Variant;
И да, упущена такая штука, как VarArrayOf
Всё ждал, когда оно появится здесь.
А еще есть любители своей мыльницой отфотографировать что-нибудь со впечатаной датой снимка. А потом удивляются, что убрать дату с 50 снимков — это стоит денег.