SOLID принципы

@ht1515 · Регистрация: 31.01.2010

Студворк — интернет-сервис помощи студентам

всего 5 принципов:
1) srp - класс должен описывать только те характеристики, которые на объект из предметной области возложены. То есть либо кот, либо пес, котопес быть не может.
2) ocp - Писать надо классы так, чтобы их можно было легко расширить, но не изменять
3) Лисков - ???
4) делайте много маленьких интерфейсов, один дольшой интерфейс это плохо. Так как рефакторинг усложняется...
5) Инверсия зависимостей. Типо композицию поменяйте на агрегацию

Я не понимаю принцип Лисков. Можете объяснить популярно?

@Shamil1 · 31.01.2017, 22:07

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

это не моя логика.

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

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

думайте лучше.

Ваша логика настолько непредсказуема, что "думать лучше" тут не поможет.

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

заодно подумайте,
как работает компилятор какацкеля,

Вы полагаете, что, хорошо подумав, можно догадаться, что код на Хаскеле транслируется в код на Си? Или всё-таки лучше взять и прочитать?

@Fulcrum_013 · 31.01.2017, 22:08

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

аха. наверное, именно поэтому, он на свалке истории,

Он до сих пор практически безраздельно рулит на суперкомпутерах. Интел кстати компилятор фортрана двигает поперед компилятора С++. Это уже правда совсем не тот фортран который был в 60-х даже не тот который был в 90-х.

@asmquest · 31.01.2017, 22:08

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

и какое отношение вообще имеет парадигма языка
к технологиями компилятора

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

@Fulcrum_013 · 31.01.2017, 22:12

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

Вы полагаете, что, хорошо подумав, можно догадаться, что код на Хаскеле транслируется в код на Си? Или всё-таки лучше взять и прочитать?

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

Добавлено через 1 минуту

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

Никакой проверки типов на стадии компиляции там тоже быть не может, потому что типы можно порождать на этапе исполнения

Типы можно порождать только на этапе проектирования. А порождение типов на этапе выполнения это уже не ООП а неизвестно что.

@Shamil1 · 31.01.2017, 22:16

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

настоящее ООП подразумевает

Где можно почитать про настоящее ООП?

@asmquest · 31.01.2017, 22:20

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

Типы можно порождать только на этапе проектирования. А порождение типов на этапе выполнения это уже не ООП а неизвестно что.

расскажите это авторам ООП-парадигмы, или, к примеру, директору по исследованиям Google и члену Совета Американской ассоциации искусственного интеллекта Питеру Норвигу, который выпустил вот эту брошюру

http://norvig.com/design-patte... tterns.pdf

Добавлено через 4 минуты

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

Где можно почитать про настоящее ООП?

http://wiki.c2.com/?AlanKaysDe... ctOriented

@Fulcrum_013 · 31.01.2017, 22:27

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

члену Совета Американской ассоциации искусственного интеллекта Питеру Норвигу,

Искустфенный интеллект это вообще антинаучная фантастика. А реальность это адаптивные автоматы.

Добавлено через 2 минуты

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

расскажите это авторам ООП-парадигмы,

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

@asmquest · 31.01.2017, 22:31

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

Искустфенный интеллект это вообще антинаучная фантастика. А реальность это адаптивные автоматы.

Неважно, главное таких как страуструп туда на пушечный выстрел не подпускают.

@hoggy · 31.01.2017, 22:31

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

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

именно так.
выросла из процедурной парадигмы.
является развитием идей процедурной парадигмы.

на сишке запросто эмулируется ооп.
конечно это не так удобно,
и всё приходится делать в ручную.
но в принципе - делают жеж.
сплошь и рядом.

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

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

ага. и вот эта вот последовательность машинных команд
уже не имеет ни малейшего отношения к фп.

ну или проэмулируйте фп на сишке, или на ассемблере.
а я посмотрю как это у вас получится.

ооп на сишке - ярко выраженная объектно ориентированная архитектура - без проблем.

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

Никакой проверки типов на стадии компиляции

вы бредите.

@asmquest · 31.01.2017, 22:38

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

на этапе проектирования

И причем тут проектирование непонятно. В огороде бузина. Проектирование ортогонально времени создания объектов

Добавлено через 4 минуты

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

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

не должен он ничего ни кому. был должен, да рассчитался.

@Fulcrum_013 · 31.01.2017, 22:42

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

Проектирование ортогонально времени создания объектов

Во время создания в рантайме создается то что было спроектировано в дезигн тайме и никак иначе.

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

не должен он ничего ни кому. был должен, да рассчитался.

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

@asmquest · 31.01.2017, 22:53

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

Во время создания в рантайме создается то что было спроектировано в дезигн тайме и никак иначе.

нет никакого дезигн тайма, есть время компиляции и исполнения

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

Тогда и единообразного управления созданными объектами не будет.

это какое то пустословие, ничем не обоснованное, фантазии.

@Fulcrum_013 · 31.01.2017, 23:06

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

нет никакого дезигн тайма,

Это 99% времени создания софта в которое программист пользует свой основной инструмент - моск.

@asmquest · 31.01.2017, 23:08

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

Это 99% времени создания софта в которое программист пользует свой основной инструмент - моск.

я уже сказал, что это ортогонально времени создания объектов

@Fulcrum_013 · 31.01.2017, 23:10

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

это какое то пустословие, ничем не обоснованное, фантазии.

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

@asmquest · 31.01.2017, 23:13

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

Какое пустословие? Единообразное управление возможно только при наличии единообразного интерфейса у управляемых объектов

я не понимаю какое это имеет отношение к делу. Кто вам мешает в динамике создавать единообразные интерфейсы?

@Fulcrum_013 · 01.02.2017, 00:17

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

приведите пример, я не понимаю какое это имеет отношение к делу.

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
class TGadget{
public:
    virtual void TurnOn()=0; 
    virtual void TurnOff()=0; 
};
class TLamp:public TGadget{
public:
 virtual void TurnOn(){//включили}; 
    virtual void TurnOff(){//выключили}; 
};
class TSuperComputer:public TGadget{
public:
 virtual void TurnOn(){//включили}; 
    virtual void TurnOff(){//выключили}; 
};
int main(){
    vector<TGadget*> Gadgets;
    Gadgets.push_back(new TLamp());
    Gadgets.push_back(new TSuperComputer());
    Gadgets.push_back(new TLamp());
    Gadgets.push_back(new TSuperComputer());
    Gadgets.push_back(new TLamp());
    Gadgets.push_back(new TSuperComputer());
    for (int i=0;i<Gadgets.size();i++) Gadgets[i]->TurnOn(); // включили все лампочки и контуперы
    for (int i=0;i<Gadgets.size();i++) Gadgets[i]->TurnOf(); // выключили все лампочки и контуперы
}

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

Добавлено через 13 минут

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

Кто вам мешает в динамике создавать единообразные интерфейсы?

Ну и что тогда можно сделать при динамическом конструировании типов того что нельзя сделать при статическом? Абсолютно ничего. При этом на соответствие спецификации интерфейса при динамическом конструировании типа тоже никто не проверит, а отлавливать ошибки в рантайме гораздо более трудоемкое занятие чем в компайлтайме.

Добавлено через 20 минут

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

Неважно, главное таких как страуструп туда на пушечный выстрел не подпускают.

Только реально работающие новости робототехники почему то связаны не со скриптами а с адаптивными автоматами реализованными на С++. Причина проста. Те кто С++ осилил занимаются реальной робототехникой. А те кто не осилил создают всякие ассоциации антинаучных мифов и пилят невесть какие скриптовые языки типа позволяющие невесть какую ахинею. Наверное самопрораммирование пытаются изобрести. Не понимают бедолаги что если машина таки научится осознавать и формализировать задачу то ей как бы и в машкоде перепрограммироваться не проблема.
Пример - типа научили роящихся роботов типа выбирать позицию чтобы типа выстроится в заданную фигуру. Запилили для этого супердупер скриптовый язык непонятного назначения с непонятно зачем добавленныыми синтаксическими конструкциями и кучу скриптомазни на оном новоявленном языке. Видел те же действия ботов в писанном на С++ в середине 90-ых первом варкрафте, Принцип простейший на сигналах занято/свободно/решил занять эту позицию. Кода экрана на 2. При этом ножками-ручками оные роящиеся роботы однозначно шевелят на плюсовом коде а никак не на скриптовом.

Добавлено через 22 минуты

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

я уже сказал, что это ортогонально времени создания объектов

НЕ может быть создано в рантайме то что не спроектировано в десигн тайме и не скомпилированно в компайл тайме.

@asmquest · 01.02.2017, 00:30

Fulcrum_013,
нихрена не понял, при чем тут вообще создание в рантайме, ну ладно

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Switchable := Object clone do(
   active := false
   turnOn := method(active = true)
   turnOff := method(active = false)
)
 
 
inRuntimeCreateTypes := method(
    Lobby Computer := Switchable clone   
    Lobby Lamp := Switchable clone
)
 
inRuntimeCreateObjects := method(
   Lobby lamps := list()
   Lobby computers := list()
   5 repeat ( lamps push(Lamp clone) )
   5 repeat ( computers push(Computer clone) )
)
 
turnOn := method(list, list foreach(turnOn))
turnOff := method(list, list foreach(turnOff))
checkPrint := method(list, list foreach(active print); "
" print)
 
#################################################
 
 
inRuntimeCreateTypes
inRuntimeCreateObjects
 
checkPrint(lamps)
checkPrint(computers)
 
turnOn(lamps)
turnOn(computers)
 
checkPrint(lamps)
checkPrint(computers)
 
turnOff(lamps)
turnOff(computers)
 
checkPrint(lamps)
checkPrint(computers)
 
 
#>>>>falsefalsefalsefalsefalse
#>>>>falsefalsefalsefalsefalse
#>>>>truetruetruetruetrue
#>>>>truetruetruetruetrue
#>>>>falsefalsefalsefalsefalse
#>>>>falsefalsefalsefalsefalse

Добавлено через 9 минут

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

новости робототехники

угу, в научном журнале "британские ученые разъясняют блондинкам за науку"

@Fulcrum_013 · 01.02.2017, 00:36

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

нихрена не понял,

А в один массив лампы и компутеры запихнуть никак? А потом одной командой все сразу включить/выключить никак?
Ну типа TurnOff(Switchable)? Полиморфизм где?

Добавлено через 3 минуты

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

угу, в научном журнале "британские ученые разъясняют блондинкам за науку"

То что подобные тыц новости могут и в журналах для блондинок быть, никак не отменяет того факта что оно во первых работает во вторых работает на адаптивных автоматах в ретьих реализовано на С++.

@asmquest · 01.02.2017, 00:37

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

А в один массив лампы и компутеры запихнуть никак? А потом одной командой все сразу включить/выключить никак?
Ну типа TurnOff(Switchable)?

можно

Новые блоги и статьи Все статьи Все блоги /
GitHub Copilot в JetBrains: модель по умолчанию, Fix и контроль MCP and_y87 12.10.2026 10 октября 2026 года GitHub обновил Copilot для JetBrains: добавил настройки стартовой модели, исправления из диагностики и управление автозапуском MCP. Поддержка IDE 2025. 1 прекращена — требуется. . .	GitHub Copilot в JetBrains: модель по умолчанию, Fix и контроль MCP and_y87 12.10.2026 10 октября 2026 года GitHub обновил Copilot для JetBrains: добавил настройки стартовой модели, исправления из диагностики и управление автозапуском MCP. Поддержка IDE 2025. 1 прекращена — требуется. . .	День 5 из 28: Codex подсказывает следующий запрос and_y87 12.10.2026 9 октября 2026 года OpenAI запустила бету Composer predictions — подсказок следующего сообщения в текущем диалоге Codex. Это помощь с формулировкой запроса, а не автоматическое продолжение задачи. . . .	Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .
ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .

@ht1515 шарпопочитатель 59 / 26 / 7 Регистрация: 31.01.2010 Сообщений: 1,035

	SOLID принципы 23.01.2017, 17:55. Показов 17648. Ответов 359 Метки нет (Все метки) всего 5 принципов: 1) srp - класс должен описывать только те характеристики, которые на объект из предметной области возложены. То есть либо кот, либо пес, котопес быть не может. 2) ocp - Писать надо классы так, чтобы их можно было легко расширить, но не изменять 3) Лисков - ??? 4) делайте много маленьких интерфейсов, один дольшой интерфейс это плохо. Так как рефакторинг усложняется... 5) Инверсия зависимостей. Типо композицию поменяйте на агрегацию Я не понимаю принцип Лисков. Можете объяснить популярно? 0