2017-02-03 3 views
0

В основном я работал с 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(); 

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

+0

Я считаю, что этот вопрос лучше подходит для [SE] (http://softwareengineering.stackexchange.com/) веб-сайта – yeputons

+0

@yeputons при обращении к другим сайтам, часто полезно указать, что [перекрестная публикация неодобрительно] (http://meta.stackexchange.com/tags/cross-posting/info) – gnat

+0

Я думаю, что можно переместить вопросы? Но я не думаю, что у меня есть эта привилегия. –

ответ

1

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

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

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

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

+0

Мне рассказали об АОП старшим разработчиком, где я работал, а затем попросил не попробовать его вообще. Я как бы смотрю, как это будет расстраивать, когда результаты программы напрямую не определяются в коде, который вы смотрите. Говоря это, было бы справедливым сказать, что чем выше уровень абстракции, тем труднее читать чужой код? Похоже, существует компромисс между «эффективностью разработчика», «эффективностью обслуживания» и «скомпилированной эффективностью кода», или «затруднением в создании скомпилированного кода». Спасибо за ответ –

+0

@ZachSmith Программируемый программист также сказал бы, что вы не должны вообще заходить в ООП, потому что вам нужно реализовать больше кода, чтобы сделать то же самое. АОП подходит для конкретных случаев, тогда как ООП является более общим. Если правило выше - это абстракция, тем труднее прочитать код, то это просто потому, что эта более высокая концепция не очень хорошо реализована в языке, библиотеке или структуре. Просто взгляните на структуры, такие как PostSharp, и как вы можете делать много вещей за кулисами, оставляя код чище, чем тот, который вообще не будет использовать AOP. –

+0

@ZachSmith Кроме того, взгляните на некоторые из моих библиотек, https://github.com/mfidemraizer/trackerdog. Будет ли отслеживание изменений таким простым, если я не буду использовать AOP? : D См. Учебник [здесь] (http://matiasfidemraizer.com/trackerdog/html/52e40f26-3dfe-47e0-adf1-09233e98f42e.htm), и я считаю, что вы создадите собственное положительное мнение об АОП. –

Смежные вопросы