Результаты поиска

Согласен +100500, но и пренебрегать ими тоже чревато последствиями. Чтобы воспользоваться любым из них - нужно пропустить через себя то, что каждый принцип проповедует. Тогда не просто сможешь слепо следовать, но и грамотно объяснить, почему здесь вот так, а не иначе, а тут вот так)

Принцип L в SOLID можно обходить(формально), делая запечатанные (sealed)/финальные (final) классы и наследуясь с абстрактных. Но следует помнить, что любое внесение изменений в такой абстрактный класс (особенно если класс на продакшене уже вышел) повлечет (может повлечь) за собой изменение в...

@PianoIst, Попробуй применять I и D в SOLID. Но опять таки принцип I гласит, что "много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения". С этим согласен, но тут возникает другая проблема - взрыв интерфейсов, когда их становится настолько...

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

@PianoIst, Даже не знаю, что ответить, так как не разу не системный архитектор)). Думаешь, делаешь реализацию в крупных блоках, потом уменьшаешь уровни абстракции . Потом, по ходу, приходят мысли, как сделать лучше, что можно вынести -> рефактришь свой код. Хорошая мысль может придти вообще в...

ухх...ничего не понял из таблицы. Лучше бы диаграмму классов нарисовал в бесплатной Visual Studio например) Из SOLID самый геморный и трудно понятный для меня - это имхо - это барабары лисков))) Типа, что должна быть возможность вместо суперкласса подставить его наследника без изменения логики...

@andy felon, В мае вроде альбом новый. Будем посмотреть) В целом теже изъезженные ходы, но Аморфис моя слабость)

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

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

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

А в деле унификации в ООП можно пойти еще дальше (зависит от языка). Но это уже идет усложнение. Метод вычисления расстояния Distance() на самом деле объявить делегатом, а в конструктор объекта или в инициализационный метод, который будет вызван при конструировании объекта, например билдером...

@SuperDroid, Да, примерно так, но насколько оправдан таймер внутри объекта - еще вопрос) Можно по разному делать. Вот допустим, если есть внешний рендер, представляющий из себя бесконечный цикл, каждая итерация которого изменяет временную константу и время в нем просчитывается(по типу игрушек)...

@Alex_V, Опишу свой опыт горький. Как-то заюзал я в одном проекте с базами данных, который мы с другом вместе пилили с нуля, связку C#+Nhibernate+PostgreSQL. База получилась не очень большая, всего-то 35 связанных таблиц. Ну и для NHibernate пришлось аналог базы в объектах налепить(для...

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

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

А оно кстати интересно, после какого-то времени программирования, когда набираешься некого опыта, заново вернуться к таким статьям, которые читал еще до того и переосмыслить их с учетом нового полученного опыта)))

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

Есть еще вот такая вот статейка: https://habrahabr.ru/post/147927/ Что скажете?

https://ru.wikipedia.org/wiki/Парадигма_программирования

Не очень понял про какую документацию и спецификацию вы говорите, тем более официальную, но для ООП попробуйте начать с классики банды четырех: Приемы объектно-ориентированного программирования. Паттерны проектирования https://docs.google.com/file/d/0B6GuCegBf3X3Tm1rZl9BUTduQm8/edit Понимание и...

Сам хочу питон начать изучать, но как-то не подворачивается случай начать. Нет стимула чтоли) А самому писать hello world неинтересно).

Я старался максимально не использовать семантики каких то конкретных языков Как правило они все сводятся к одним и тем же принципам У нас язык совмещает не только ооп, но и процедурное программирование. Отсюда юниттесты не только классов, но и процедур и функций в библиотеках. Но принцип...

Это как один из вариантов. И нет, это не js. Пусть у питона будут другие варианты тестирования, я питон не изучал, к сожалению. Прогресс не стоит на месте. И я не спорю по конкретному языку, я написал один из примеров как можно пользоваться юниттестами. В том проекте, где работаю я, нет...

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