Семинар разработчиков №2

[GrAndSE]

мне бы была интересна "ООП vs. процедурное программирование".

+1
Как раз тот момент, который часто пропускается, причем даже в серьезной литературе.
Привести доводы за и против, расказать некотоыре самые выдающиеся "фишки" и лаги. А на основе этого сделать выводы - а где лучше это испльзовать.

 

[alfim]

+1, сегодня со знакомым завели разговор на эту тему, очень интересно на самом деле. Все еще есть языки, где ООП вообще нету (1С, например) -- как быть в таких случаях?

 

[OSA]

а ведь есть еще и функциональное программироние ... его со счетов тоже не надо сбрасывать

 

[nnick]

мне бы была интересна "ООП vs. процедурное программирование".

a) -100

Нефиг. Вот сравнительно недавний

You must be registered for see links

b) "баян нах" - ООП, ИМХО, не более чем удобные языковые конструкции для принципов озвученных 35 лет назад.

цитирую по попавшей под руку книге "Software Architecure in Practice" 2nd ed by Len Bass, Paul Clements, Rick Kazman.

Дэвид Парнас:
* Принцип конструирования, описывающий разбиение системы на элементы с целью удобства сопровождения и обеспечения повторного использования. Сложно найти более фундаментальный принцип построения архитектуры, нежели этот, названный Парнасовым принципом информационной закрытости [Parnas 72]
* Принцип обращения к элементу исключительно через его интерфейс. Это вообще концептуальная основа всего объектного проектирования [Parnas 72]
* Наблюдение, согласно которому любая программная среда состоит из множества отдельных структур, сопровождающееся предостережением о недопустимости их смешения [Parnas 74]
* Введение структуры использования - принципа управления связями между элементами с целью повышения расширяемости системы, обеспечения оперативного и несложного получения подмножеств [Parnas 79]
* Принцип выявления и обработки ошибок (теперь их называют исключениями) в компонентных системах, ставший в большинстве современных языков программирования основополагающим [Parnas 79]
* Тезисы о том, что (1) любую программу следует рассматривать как члена семейства программ, (2) общность таких членов можно использовать в своих интересах, и (3) те проектные решения, которые легче всего пересмотреть, необходимо реализовывать в последнюю очередь. Первичное структурирование программы - один из этапов создания архитектуры - должно предусматривать принятие начальных, распространяющихся на всё семейство, проектных решений [Parnas 76]
* Признание воздействия структуры системы на атрибуты её качества ( в частности, на надёжность) [Parnas 76]
* Интерфейс - ряд допущений об элементе, которые мы можем принять с достаточной степенью уверенности и которые варьируются в зависимости от контекста применения этого элемента [Parnas 71]

[Parnas 71] Parnas D. "Information Distribution Aspects of Design Methodology", Proceedings of the 1971 IFIP Congress
[Parnas 72] Parnas D. "On the Criteria of Decomposing Systems into Modules", CACM 15(12), 1972
[Parnas 74] Parnas D. "On a `Buzzword': Hierarchical structure@, Proceedings of the 1974 IFIP Congress
[Parnas 76] Parnas D. "On the Design and Development of Program Families", IEEE Transactions on Software Egnineering SE-2(1),1976
[Parnas 79] Parnas D. "Designing Software for Ease of Extension and Contraction", IEEE Transactions on Software Engineering, SE-5(2),1979

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

О! Кто возьмётся за доклад "WTF is Software Engineering and why does it matter?"

P.S.Ишшо: Фредерик П. Брукс, "Мифический человеко-месяц" двадцать лет спустя:

"Парнас был прав, а я - нет в отношении сокрытия информации
В главе 7 я противопоставляю две точки зрения на то, в какой мере каждый участник команды может иметь право или поощряться к знанию проектов и текстов программ, созданных коллегами....Этот взгляд резко противоречит мнению Дэвида Парнаса о том, что программные модули должны быть инкапсулированы, с хорошо определенными интерфейсами, а внутренность таких модулей должна быть частной собственностью программиста, невидимой снаружи. Программисты эффективнее всего работают, будучи ограждены от внутренностей чужих модулей..... Сегодня я убежден, что ограничение информации, часто осуществляемое теперь методами объектного программирования, является единственным способом поднять уровень программных разработок.
Используя другие методы, можно действительно попасть в беду. Согласно методике Миллза программисты могут получить подробности семантики интерфейсов, с которыми они работают, узнав, что находится "по ту сторону". Укрывание этой семантики может быть причиной системных ошибок. С другой стороны, методика Парнаса способствует устойчивости при внесении изменений и больше подходит к стратегии проектирования, предполагающей изменения в будущем."

 

[artvolk]

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

От общего, к частному:

You must be registered for see links

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

You must be registered for see links

In software engineering and project management, a methodology is a codified set of practices (sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatably carried out to produce software.

You must be registered for see links

A programming paradigm is a fundamental style of programming regarding how
problems solutions are to be formulated in a programming language. (Compare
with a methodology, which is a style of solving specific software
engineering problems).
(тут ООП, процедурное и функциональное, см. список, где кроме упомянутых ещё с десяток )

You must be registered for see links

In software engineering (or computer science), a design pattern is a general repeatable solution to a commonly occurring problem in software design

Я это к чему, раз programming paradigm — средство решения задач в software engineering, значит сравнивать сами парадигмы нет смысла — это как молоток и отвёртка (хотя и тем и другим можно колоть орехи, только разными способами ). Для доклада можно уточнить в каких задачах и при каких условиях что лучше выбрать, но я бы не взялся, anybody?

 

[alfim]

Собственно, как раз и предлагается обсудить -- когда и что лучше применять. Я все еще считаю, что будет полезно и интересно. Только каски надо взять . Дабы не поубивали друг-друга.

 

[artvolk]

Собственно, как раз и предлагается обсудить -- когда и что лучше применять. Я все еще считаю, что будет полезно и интересно. Только каски надо взять . Дабы не поубивали друг-друга.

Добавил эту тему в опрос. Дре, спасибо!

 

[garrik]

Интересно послушать про оплату и стим. работников, вёрстку, СЕО. Хотелось бы услышать про ньюансы работы с заказчиками.
И классно бы устроить балаган и мордобой по поводу ООП вс олл