Вы используете статическую переменную. Уже хотя-бы этим. Представьте себе ситуацию, когда экземпляр класса нужно будет вернуть из абстрактной фабрики. Что вы будете делать в этом случае?
Вы за слова то не цепляйтесь :) Понятное дело что в 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;
И частным случаем паттерна singleton не является. Называйте, пожалуйста, вещи своими именами.
Проверять уровень владения ООП на примерах точка->линия->фигура или животное->кошка, это как проверять знание арифметики счетом на пальцах. Проверить можно, но уровень владения не покажет.
знаешь, что такое ложная дихотомия?
познал такую абстракцию, как синглетон
если тебе нужно познавать такую дико сложную абстракцию как синглтон, то у тебя некотоорые проблемы с фундаментальными знаниями, и в проектирование тебе пока рано
это уже показатель
это показатель того, что ты смог заучить реализацию некоторой абстракции. скорее всего - не понимая, зачем её вообще ввели
это показатель того, что ты смог заучить реализацию некоторой абстракции.
А что это, как не показатель уровня владения чем-либо?
Позволю себе с вами не согласиться. Например, вы знает на зубок теорему Пифагора, если вас поднять среди ночи, вы докажите ее без промедления. Но вот на практике в реальной жизни не видите ни одного случая, где бы ее можно было применить. Это и отличает знание от понимания (читайте «смог заучить» от «уровня владения»).
ты предлагаешь безальтернативный выбор из двух частных случаев, один из которых заведомо хуже агитируемого. это дешёвый демагогический ход
А что это, как не показатель уровня владения чем-либо?
заучивание никогда не является показателем владения
не так давно один товарищ на собеседовании отвечал на вопрос, чем процесс отличается от потока; он сказал, что потоки делят общее адресное пространство, а процессы - нет. показатель? владение? следующим был вопрос о том, как можно передать данные между потоками одного процесса; он ответил, что не знает, и что, скорее всего, это невозможно
с тем же успехом человек, заучивший реализацию классических паттернов, может совершенно не уметь проектировать. ни в ОО-стиле, ни в каком либо другом
Я вызубрил теорему Пифагора, и знаю что в определенных условиях a^2 + b^2 = c^2. Как, почему и зачем так получается мне уже неинтересно, я успешно нахожу «c» и без знания доказательства. Это один уровень владения. То что я не знаю доказательства, не мешает мне применять для решения задач.
Но мы же не придираемся друг к другу, а ведем культурную беседу, почему бы и не поиграть :) Придираются тут некоторые стоящие особняком личности.
Как, почему и зачем так получается мне уже неинтересно, я успешно нахожу «c» и без знания доказательства. Это один уровень владения. То что я не знаю доказательства, не мешает мне применять для решения задач.
Хм. Грубо говоря, у вас спрашивают детскую задачку — «из точки A выехали две фуры, одна движется строго на север со постоянной скоростью 50 миль в час, другая строго на запад со скоростью 60. Вопрос, какое между ними будет расстояние через 3 часа». Но если вы не применяли теорему Пифагора уже 10 лет на практике, но все еще помните формулировку (даже без доказательств, фиг с ними), не факт что вы сходу ее примените для решения именно этой задачи. Может быть вы еще начнете изобретать велосипед, кто знает. А вот если бы вы работали каждый день с подобными данными, вы бы применили ее не задумываясь. Я рассуждаю с этой точки зрения. Знать != применять.
Я просто не понимаю, почему применение - это уровень владения, а знание - нет?
Почему нельзя выделить уровни владения, начиная с нулевого «не знаю, что такое ООП», «знаком с парадигмами», «пишу с использованием классов и объектов не понимая зачем они нужны» и т.д. по возрастающей?
Эм. Ну я думаю потому что владеть знанием != владеть опытом. Т.е. вы знаете как молотком забить гвоздь, любой это знает. Т.е. владеет знанием. Но не каждый сможет сходу забить десятку в балку с 3-4 ударов, причем ровно и без косяков. Это уже называется владеть опытом. А опыт приходит только с практикой. Я думаю это и есть причина, почему мешать уровень владения знанием и уровень применения на практике — не лучшая затея.
Почему нельзя выделить уровни владения, начиная с нулевого «не знаю, что такое ООП», «знаком с парадигмами», «пишу с использованием классов и объектов не понимая зачем они нужны» и т.д. по возрастающей?
Что касается уровней, не знаю. Скорее всего можно, но вот такая шкала будет отражать только уровень знания, но не уровень владения знанием.
С выходом питона 3.4, я стал в скриптах использовать @asyncio.coroutine, yield from etc.. Спросите меня про то, как работают сопрограммы и я начну в ответ что-то мямлить про конкурентность и в итоге замолчу.
Вопрос, мой код перестанет быть ассинхронным от этого?
Можно назвать мой уровень «уровнем владения»?
Понятно, что зная как оно работает, я бы эффективней использовал этот инструмент. Но, магия, оно работает и без этого, чисто по аналогии с документацией библиотеки!
Этого же мало для оценки уровня владения ООП, вам не кажется?
мало. и я об этом уже написал. дважды. а ещё я написал что из этого не следует, что паттернов достаточно
А умение применять, не понимая как это работает?
это уровень интерна в лучшем случае. monkey job
не очень-то много и предложили
а давай такой: берём задачу, берём критерии выполнения, делаем реализацию, оцениваем реализацию. то же самое, что в GoF, только начинаем с задачи, а не с решения. задачу берём из предметной области
Не не не... Я не хочу меряться ничем!
Я просто так же, как и ТС хочу понять, как можно оценить «уровень владения ООП» и вообще, какие уровни можно выделить.
Понятно, что зная как оно работает, я бы эффективней использовал этот инструмент. Но, магия, оно работает и без этого, чисто по аналогии с документацией библиотеки!
А если вам нужно будет сделать что-то, что выходит за пределы документации? Возьмем те же генераторы что вы привели выше. Скажем вы хотите понять, для чего можно использовать возврат в 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
владение ООП - это умение решать задачи проектирования с помощью ООП. не знание готовых решений, не знание трёх китов, не чтение статей Карделли, не умение отнаследовать ежа от ужа, и даже не знание устройства таблицы виртуальных функций (или её аналога)
владение ООП - это умение решать задачи проектирования с помощью ООП. не знание готовых решений, не знание трёх китов, не чтение статей Карделли, не умение отнаследовать ежа от ужа, и даже не знание устройства таблицы виртуальных функций (или её аналога)
Согласен. Но это, наверное, потолок. Должны же быть уровни и для тех, кто только знает чем класс отличается от объекта?
Дать ссылку на свой GitHub. А мы всё обругаемрасскажем. Если GitHub-а или Bitbucket-а, или чего-то аналогичного нет (а ты не разрабатываешь уже несколько лет на профессиональном уровне), то, скорее всего, всё довольно печально.
Т.е. если не писал код 2 года. То уровень владения ООП низкий да?
Если честно это самый неожиданный критерий )
Дать задачи на инкапсуляцию, наследование, полиморфизм, их комбинации.
а сочинять музыку учиться, играя гаммы?
ты часто в рамках рабочей деятельности решаешь изолированные задачи на инкапсуляцию, полиморфизм и наследование? или синтетические задачи на их комбинацию?
зачем проверять одно умение, если фактически нужно другое?
это основы. умение проектировать решение должно быть с самого начала, со временем просто должна расширяться область решений. нет качественной разницы в обучении абстракции потока выполнения функциями и проектировании объектной иерархии
Должны же быть уровни и для тех, кто только знает чем класс отличается от объекта?
давай назовём их оценками, а этих людей - учащимися на программистов, и всё встанет на свои места
Я думал люди это трут и забывают как страшный сон. Лично я так и сделал :)
А те люди, которые это хранят, в большинстве своем просто постесняются давать это на обозрение. И правильно сделают.
А вы свои первые хелловорды все храните? :)
Вот и зачем людям нужны такие примеры? Они даже слабо показывают зачем вообще нужны сопрограммы. Вы совращаете неокрепшие умы, вас могут неправильно понять :)
Берешь какую-нибудь задачу, рисуешь UML диаграмму к ней и выкладываешь сюда :D
Пример задачи: Спроектировать компьютерную игру, например настольная или стратегия, пошаговая (но это не обязательно), с возможностью мультиплеера (по сети, интернету, на одном устройстве) и сингл плеера.
Вот, сможешь набросать диаграмму классов/объектов, провести анализ юз кейсов, считай, что ты знаешь ООП.
это небольшой пример из всё-таки большого раздела документации по asyncio и конечно же он из контекста выдран. Как мне кажется он всё-таки показателен, что не зная, как работают сопрограммы, дает некое понимание, для чего их можно использовать.
Сложно гадать, что ему в голову придет, когда он увидит по этому примеру вывод: Неужели по этому примеру нет над чем подумать?
Дело в том есть или нет. Дело в том какую пищу для размышления дает та или иная информация. А вы не думали, что прочитав ваш пример, какой-нибудь поехавшик фрик начнет применять это как фундамент для реализации элементарной линейной многозадачности, а-ля замены multiprocessing (или как это там у вас в питоне называется)? Вас не посещали такие мысли? :)