Опять ООП

Вы используете статическую переменную. Уже хотя-бы этим. Представьте себе ситуацию, когда экземпляр класса нужно будет вернуть из абстрактной фабрики. Что вы будете делать в этом случае?

Вы используете статическую переменную

Эмм, а синглтоны у тебя живут в эфире?

Вы за слова то не цепляйтесь :) Понятное дело что в static. Но я вам указываю не на это. Еще раз — ваш вариант не абстрагирует процесс создания. Это основной поинт. Ответьте на вопрос, что вы будете делать когда экземпляр класса нужно будет вернуть из абстрактной фабрики?

...
public static Singleton getInstance() {
    if (_i == null) {
        _i = _f.create();
    }
    return _;
}
...

Какого класса? Какая фабрика? Какая ленивая инициализация? Я тебя спросил, является ли статическая переменная частным случаем синглтона. Частным. Случаем. Синглтона.

Нет. В вашем случае нет. Да, статическая переменная может являться частным случаем singleton, но только в случае, если она предоставляет экземпляр статического класса. Например в этом

public class S {
    public static final S _I = new S();
}

static int myOneAndOnlyInt;

Ловко ты сравнил 3 кита ООП и задачку с собеседование джуниора.

три кита, my ass. а ещё сильней щёки надуть получится? высшая степень ООП на PHP, двигаешься в сторону понимания MVC?

Сначала умение реализовывать, потом видеть, а потом понимать когда не надо их всюду пихать.

а может начать с понимания того, зачем их вообще придумывали?

Проверять уровень владения ООП на примерах точка->линия->фигура или животное->кошка, это как проверять знание арифметики счетом на пальцах. Проверить можно, но уровень владения не покажет.

знаешь, что такое ложная дихотомия?

познал такую абстракцию, как синглетон

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

это уже показатель

это показатель того, что ты смог заучить реализацию некоторой абстракции. скорее всего - не понимая, зачем её вообще ввели

знаешь, что такое ложная дихотомия?

Да, знаю. Где ты увидел её в моих рассуждениях?

это показатель того, что ты смог заучить реализацию некоторой абстракции. скорее всего - не понимая, зачем её вообще ввели

А что это, как не показатель уровня владения чем-либо?

Shit. Я смотрю тут все друг к другу за каждое слово готовы прицепиться, надо бы незаметно исправиться, а то еще съедят :)

... если она предоставляет экземпляр статического класса. ...

... если она предоставляет экземпляр статического класса. ...

это показатель того, что ты смог заучить реализацию некоторой абстракции.

А что это, как не показатель уровня владения чем-либо?

Позволю себе с вами не согласиться. Например, вы знает на зубок теорему Пифагора, если вас поднять среди ночи, вы докажите ее без промедления. Но вот на практике в реальной жизни не видите ни одного случая, где бы ее можно было применить. Это и отличает знание от понимания (читайте «смог заучить» от «уровня владения»).

Где ты увидел её в моих рассуждениях?

точка->линия->фигура или животное->кошка

умение реализовать паттерны

ты предлагаешь безальтернативный выбор из двух частных случаев, один из которых заведомо хуже агитируемого. это дешёвый демагогический ход

А что это, как не показатель уровня владения чем-либо?

заучивание никогда не является показателем владения

не так давно один товарищ на собеседовании отвечал на вопрос, чем процесс отличается от потока; он сказал, что потоки делят общее адресное пространство, а процессы - нет. показатель? владение? следующим был вопрос о том, как можно передать данные между потоками одного процесса; он ответил, что не знает, и что, скорее всего, это невозможно

с тем же успехом человек, заучивший реализацию классических паттернов, может совершенно не уметь проектировать. ни в ОО-стиле, ни в каком либо другом

Достаточно реализовать наследование хотя бы двух классов и виртуальные ф-ции в них. Хотя бы на ассемблере.

Позволю себе с вами не согласиться.

Мне кажется, вы тоже включились в игру словами! )

Я вызубрил теорему Пифагора, и знаю что в определенных условиях a^2 + b^2 = c^2. Как, почему и зачем так получается мне уже неинтересно, я успешно нахожу «c» и без знания доказательства. Это один уровень владения. То что я не знаю доказательства, не мешает мне применять для решения задач.

ты предлагаешь безальтернативный выбор из двух частных случаев, один из которых заведомо хуже агитируемого. это дешёвый демагогический ход

Я, предлагаю безальтернативный, а уж это то где углядели? Да, ни разу.

Вообще не отрицаю других способов оценки. Только их что-то не очень-то много и предложили.

Кстати, что покажет «животное->кошка», кроме как владение основными понятиями? Этого же мало для оценки уровня владения ООП, вам не кажется?

заучивание никогда не является показателем владения

А умение применять, не понимая как это работает?

Ну, хватит уже словми играть.

Мне кажется, вы тоже включились в игру словами! )

Но мы же не придираемся друг к другу, а ведем культурную беседу, почему бы и не поиграть :) Придираются тут некоторые стоящие особняком личности.

Как, почему и зачем так получается мне уже неинтересно, я успешно нахожу «c» и без знания доказательства. Это один уровень владения. То что я не знаю доказательства, не мешает мне применять для решения задач.

Хм. Грубо говоря, у вас спрашивают детскую задачку — «из точки A выехали две фуры, одна движется строго на север со постоянной скоростью 50 миль в час, другая строго на запад со скоростью 60. Вопрос, какое между ними будет расстояние через 3 часа». Но если вы не применяли теорему Пифагора уже 10 лет на практике, но все еще помните формулировку (даже без доказательств, фиг с ними), не факт что вы сходу ее примените для решения именно этой задачи. Может быть вы еще начнете изобретать велосипед, кто знает. А вот если бы вы работали каждый день с подобными данными, вы бы применили ее не задумываясь. Я рассуждаю с этой точки зрения. Знать != применять.

а может начать с понимания того, зачем их вообще придумывали?

Может, но практика показывает, что понимание того, что не надо везде запихнуть побольше паттернов всё равно приходит не сразу.

Знать != применять.

Я просто не понимаю, почему применение - это уровень владения, а знание - нет?

Почему нельзя выделить уровни владения, начиная с нулевого «не знаю, что такое ООП», «знаком с парадигмами», «пишу с использованием классов и объектов не понимая зачем они нужны» и т.д. по возрастающей?

Эм. Ну я думаю потому что владеть знанием != владеть опытом. Т.е. вы знаете как молотком забить гвоздь, любой это знает. Т.е. владеет знанием. Но не каждый сможет сходу забить десятку в балку с 3-4 ударов, причем ровно и без косяков. Это уже называется владеть опытом. А опыт приходит только с практикой. Я думаю это и есть причина, почему мешать уровень владения знанием и уровень применения на практике — не лучшая затея.

Почему нельзя выделить уровни владения, начиная с нулевого «не знаю, что такое ООП», «знаком с парадигмами», «пишу с использованием классов и объектов не понимая зачем они нужны» и т.д. по возрастающей?

Что касается уровней, не знаю. Скорее всего можно, но вот такая шкала будет отражать только уровень знания, но не уровень владения знанием.

Что касается уровней, не знаю. Скорее всего можно, но вот такая шкала будет отражать только уровень знания, но не уровень владения знанием.

... уровень знания, но не уровень владения знанием опыта.

пхп никогда не видел, mvc понял на первом курсе

чяднт?

Пример.

С выходом питона 3.4, я стал в скриптах использовать @asyncio.coroutine, yield from etc.. Спросите меня про то, как работают сопрограммы и я начну в ответ что-то мямлить про конкурентность и в итоге замолчу.

Вопрос, мой код перестанет быть ассинхронным от этого? Можно назвать мой уровень «уровнем владения»?

Понятно, что зная как оно работает, я бы эффективней использовал этот инструмент. Но, магия, оно работает и без этого, чисто по аналогии с документацией библиотеки!

Подскажите мне как оценить свой уровень владение ООП?

По количеству классов в коде хеллоуворлда.

Есть ли какой нибудь стандарт ООП?

Да, есть. Эталонный стандарт ООП — мобильное приложение фейсбука под iOS. 18000 классов, FBEventUpdateNotificationSubscriptionLevelMutationOptimisticPayloadFactoryProtocol-Protocol.h, все дела.

Этого же мало для оценки уровня владения ООП, вам не кажется?

мало. и я об этом уже написал. дважды. а ещё я написал что из этого не следует, что паттернов достаточно

А умение применять, не понимая как это работает?

это уровень интерна в лучшем случае. monkey job

не очень-то много и предложили

а давай такой: берём задачу, берём критерии выполнения, делаем реализацию, оцениваем реализацию. то же самое, что в GoF, только начинаем с задачи, а не с решения. задачу берём из предметной области

Может, но практика показывает, что понимание того, что не надо везде запихнуть побольше паттернов всё равно приходит не сразу.

так может именно потому, что нет

понимания того, зачем их вообще придумывали

а?

если GoF сходу рассматривать как учебник, а не как кулинарную книгу, может и эффект какой-то другой будет?

это уровень интерна в лучшем случае. monkey job

Но это, всё-таки уровень! )

а давай такой: берём задачу...

Не не не... Я не хочу меряться ничем! Я просто так же, как и ТС хочу понять, как можно оценить «уровень владения ООП» и вообще, какие уровни можно выделить.

Понятно, что зная как оно работает, я бы эффективней использовал этот инструмент. Но, магия, оно работает и без этого, чисто по аналогии с документацией библиотеки!

А если вам нужно будет сделать что-то, что выходит за пределы документации? Возьмем те же генераторы что вы привели выше. Скажем вы хотите понять, для чего можно использовать возврат в 3.4. Вы сможете сказать сходу (не выполняя, и никуда конечно же не подглядывая :)) результат выполнения данного кода в python 3.4 и, скажем в 3.2, и прокомментировать его:

def one():
    return 1
    yield 2

def two():
    result = yield from one()
    print(result)

two() #result?

Понятно, что зная как оно работает, я бы эффективней использовал этот инструмент.

Дак вот в чем вопрос. Можно ли определить уровень опыта применения тех же генераторов, если у человека просто спросить — что такое генераторы и как они работают?

Спросите меня про то, как работают сопрограммы и я начну в ответ что-то мямлить про конкурентность и в итоге замолчу.

Вопрос, мой код перестанет быть ассинхронным от этого?

А вот это уже интересный вопрос. Т.е. вы не знаете что такое сопрограммы, как они работают, но как-то умудряетесь их применять и причем успешно? Я правильно понял?

чяднт?

не можешь в оскорбительные метафоры. три кита ООП в смысле сложности ничем существенно не отличаются от, например, паттерн-матчинга, лени и рекурсии (или почти любой другой тройки выбраных наугад идиом). это не священная корова и не доказательство теоремы Ферма. это такой же вопрос для джуна, только ещё более бесполезный, чем просьба написать факториал

Я не хочу меряться ничем!

я тоже. я просто предлагаю критерий оценки. если мы оцениваем проектирование - давайте возьмём задачу на проектирование. не решение задачи (паттерн), не тривиальную синтетическую задачу (speak), а сколько-нибудь сложную задачу из конкретной предметной области. набросок реализации протокола с отрицательной изменчивостью, сериализатор для иерархии, простое ОО IPC, параллелизацию n-арного леса зависимых задач, whatever

владение ООП - это умение решать задачи проектирования с помощью ООП. не знание готовых решений, не знание трёх китов, не чтение статей Карделли, не умение отнаследовать ежа от ужа, и даже не знание устройства таблицы виртуальных функций (или её аналога)

Вы сможете сказать сходу (не выполняя, и никуда конечно же не подглядывая :)) результат выполнения данного кода в python 3.4 и, скажем в 3.2

У нас же интернет, разве можно не подглядывая?! Нет, не могу.

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

Вот пример, уж извините за факториал Фибонначи в документации нет. Дает некоторое представление о том зачем оно нужно, но не о том как оно работает!

import asyncio

@asyncio.coroutine
def factorial(name, number):
    f = 1
    for i in range(2, number+1):
        print("Task %s: Compute factorial(%s)..." % (name, i))
        yield from asyncio.sleep(1)
        f *= i
    print("Task %s: factorial(%s) = %s" % (name, number, f))

loop = asyncio.get_event_loop()
tasks = [
    asyncio.ensure_future(factorial("A", 2)),
    asyncio.ensure_future(factorial("B", 3)),
    asyncio.ensure_future(factorial("C", 4))]
loop.run_until_complete(asyncio.wait(tasks))
loop.close()

владение ООП - это умение решать задачи проектирования с помощью ООП. не знание готовых решений, не знание трёх китов, не чтение статей Карделли, не умение отнаследовать ежа от ужа, и даже не знание устройства таблицы виртуальных функций (или её аналога)

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

На что там смотреть, на таблицы методов и диспетчер?

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

А когда он студенческие поделки на коленке писал, зачем им быть приватными? Всё равно они никуда не годятся.

Дать ссылку на свой GitHub. А мы всё обругаемрасскажем. Если GitHub-а или Bitbucket-а, или чего-то аналогичного нет (а ты не разрабатываешь уже несколько лет на профессиональном уровне), то, скорее всего, всё довольно печально.

Т.е. если не писал код 2 года. То уровень владения ООП низкий да?
Если честно это самый неожиданный критерий )

Да. Если 2 года не заниматься программированием, то всё плохо. Тут постоянные навыки нужны, иначе всё забывается и делаешься полным нулём.

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

а сочинять музыку учиться, играя гаммы?

ты часто в рамках рабочей деятельности решаешь изолированные задачи на инкапсуляцию, полиморфизм и наследование? или синтетические задачи на их комбинацию?

зачем проверять одно умение, если фактически нужно другое?

это, наверное, потолок

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

Должны же быть уровни и для тех, кто только знает чем класс отличается от объекта?

давай назовём их оценками, а этих людей - учащимися на программистов, и всё встанет на свои места

http://www.c2.com/cgi/wiki?HeInventedTheTerm

А когда он студенческие поделки на коленке писал

Я думал люди это трут и забывают как страшный сон. Лично я так и сделал :)
А те люди, которые это хранят, в большинстве своем просто постесняются давать это на обозрение. И правильно сделают.
А вы свои первые хелловорды все храните? :)

но не о том как оно работает!

Вот и зачем людям нужны такие примеры? Они даже слабо показывают зачем вообще нужны сопрограммы. Вы совращаете неокрепшие умы, вас могут неправильно понять :)

это вообще не показатель знаний в ООП

А что показатель? :)

Предлагаю сделать следующее:

Берешь какую-нибудь задачу, рисуешь UML диаграмму к ней и выкладываешь сюда :D

Пример задачи: Спроектировать компьютерную игру, например настольная или стратегия, пошаговая (но это не обязательно), с возможностью мультиплеера (по сети, интернету, на одном устройстве) и сингл плеера.

Вот, сможешь набросать диаграмму классов/объектов, провести анализ юз кейсов, считай, что ты знаешь ООП.

Вот и зачем людям нужны такие примеры?

это небольшой пример из всё-таки большого раздела документации по asyncio и конечно же он из контекста выдран. Как мне кажется он всё-таки показателен, что не зная, как работают сопрограммы, дает некое понимание, для чего их можно использовать.

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

А теперь объясните мне, пожалуйста, на пальцах, для чего именно программист станет использовать со-программы, опираясь на ваш пример.

Извиняюсь, конечно же с поправкой

... для чего именно программист, не понимающий как работают со-программы, станет использовать ...

Явно, не факториал считать.

Сложно гадать, что ему в голову придет, когда он увидит по этому примеру вывод:

Task A: Compute factorial(2)...
Task B: Compute factorial(2)...
Task C: Compute factorial(2)...
Task A: factorial(2) = 2
Task B: Compute factorial(3)...
Task C: Compute factorial(3)...
Task B: factorial(3) = 6
Task C: Compute factorial(4)...
Task C: factorial(4) = 24

Неужели по этому примеру нет над чем подумать? Хотя, наверное, главное здесь это yield from asyncio.sleep(1) ))

Сложно гадать, что ему в голову придет, когда он увидит по этому примеру вывод:
Неужели по этому примеру нет над чем подумать?

Дело в том есть или нет. Дело в том какую пищу для размышления дает та или иная информация. А вы не думали, что прочитав ваш пример, какой-нибудь поехавшик фрик начнет применять это как фундамент для реализации элементарной линейной многозадачности, а-ля замены multiprocessing (или как это там у вас в питоне называется)? Вас не посещали такие мысли? :)

это, наверное, потолок

Т.е. курс для первокурсников (SICP, глава 3) — это потолок? o_O'