Подскажите мне как оценить свой уровень владение ООП? уровень владения
Вам по какой шкале? ООП это методология, т.е. система каких-либо принципов/положений/методов/etc. Те кто говорят «знаю ООП», или «владею ООП на определенном уровне» (почти всегда это значит что они постигли дзен, конечно же), обычно подразумевают под этим свои влажные фантазии. Не более.
Есть ли какой нибудь стандарт ООП?
Как и у любой системы, у ООП есть свой фундамент, сейчас вам здесь расскажут о трех китах, и прочем бреде.
Для того чтобы научиться понимать какую-либо систему, нужно постоянно работать с ней. ООП не исключение. Практика — это и единственная возможность «понять ООП», и единственная возможность оценить «уровень владения», как не странно.
Поэтому, чтобы понять оценить свой «уровень владения», в этом же треде сами себе задайте задачу, и сами спроектируйте ее объектную структуру. По результатам вы все поймете сами.
Если же вам нужны просто тесты на знания элементарных вещей — в интернете их полно. Как правило это тесты с вопросами в духе «чем абстрактный класс отличается от интерфейса?» бла-бла-бла и прочий бред.
Дать ссылку на свой GitHub. А мы всё обругаемрасскажем. Если GitHub-а или Bitbucket-а, или чего-то аналогичного нет (а ты не разрабатываешь уже несколько лет на профессиональном уровне), то, скорее всего, всё довольно печально.
Именно так. Не только умение увидеть, но и самому запилить фабрику, обсервер etc.
ООП - это абстракция. Дизайн-паттерны - тоже абстракция, как мне кажется их навязывают в большой мере для того, чтобы оправдать применение ООП.
И для оценки уровня владения ООП совсем не важен ЯП.
Не забывайте «применение объектно-ориентированного языка вовсе не означает, что код автоматически становится объектно-ориентированным».
Проверять уровень владения ООП на примерах точка->линия->фигура или животное->кошка, это как проверять знание арифметики счетом на пальцах. Проверить можно, но уровень владения не покажет.
А если, к примеру, ты познал такую абстракцию, как синглетон, да, ещё и реализовать её можешь на конкретном инструменте - это уже показатель.
да нет. паттерны - это паттерны. они к ООП отношения не имеют и могут быть реализованы и без ООП. это маленько другой уровень.
а сам по себе ООП - это просто одна из фич ЯП. ну, в некоторых языках без него вообще нельзя программировать. сам по себе ООП - понятие, скорее, самоценное для студентов. на практике, конечно, паттерны и конкретный опыт работы важнее. а чисто чтобы «знать ООП» - это именно задачки про кошек и треугольники.
да с хрена ли? начнём с того, что я могу хоть на ассемблере эти ваши классы реализовать. просто на ассемблере оно даром не нужно и вопрос целесообразности встаёт.
люди-то жили и до ООП. и всё работало.
Начнём с того, что я могу хоть на ассемблере эти ваши классы реализовать.
Тогда ваш код автоматически станет ООП. ООП — это подход, по сути, один из паттернов, удобство реализации которого стало популярно внедрять в поддержку на уровне ЯП.
блин, да возьмите любую старую софтину на С, когда никаких классов не было. структурки, указатели на функции, вот это всё. думаете, откуда все эти ваши игрушки с ООП появились? именно оттуда. просто за вас это компилятор теперь делает, а мы раньше всё ручками писали. а то, что на С можно написать, на ассемблере тоже можно. я в своё время игралась и писала графические приложухи на ассемблере. сейчас я на нём редко пишу. у меня более важные задачи есть. так что отошлю вас самостоятельно поработать над этим заданием для студентов.
Я говорю, что знанием паттернов можно проверить уровень владения ООП. Это разные вещи.
а я говорю, что нет. например, есть паттерны для эмбеддеда, есть паттерны для микроконтроллеров и т.д. и никакого там ООП даже близко. и даже ООП-шные паттерны можно реализовать вовсе без ООП. сложнее технически, но можно. так что паттерны - это паттерны.
Тогда ваш код автоматически станет ООП. ООП — это подход, по сути, один из паттернов, удобство реализации которого стало популярно внедрять в поддержку на уровне ЯП.
ну, теоретически да. но тогда надо выяснять, что обзывается ООП: встроенная в ЯП подсистема или абы какая реализация. а то можно дойти до сомнительного утверждения, что для знания ООП достаточно реализовать синглтон на ассемблере :)
для начала надо дать точное определение ООП.
потому что «ООП в вакууме» существует только в теории. наверное, рисование абстрактных схем в UML нотации и есть «стандарт ООП» в чистом виде, без привязки к конкретике.
Всем :)
Singleton, в первую очередь, порождающий паттерн, следовательно он дает нам возможность абстрагироваться от способа/процесса создания. Вы же главного поинта паттерна не соблюдаете, поэтому ваш вариант паттерн не реализует.