ООП - кто пользуется?- Разработка программ

Гость

0 - 26.05.2012 - 18:25

Помню, раньше столько пели про ООП! А сейчас смотрю на реальные проекты - ООП в чистом виде практически не используется. А вы используете ООП?

Гость

1 - 26.05.2012 - 20:46

Я тоже сегодня коньячка накатил, соточку :-)

А что есть ООП в "грязном" виде?

Гость

2 - 26.05.2012 - 21:06

В чистом виде ООП это Object.Property=Object.Attribute
...
В реальных проектах используется все - от быдлокодинга до ассемблера. А ООП - это всего лишь парадигма программирования. То есть мода/течение/жизненный этап развития.

Гость

3 - 26.05.2012 - 21:09

Блин, я тоже :)

В чистом виде - когда сначала прописывают все классы, а потом уже алгоритмы. Часто бывает, что в классе по два метода.

В грязном виде - классы используют только в том случае, когда нельзя обойтись простой функцией.

Гость

4 - 26.05.2012 - 21:22

Пользуюсь но без крайностей )

Гость

5 - 26.05.2012 - 22:06

ООП... ИМХО - это подход, когда данные неотделимы от кода. Т.е., если раньше можно было скормить структуру типа "слон" в процедуру "поднять на воздушном шарике", то сейчас - фигушки. Есть класс слон, и у него метод "вымыть", а есть класс "мышь" и у него метод "поднять на воздушном шарике".
Что есть гигантский скачок. Альтернатива, очевидно - возврат к записям и процедурам - либо освоение проблемно-ориентированного, функционального и других подходов.

Гость

6 - 26.05.2012 - 23:40

>Есть класс слон, и у него метод "вымыть", а есть класс "мышь" и у него метод "поднять на воздушном шарике".

Ага, канонический пример: есть "Кот" который наследуется от "Млекопитающее" и есть "Гусь" который наследуется от "Птица" (у которого есть метод "летать"). Теперь внимание вопрос: от кого наследуем зверька "Летучая мыша"? (который умеет летать, но обязательно должен быть млекопетающим?)

Вот тут ООП и сливает.

Гость

7 - 27.05.2012 - 00:24

открой в википедии «летучие мыши». Там указано будит, класс млекопитающие, отряд, подотряд, вид. А не гибрид гуся со слоном.

Гость

8 - 27.05.2012 - 02:24

http://habrahabr.ru/post/143620/

Гость

9 - 27.05.2012 - 08:49

6-wayerr > Метод "летать" должен быть не у классов с предком "животное", а у класса "крылья" с предком "способ перемещения". Таким образом, мы отделяем видовую принадлежность от способа движения и можем динамически при создании объекта задавать это. ЕМНИП, в "Gang of Four" это называется "стратегия класса". Тут даже можно летучего слона создать - только вызывать придется не Слон.Лететь, а Крылья(Слон.Движок).Лететь - ну, или обобщенно Слон.Движок.ОбщийАбстрактныйМетодДвижения.
Блин, чего это я? Здесь 50% населения владеет ООП лучше меня, и лектор из меня уже хреновый.

Гость

10 - 27.05.2012 - 08:56

8-TVV1 >
Внимательно читал, но не согласен почти ни с одним. Такое ощущение, что человек пытался сделать один крупный проект на ООП, запутался в классах и этим очень недоволен.
Паттерны не приводят к хорошей структурированности.
Порадовало. А автоматические тесты удлиняют разработку ПО - верно? Вместо одной программы с тестами можно сделать две без тестов.
Здравое зерно в статье есть, но написано,ИМХО, обиженным неудачником. Когда я понял, что на софте миллионером не стану, я же не начал кричать "Разработка - УГ!!!", а просто плавно пересаживаюсь на рекламу и аренду.

Гость

11 - 27.05.2012 - 12:22

9-NTFS_ > Метод "летать" должен быть не у классов с предком "животное", а у класса "крылья" с предком "способ перемещения".

у нас может появиться "летучая рыба" (обувщик найдет в википедии образец) , у нее тоже есть способность "летать" но она не может ходить, т.е. набор способов передвижения разный 8). В итоге у вас будет в базовом классе десяток полей на все способы передвижения, пока не появится корова на реактивной тяге для которой в базовый класс придется еще добавлять поле.

Гость

12 - 27.05.2012 - 12:29

8-TVV1 >

после фразы "Бизнес компоненты нельзя использовать повторно" можно не читать.

А еще он капитан очевидность, который не осилил прочитать вышеупомянутую книгу четырех:

Например, нелепо просить объект отрендерить себя в HTML. Знание о рендеринге HTML в этом случае размазывается по проекту и небольшое изменение в коде рендеринга влечёт за собой изменение множества классов. Правильнее будет передать объект в отдельный комонент рендеринга HTML. И этот компонент прежде всего извлечёт все интересующие его значения из объекта.

Только непонятно как вышеуказанное противорчеит ООП, да и каноническому паттерну MVC?

короче позор хабру

Гость

13 - 27.05.2012 - 13:53

Если честно, когда-то изучал паттерн "фабрика объектов", вот его ни для одной своей задачи не смог придумать, куда воткнуть, но твёрдо решил, что он подходит для хранения объектов видов животных. :)

Гость

14 - 27.05.2012 - 15:25

11-wayerr >
десяток полей на все способы передвижения
Можно использовать коллекцию способов передвижения. Тогда, из нее можно выбирать тот, который нужен. Например, скормить класс "вода" - и коллекция выдаст либо "лететь", либо "плыть", но никак не "идти" или "ползать".
Эпический вин концепции ООП - возможность дробить систему на маленькие частично независимые классы, каждый из которых делает только свое дело. А вот для грамотной связи этих классов нужно и паттерны изучать, и Фаулера читать - чего автор поста на хабре, ИМХО, и не осилил.

Гость

15 - 27.05.2012 - 15:25

Судя по всему, он даже не в курсе про "мост иерархий" :-)

Гость

16 - 27.05.2012 - 15:56

14-NTFS_ > Можно использовать коллекцию способов передвижения. Тогда, из нее можно выбирать тот, который нужен. Например, скормить класс "вода" - и коллекция выдаст либо "лететь", либо "плыть", но никак не "идти" или "ползать".

Короче получится pattern matching своими руками 8)

14-NTFS_ >Эпический вин концепции ООП - возможность дробить систему на маленькие частично независимые классы, каждый из которых делает только свое дело.

вырожденный случай которого процедурное программирования, потому что снижая связанность придется уйти от наследования (как в обсуждаемом примере с методом передвижения) в итоге придем к анемичной (по выражению фаулера) модели объектов.

Вот НМВ более грамотное (чем на хабре) размышление на сию тему http://www.gotdotnet.ru/blogs/bezzus/1212/

Гость

17 - 27.05.2012 - 17:13

> В чистом виде - когда сначала прописывают все классы,
> а потом уже алгоритмы. Часто бывает, что в классе по
> два метода.

Просто любопытно, где вы такой ереси набрались?

Гость

18 - 27.05.2012 - 17:59

17-archimag > Почему сразу ересь? Вы что, никогда не рисовали UML до начала кодирования? Это способ, имеющий право на существование.

Гость

19 - 27.05.2012 - 18:07

> Это способ, имеющий право на существование

Только не надо называть его "ООП в чистом виде".

Гость

20 - 27.05.2012 - 21:37

Ни разу не видел чела с UML до шкодинга. Может я мало видел?
...
А вот всепоглощающее наследование в Python мне показалось вполне оопсным и совсем не оопасным. При этом задумываться о стиле шкодинга особо и не надо.

Гость

21 - 27.05.2012 - 22:03

20-economist > Ни разу не видел чела с UML до шкодинга. Может я мало видел?

да, я некоторые задачи прорисовываю в uml, на этом этапе можно избежать многих неприятных косяков которые вылеут позже.

20-economist > А вот всепоглощающее наследование в Python мне показалось вполне оопсным и совсем не оопасным. При этом задумываться о стиле шкодинга особо и не надо.

Оно вообще ненадо задумываться если речь идет о "быстрой" разработке, когда написал, сдал и забыл.

Гость

22 - 29.05.2012 - 08:51

Честно говоря, не понимаю, как некоторым может не нравиться ООП. Бывает некрасиво, когда ООП притягивают буквально "за уши", типа static класса с public процедурами. Ведь есть модули и нэймспейсы. А класс нужен только тогда, когда планируется создавать несколько экземпляров.
Кстати, в vb.net, в отличие от шарпа, обычные модули оставили.

Sserj

23 - 30.05.2012 - 15:05

(6) Вообще то есть еще такое понятие как интерфейсы, ну или абстрактные для c++ так что то что не укладывается в строгую иерархию можно переносить туда.

Гость

24 - 30.05.2012 - 20:24

23-Sserj >

интерфейсы не наследуют реализацию, абстрактные классы для этого также плохо подходят ибо при множественном наследовании реализаций - возникают неприятные последствия.

Гость

25 - 31.05.2012 - 11:39

"Если не выходить за границу «объектно-ориентированных» методов, чтобы остаться в рамках «хорошего программирования и проектирования», то в итоге обязательно получается нечто, что является в основном бессмысленным."
(с) Бьерн Страуструп.

Гость

26 - 14.01.2013 - 00:57

Чистое ООП - SmallTalk
Грязное ООП - C++

Гость

27 - 20.01.2013 - 13:44

Можно я скажу? Не нужно быть упертым [*****] в этих вещах. Это золотое правило, читая которое Бьярн просто ржет, аки конь.

Гость

28 - 03.02.2013 - 22:27

Цитата:

Сообщение от wayerr

Вот тут ООП и сливает.

А множественное наследование не катит?

Гость

29 - 04.02.2013 - 23:58

Процитирую себя постом выше:

>при множественном наследовании реализаций - возникают неприятные последствия.

что является "неприятными последствиями" можно узнать как в статьях почем у жаве нет этого наследования так и в книгах по c++ где рассказывают что делать если у вас есть два родительских класса с методами одинаковой сигнатуры

Гость

30 - 05.02.2013 - 08:02

Аффтор, неа))
Так и не удалось поиспользовать полезно никогда. Его имеет смысл применять, когда делаешь что-то мега-большое(например компилируемый классификатор птиц и животных, как верно подметил wayerr), иначе это приводит к реализации кучи методов(даже фиктивной) для совместимости классов, и иногда к наличию лишних пропертисов и internal-переменных, что в итоге влияет на потребление и размеры выходного файла.
Когда-то давным давно применял в одной игруле(танки), где объект Tank был наследован от BaseObject, второй кроме координат не обладал ничем полезным. До сих пор когда вспоминаю, не пойму, а нафига оно было нужно? )))

Гость

31 - 05.02.2013 - 22:52

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

Гость

32 - 06.02.2013 - 09:55

>иначе это приводит к реализации кучи методов(даже фиктивной) для совместимости классов, и иногда к наличию лишних пропертисов и internal-переменных

это все из-за убогости с++ и прочих популярных языков якобы "реализующих ООП", ну и особенности реализации как в случае с координатами в базовом объекте.

Гость

33 - 06.02.2013 - 11:52

32-wayerr >
это все из-за убогости с++
На ваш вкус - какие языки реализуют ООП "неубого"?

Гость

34 - 06.02.2013 - 16:14

Цитата:

Сообщение от Том

что является "неприятными последствиями" можно узнать как в статьях почем у жаве нет этого наследования так и в книгах по c++ где рассказывают что делать если у вас есть два родительских класса с методами одинаковой сигнатуры

Неужели всё так хреново? :)
Кстати, а где у нас методы с одинаковой сигнатурой?

Гость

35 - 06.02.2013 - 18:57

>На ваш вкус - какие языки реализуют ООП "неубого"?

пока из статически типизированных таких не нашел, серьезно

Гость

36 - 06.02.2013 - 19:27

35-wayerr >
А все-таки, "наиболее близки", на ваш взгляд?

Гость

37 - 07.02.2013 - 00:31

да никакие, вы только не туда копаете дело не в том как они "реализуют ООП", а в убогости самих языков. В техже плюсах у тебя есть и виртуальные классы и наследование всего, что движется (чем народ и пользуется) и на шаблонах там можно такого "нагородить" что тошно, а вот reflection (RTTI) нормальной нет (кое что есть, но какие там затейливости!),

а ведь получить тип объекта, и дернуть произвольный метод - это никак не связанно с ООП, зато позволяет как лепить фабрики (и кучу всего другого) так и просто дизайн делать вида (пример спорный, и именно так нигде не видел):

void addAll(List list, T ... values) **
if(list instanceof MiltiplyOpsList) **
((MiltiplyOpsList)list).addAll(values);
** else **
... дефолтная реализация с list.add(value)
**
**

Гость

38 - 07.02.2013 - 08:20

37-wayerr > Если в методе addAll нужно передавать неизвестно кому (класс List), неизвестно что (класс T), то нужно либо пересмотреть архитектуру, либо сделать два базовых класса ListAbstract и ParamAbstract, и перегружать виртуальный метод ListAbstact.Add(Param:TParamAbstract). И все, не нужно динамическое преобразование.
В чистом виде, я вообще считаю конструкцию вида TNeededClass(Obj) опасной. Потому что НИКТО не знает, что же на самом деле находится в переменной Obj.

Насчет RTTI - не знаю, у меня в проекте еще на пятом Delphi был код:

var p:Pointer ;
proc:TFuncForFRVar ;
begin
p:=Self.MethodAddress(ParName) ;
if Assigned(p) then begin
TMethod(proc).Code:=p ;
TMethod(proc).Data:=Self ;
ParValue:=proc() ;
end ;

Если это не "дернуть произвольный метод", то что?
А во всяких C#, ЕМНИП, это даже без костылей делается - на уровне фреймворка.

Гость

39 - 07.02.2013 - 21:18

38-NTFS_ >либо сделать два базовых класса

вот с этого момента вы городите над собой курган из недостатков ООП, ибо сторонние пользователи метода не должны ничего реализовывать (класс или интерфейсы) для него 8)

>ListAbstract

List итак интерфейс

>перегружать виртуальный метод ListAbstact.Add(Param:TParamAbstract)

в итоге у вас "интерфейс" списка будет содержать 25 методов (это число из реального примера), т.е. любой человек который будет реализовывать этот интерфейс столкнется с необходимостью кодить 20 ненужных методов, это ли не Праздник ООП?

>пятом Delphi
>Если это не "дернуть произвольный метод", то что?

наверное это не плюсы, не находите? Просто на каждый косяк ЯП можно найти другой ЯП где этого косяка нету, вот вы нашли дельфи, причем не дельфи, а имитиацию синтаксиса objectpascal на платформе .net, для тех кто не осилил C#, хехе

ООП - кто пользуется?

Интернет-форум Краснодарского края и Краснодараг. Краснодар, Краснодарский край 2022г.

Интернет-форум Краснодарского края и Краснодара
г. Краснодар, Краснодарский край 2022г.