Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд.
Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.
Просто беру и делаю, стараясь делать качественно, насколько это возможно, не слишком увлекаясь.
Делать просто хорошо не намного дольше, чем делать кое-как.
Вот потом уже рано или поздно нужно будет остановиться, посмотреть на то, что получилось и устроить хороший еврорефакторинг. В вашем случае это когда-нибудь придется делать тому, кто будет поддерживать ваш продукт, иначе лопнет. Но с вашими короткими проектами эта проблема вашей не станет.
Здравствуйте, licedey, Вы писали:
L>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд. L>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.
Дык разбивать на классы, функции и т.п. нужно не ради причастности к модному движению, а для того чтобы код было легко развивать и поддерживать.
По сему классы нужно вводить только когда другие пути дают худший результат. В прочем, есть задачи которые классами описываются лучше. Это задачи симуляции, т.е. когда нужно построить некоторую модель, "запустить" ее и наблюдать за тем как она себя поведет под воздействием входных данных. Но таких задач не так уж и много. И зачастую ООП-ом начинают решать задачи ему не свойственные. Вот это и есть ООП головного мозга.
Чтобы такого не случалось нужно кроме ООП познать и другие парадигмы. Как минимум имеет смысл освоить ФП, МП/DSL.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, abibok, Вы писали:
A>Вы так говорите как будто запрограммировать в не-ООП стиле получится быстрее. Это то же самое что говорить что без юнит-тестов получится быстрее.
L>Задачу на неделю для фриланса?! Конечно быстрее.
Что именно — первое или второе? По поводу второго еще можно поспорить, а с первым-то как? Вы давно писали что-нибудь в не-ООП стиле? Мне пришлось бы заставлять писать себя так, и это было бы явно медленнее, не говоря уже об отладке и сопровождении.
Здравствуйте, licedey, Вы писали:
L>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд. L>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость
смотря, что за задача. кстати, а чем класс от объекта отличается? и чем они вместе отличаются от модулей?
> не дает нужного результата в релизе. Скажите как вы делаете задание с нуля.
смотрю, какие сущности и какой функционал мне потребуется для решения. и начинаю реализовывать это отдельными модулями, максимально абстрагированными друг от друга, а потом свожу их воедино. но это _сильно_ зависит от задачи. создание "с нуля" подразумевет, что этого еще никто не делал (или делал, но недоделал) и потому сначала нужно провести ресерч. потом заточить прототип. вы сочинения в школе тоже начисто сразу писали? или нет? наверное черкали, резали, а потом выбрасывали, меняли местами и склеивали. так и в программировании. начисто с нуля ничего не делается.
> Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.
зависит от того кому это поддерживать
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, abibok, Вы писали:
L>>Задачу на неделю для фриланса?! Конечно быстрее.
A>Что именно — первое или второе? По поводу второго еще можно поспорить, а с первым-то как? Вы давно писали что-нибудь в не-ООП стиле? Мне пришлось бы заставлять писать себя так, и это было бы явно медленнее, не говоря уже об отладке и сопровождении.
А вы уверены, что вы вообще хоть когда нибудь писали в ООП-стиле?
Вот я чем дольше работаю, тем меньше вижу ентое ООП.
Более того, очень многими неглупыми людьми ставится под сомнение его полезность. Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, abibok, Вы писали:
L>>>Задачу на неделю для фриланса?! Конечно быстрее.
A>>Что именно — первое или второе? По поводу второго еще можно поспорить, а с первым-то как? Вы давно писали что-нибудь в не-ООП стиле? Мне пришлось бы заставлять писать себя так, и это было бы явно медленнее, не говоря уже об отладке и сопровождении.
L>А вы уверены, что вы вообще хоть когда нибудь писали в ООП-стиле?
полностью поддерживаю. многие языки (не плюсы) имеют ооп чисто для галочки. и ведь живут. к тому же, если мы в плюсах создадим класс "сортировка" (с кучей разных алгосов сортировки), то это будет не ооп, а модульное программирование, потому что "сортировка" это не сущность. это действие, выполняемое над некоторыми сущностями (массивами, списками...). загнать разные методы сортировки в один класс можно, но что мы получим в результате? обыкновенный модуль, но не объект.
и потом, если взять два достаточно крупных проекта -- например, Spider Monkey (си) и Google V8 (плюсы), то в первом легко разобраться и с ходу начать дотачивать код под свои нужды. нужно прикрутить логгер -- берем и прикручиваем. а теперь смотрим на приплюснутый код. вообще-то он не совсем приплюснутый. он даже хуже. половина движка java script написана на спец-реализации самого java-script и взаимодействует с приплюснутым кодом очень нетривиальными путями. просто воткнуть fopen/fprintf не получается. и приходится в одном месте создавать новый интерфейс, а в другом месте его юзать. причем данные имеют жутко сложную структуру. итераторы всякие везде... да еще и с разными типами... хосподи. записать аргументы функции в файл -- это кошмар на улице вязов.
L> Более того, очень многими неглупыми людьми ставится под сомнение его полезность.
про все ооп не скажу, но вот никак не могу понять -- действительно ли язык программирования должен быть таким сложным, как плюсы? действительно ли у программиста должна болеть голова за виртуальные деструкторы? говорят, что плюсы обеспечивают высокую производительность. и где же она? куча программ на жабе не сильно уступает аналогичным программам на плюсах. хваленный сверхбыстрый движок гугла написан не только на плюсах, но и на жаба скрипте, причем там такие критические фрагменты кода, как, например, операции с массивами. вероятно, на этот шаг пошли по соображениям безопасности. чтобы память не текла и буфера нежиданно не переполнялись.
вот я и думаю -- а что мне дадут плюсы, если их выучить? питон мне дал высокую продуктивность и учить его не пришлось (так, полистал книжку на выходных), java script дала высокую портабельность (работает _везде_, включая мобилки и опять без затрат на обучение), чистый си дает производительность, но нам нем пишутся только самые низкоуровневые компоненты, а обвязка -- жаба, питон, руби или скала.
у плюсов же -- производительность только в теории, на практике оно тормозит и отжирает память (если, конечно, пользоваться приплюснутыми фичами на полную). программы сложно писать и еще сложнее понимать. с компиляторами и платформами сплошная чехарда. даже плагин для популярных программ обычно нужно писать на том компиляторе, которым собиралась сама программа.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Sorc17, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>Чтобы такого не случалось нужно кроме ООП познать и другие парадигмы. Как минимум имеет смысл освоить ФП, МП/DSL.
S>Посоветуйте, что почитать, чтобы асилить этот МП/DSL? Желательно "для чайников", ибо раньше никогда не пробовал
Внутренние языки, специфичные для предметной области: здесь
Здравствуйте, Lloyd, Вы писали:
L>Более того, очень многими неглупыми людьми ставится под сомнение его полезность. Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
Почему это анемик процедурный ? Если смтореть про инкапсуляцию как у Скота Мейерса, то ООПшность это именно переход от рич к анемик.
Здравствуйте, Ikemefula, Вы писали:
L>>Более того, очень многими неглупыми людьми ставится под сомнение его полезность. Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
I>Почему это анемик процедурный ?
Потому что имеем разнесение данных и способов работы с ними. Может "процедурный" и не самое удачное слово, но вот "ООП" уж тут точно ни в какие ворота.
I>Если смтореть про инкапсуляцию как у Скота Мейерса, то ООПшность это именно переход от рич к анемик.
Здравствуйте, Lloyd, Вы писали:
L>>>Более того, очень многими неглупыми людьми ставится под сомнение его полезность. Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
I>>Почему это анемик процедурный ?
L>Потому что имеем разнесение данных и способов работы с ними. Может "процедурный" и не самое удачное слово, но вот "ООП" уж тут точно ни в какие ворота.
ООП как раз никуда не девалось
I>>Если смтореть про инкапсуляцию как у Скота Мейерса, то ООПшность это именно переход от рич к анемик.
L>Я не знаю, какая инкапсуляция у Мейерса.
Здравствуйте, licedey, Вы писали:
L>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд. L>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.
ООП — это инструмент управления структурной сложностью. Если программа простая, с коротким циклом поддержки (пофиксил баги и забыл), то на красивый дизайн можно забить. Конечному пользователю все равно что внутри, заказчику тоже пока корявость кода не бьет ему по карману стоимостью поддержки и модификации.
Здравствуйте, Ikemefula, Вы писали:
I>>>Почему это анемик процедурный ?
L>>Потому что имеем разнесение данных и способов работы с ними. Может "процедурный" и не самое удачное слово, но вот "ООП" уж тут точно ни в какие ворота.
I>ООП как раз никуда не девалось
У вас видимо свое понимание о том, что такое ООП, отличное от распространненной трактовки:
Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.
А вот собственно отличие от процедурного программирования:
The most important distinction is whereas procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together so an "object", which is an instance of a class, operates on its "own" data structure.
Здравствуйте, мыщъх, Вы писали:
М>то это будет не ооп, а модульное программирование, потому что "сортировка" это не сущность. это действие
Сущность может быть и действием и ещё много чем. Есть в ООП такая штука, как различные типы классов (я в литературе встречал название "типы объектов", но мне оно кажется не правильным). Какие-то классы описывают предметы, другие — действия, ... Их там 4 типа, оп-моему. Надо спросить у хорошо подкованных в теории ООП, они должны знать
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Lloyd, Вы писали:
I>>ООП как раз никуда не девалось
L>У вас видимо свое понимание о том, что такое ООП, отличное от распространненной трактовки: L>
L>Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.
Это слишком общая формулировка. Разве здесь сказано, что "все структуры данных должны иметь хотя бы один метод для работы с этими данными" ?
L>А вот собственно отличие от процедурного программирования: L>
L>The most important distinction is whereas procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together so an "object", which is an instance of a class, operates on its "own" data structure.
И это слишком общая формулировка. Ты их из википедии что ли надёргал ? Класс спокойно может выполнять операции над своими членами, каждый из которых м.б. простой структурой данных.
L>Вы все еще уверены, что anemic — это ООП?
Вот пример про анемик из соседнего форум. Есть бизнес сущность Account, необходимо сделать трансфер средств из одного на второй.
var rep = new AccountRepository(Application.Db);
var account1 = rep.LookUpFor(id_1);
var account2 = rep.LookUpFor(id_2);
var svc = new TransferService(account1, account2, Application.CurrencyRates);
svc.Transfer(100,Currency.USD);
Ты хочешь сказать, что если класс Account это простая структура вообще без всяких методов, то код выше перестаёт быть ООП ?
Для сравнения, рич
var rep = new AccountRepository(Application.Db);
var account1 = rep.LookUpFor(id_1);
var account2 = rep.LookUpFor(id_2);
account1.TransferTo(account2, 100, Currency.USD); // опаньки, нарушение инкапсуляции
Здесь Account наделили методами и стало ООП ? Всего то изменились классы и обязанности и теперь класс придется модифицировать по любому поводу.
Здравствуйте, Ikemefula, Вы писали:
I>>>ООП как раз никуда не девалось
L>>У вас видимо свое понимание о том, что такое ООП, отличное от распространненной трактовки: L>>
L>>Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.
I>Это слишком общая формулировка. Разве здесь сказано, что "все структуры данных должны иметь хотя бы один метод для работы с этими данными" ?
Конечно общая. ООП — это вообще довольно мутное понятие.
L>>А вот собственно отличие от процедурного программирования: L>>
L>>The most important distinction is whereas procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together so an "object", which is an instance of a class, operates on its "own" data structure.
I>И это слишком общая формулировка. Ты их из википедии что ли надёргал ? Класс спокойно может выполнять операции над своими членами, каждый из которых м.б. простой структурой данных.
И что?
L>>Вы все еще уверены, что anemic — это ООП?
I>Вот пример про анемик из соседнего форум. Есть бизнес сущность Account, необходимо сделать трансфер средств из одного на второй. I>
L>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд. L>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.
Критерий простой — если программа будет в дальнейшем модифицироваться (изменение и уточнение требований в будущем, либо банальная инкрементальная разработка), то без нормальной архитектуры и хороших тестов это сделать будет невозможно.
