Разработаны ли языковые парадигмы, такие как ООП, с точки зрения исполнения или разработки?

В основном я работал с JavaScript, но сейчас работаю с C #. Мне пришло в голову, что при программировании и учете иерархии объектов в обоих случаях я действительно не знаю, как выполняется код.

При написании иерархий «классов» в JavaScript я обнаружил, что программисты Java были шокированы определением этих иерархий, внешних по отношению к определению конструктора. Например:

function SomeConstructor() {}
SomeConstructor.prototype.someMethod = function() {}
var someItem = new SomeConstructor()
someItem.someMethod()

Это сильно отличается от того, как строится традиционный язык ООП (по крайней мере, с моим менее чем 2-летним опытом), например, на C #:

public class SomeClass{
  public SomeClass() {}
  protected void SomeMethod() {}
}
SomeClass someItem = new SomeClass();
someItem.SomeMethod();

Вопрос: фокусируются ли языковые парадигмы, такие как ООП, на повышении эффективности выполнения кода, вывода разработчика (т. Е. Простоты использования) или на то и другое?


person Zach Smith    schedule 03.02.2017    source источник
comment
Я считаю, что этот вопрос лучше подходит для веб-сайта SE   -  person yeputons    schedule 03.02.2017
comment
@yeputons, ссылаясь на другие сайты, часто бывает полезно указать, что перекрестная публикация не одобряется   -  person gnat    schedule 03.02.2017
comment
Думаю, можно вопросы перенести? Но я не думаю, что у меня есть такая привилегия   -  person Zach Smith    schedule 03.02.2017


Ответы (1)


Вопрос: фокусируются ли языковые парадигмы, такие как ООП, на повышении эффективности выполнения кода, вывода разработчика (т. Е. Простоты использования) или на то и другое?

Я бы сказал, что объектно-ориентированное программирование (ООП), аспектно-ориентированное программирование (АОП) и другие парадигмы находятся на максимально возможном уровне.

Чем выше уровень, тем больше внимания уделяется производительности.

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

person Matías Fidemraizer    schedule 03.02.2017
comment
Старший разработчик, где я работал, рассказал мне об АОП, а затем попросил не пробовать его вообще. Я как бы вижу, как было бы неприятно, если бы результаты программы напрямую не определялись в коде, который вы просматриваете. При этом было бы справедливо сказать, что чем выше уровень абстракции, тем труднее читать чужой код? Похоже, существует компромисс между «эффективностью разработчика», «эффективностью обслуживания» и «эффективностью скомпилированного кода» - или «трудностью повышения эффективности скомпилированного кода». Спасибо за ответ - person Zach Smith; 07.02.2017
comment
@ZachSmith Программист, занимающийся только процедурными вопросами, также сказал бы, что вам вообще не следует переходить в ООП, потому что вам нужно реализовать больше кода, чтобы делать то же самое. АОП подходит для конкретных случаев, в то время как ООП является более общим. Если правилом более высокого уровня является абстракция, тем сложнее читать код, то это просто потому, что эта более высокая концепция плохо реализована в языке, библиотеке или фреймворке. Просто взгляните на такие фреймворки, как PostSharp, и на то, как вы можете делать множество вещей за кулисами, оставляя код более чистым, чем тот, который вообще не использует АОП. - person Matías Fidemraizer; 07.02.2017
comment
@ZachSmith Также взгляните на некоторые из моих библиотек, github.com/mfidemraizer/trackerdog. Было бы так легко отслеживать изменения, если бы я не использовал АОП? : D См. Руководство здесь, и я верю вам Сформирую собственное положительное мнение об АОП. - person Matías Fidemraizer; 07.02.2017