Какой смысл ООП?
Я не уверен, как это делается в CustomScrollView, но вы можете попробовать это:
Scaffold(
body: NestedScrollView(
headerSliverBuilder: (BuildContext context, bool innerBoxIsScrolled) {
return <Widget>[
SliverAppBar(...),
];
},
body: ListView.builder(..),)
);
43 ответа
Я знаю, что нахожу ООП полезным в значительной степени только на синтаксической сахарной основе (инкапсуляция, перегрузка оператора, typechecking). Относительно преимуществ ООП... Я не знаю. Я не думаю, что это хуже , чем процедурный материал.
На более легкой стороне, мой лектор ООП сказал, что ООП важно, потому что иначе "код имел бы слишком много циклов". Да. Иногда это является угнетающим, что я плачу 500$ на бумагу. :(
Мне значение ООП должно уменьшить объем и разделить состояние от поведения. С меньшим объемом код легче понять.
Это может быть сделано на большинстве языков, все необходимо для достижения, это - путь к состоянию для делегирования вызова метода поведения и пути к поведению для дальнейшего делегирования вызова к родительскому поведению.
, чтобы иметь ряд классов моделируют домен эффективным способом, нет никакого волшебного метода. Как фортепьяно, мы должны практиковать. ООП является абстрактным инструментом, оно может помочь Вам создать код более простым способом, но оно не может думать и проанализировать домен Вашего приложения для Вас.
, Какие работы для меня должны остаться близко к домену максимально долго, все еще избегая большинства дублирований кода.
ООП помогает разделить интерфейс от реализации. Вам не нужна поддержка ООП на языке для пользы из дизайна OO.
Один небольшой пример, где ООП помогло чрезвычайно:
подарки уровня UNIX Virtual File System (VFS) универсальный интерфейс (открывают/читают/пишут) таблицы использования указателей функции - во многом как C++ виртуальная отправка таблицы.
Клиенты используют тот же набор вызовов независимо от того, говорят ли они с локальной файловой системой, удаленная сеть Файловая система (NFS) или (сегодня) поддельные файловые системы (например,/proc).
См. исходную газету Sun: Vnodes: Архитектура для Нескольких Типов файловой системы в Sun UNIX
Мы скажем то же самое десять лет с этого времени о функциональном программировании?
Реальным миром не является "OO". Реальный мир не в основном структурирован от разумных частей. Вместо этого это сделано из хаотично движущихся частиц. Земля является супом частицы. Все еще люди видят птиц, деревья, небо, землю, леса, водоемы. OO об абстракции компонентов программы. Это существенно испорчено для размышления о OO для моделирования чего-то еще, чем программы.
Всем деньгам и время не удалось сделать программное обеспечение немного лучше, потому что этому не удалось сделать программистов более умными, также потому что этому не удалось изменить путь, как люди думают о программном обеспечении. "ООП" в смысле, Вы используете его, является модным словечком, используемым для получения денег из идиотов. Да, люди, которые поместили деньги на образовании "ООП" и инструментах, являются идиотами. Люди, которые склонны падать на обманы, склонны быть идиотами.
значение "ООП" является абстракцией и повторным использованием кода внутренняя часть та же программа . ООП предназначено, чтобы использоваться с обязательными программами.
, Если Вы встаете от ассемблерных подпрограмм. Блок является заказанными последовательностями пар, составленных из маркировок и инструкций. Ассемблерный код подобен 'супу частицы'. Теперь можно переместиться в подпрограмму. Подпрограмма выбирает маркировку от того label:instruction - суп и скрывает остальную часть маркировок в подпрограмме. Поскольку код эффекта становится более абстрактным, и Ваше пространство имен остается более чистым.
Теперь, если Вы думаете, что делают подпрограммы... Немногие из несколько десятилетий назад люди думали, что подпрограммы в своих лучших проявлениях, когда они работают над аргументами. Это сделало их для предоставления каждого объектного своего собственного протокола. Протокол содержал бы label:procedure - пары. Теперь названный selector:method - пары. Процедуры больше не связывались непосредственно с другими процедурами, объясняя 'позднее связывание' - термин. Наряду с хранением истории из протоколов (наследование), это сформировало 'объектную ориентацию' в smalltalk.
Вас вывели из строя механизм позднего связывания и забыли, что означает наследование. И Вы все же задаетесь вопросом, что Вы пропускаете там. "Где значение ООП, и почему имеет все время, и деньгам не удалось сделать программное обеспечение немного лучше?" - я думаю, что Вы наполнили их в свою задницу. Когда Вы попытаетесь к колоноскопии, Вы найдете их.
, Возможно, шляпа, полировка или дерево не являются стулом, но они все - ISittable.
Да, но только действие с обратной силой. Они - ISittable, потому что кто-то сидел на них.
ООП имеет уменьшенные затраты и увеличенная эффективность.
, Когда я сделал переход от классического ASP/VBScript до C#, я заметил ОГРОМНОЕ увеличение производительности благодаря ООП.
Я соглашаюсь с InSciTek Jeff. Даже если Вы не используете OO в его самом чистом смысле, Теория Инкапсуляции может помочь уменьшить потенциальную структурную сложность: http://www.edmundkirwan.com
DrPizza
, Если procedureal программирующее использование преимущества инкапсуляции до того же градуса, затем хорошего на нем!
Это только , портативная языком методология для хранения переменных группировалась с функциями/методами/подпрограммами, которые взаимодействуют с ними.
"Даже если нет никакого фактического [информационная архитектура], это, doesn’t означают нас, don’t испытывают или чувствуют его как таковой. Дзен-буддисты говорят, что нет никакого фактического “self”, но они все еще называют своих детей. "-Andrew Hinton
ДЕСКРИПТОРЫ (и остальная часть WinAPI) ООП!
они, хотя? Они весьма наследуемы, они, конечно, не substitutable, они испытывают недостаток в четко определенных классах... Я думаю, что они падают длинный путь за исключением "ООП".
There are already a lot of answers on this as this is an old post but i thought i'd chime in.
You mention "class taxonomy" a bit which gets into subtyping and polymorphism. This all revolves around inheritance which in it heyday was considered the silver bullet of OOP. Nowadays, inheritance and large class hierarchies are actually discouraged, even among shops that do a lot of OOP. This is because the other pricinples of OOP, such as encapsulation, loose coupling, cohesion and so forth have been found to be far more useful than inheritance. I would even go so far to say that loose coupling is the reason for OO, not code reuse. Code reuse usually happens at the method/function level. I do sometimes reuse classes under different circumstances, but not that often. Loose coupling though helps organize a system quite a bit. Each object has its own scope, the data in the object isn't or should not be manipulated except by accessor methods or properties, each object should do one simple thing and should talk to other objects thru simple interfaces. This handful of principles helps code readability, helps isolate bugs and prevent you from having to make many changes in lots of different places to change one thing. When objects are not closely intertwined, you can change one without affecting others. This has been a huge benefit to me. Inheritance is useful only now and then.
Code reuse is still important and if you are copying and pasting or rewriting the same code, thats a bad practice even under plain old procedural, structured or functional programming. That actually increases costs due to duplicated effort, increased maintenance and more bugs.
>>> a=12345
>>> a.__str__().__len__()
5
Из моего опыта, который начался в C/Unix (не OOP) в середине 1980-х годов, затем перешел на C++ (OOP) в 1990 году, а затем на Java около 1996 года (OOP), я обнаружил, что OOP дает огромный толчок производительности, ремонтопригодности и надежности по сравнению с большими не
Главное, что я заметил, что в приложениях, не связанных с ООП, я работал над сложностью, казалось, рос с экспоненциальной скоростью в отношении сложности приложения, тогда как в приложениях, связанных с ООП, я работал над сложностью, казалось, имел гораздо более линейную связь с учетом сложности приложения.
Другими словами - с хорошо разработанными приложениями ООП вы никогда не получаете, что "OMG исходный код для этого приложения выходит из-под контроля" ощущение, что вы получаете с большими приложениями не ООП.
Другие вещи, без которых я не могу обойтись как разработчик ООП, - это способ написания кода, который моделирует реальные сущности, существующие в проблемной области приложения. Объекты обретают собственную жизнь - далеко за пределы того, что делали любые структуры (C) или Records (Pascal) в плохие старые =] дни не ООП.
Одно из условий состоит в том, что главный архитектор проекта ООП должен знать, что он делает, и он обычно должен уделять больше времени размышлению, чтобы получить правильный дизайн, чем на самом деле реализовать его, но расплата за "мышление вещи вперед" действительно удивительна. Возможности для повторного использования или потрясающе прохладной оптимизации дизайна появляются на свет, что вы пробиваете воздух и совершаете приземления в офисе... хорошо, это может показаться немного странным для других в офисе, но такого энтузиазма никогда не было в дни, не связанные с ООП:)
Я видел какой-то довольно плохо написанный код ООП и, возможно, это то, что вы испытали, что, возможно, привело вас задать вопрос. В качестве подрядчика в середине 90-х я часто находил, что проект "OO" уже был начат тем, кто знал, что такое класс, но не намного больше. Это был очень болезненный опыт, и я часто находил, что мои первые несколько месяцев работы включали в себя обучение команды совершенно другому образу мышления "OO". Только после того, как мозг каждого был перемотан, мы все могли действовать как команда, чтобы создать что-то потрясающее.
Многие люди считают процесс "перемотки мозга" слишком сложным,болезненные или просто слишком много усилий и так провести свою жизнь dissin 'OOP, и так вы найдете много ненавистников OO там, но я рад этому, потому что это те люди, которые делают таких, как я, выглядят хорошо: "Что, вы можете сделать это за $ X, и он будет готов через 2 месяца, и вы дадите нам поддерживаемую базу кода!!! Вау, можешь начать сегодня? "