OO или процедурный

Это зависит от того, что вы имеете в виду под «является объектом». Если вы хотите все, что не является примитивом , то есть вещи, на которые вы можете устанавливать новые свойства, это должно помочь:

function isAnyObject(value) {
    return value != null && (typeof value === 'object' || typeof value === 'function');
}

Это исключает примитивы (простые числа / NaN / Infinity, простые строки, символы, true / false, undefined и null), но должны возвращать true для всего остального (включая объекты Number, Boolean и String) , Обратите внимание, что JS не определяет, какие «хостовые» объекты, такие как window или console, должны возвращаться при использовании с typeof, поэтому их трудно покрыть такой проверкой.

Если вы хотите узнать, является ли что-то «простым» объектом, то есть оно было создано как литерал {} или с помощью Object.create(null), вы можете сделать это:

function isPlainObject(value) {
    if (Object.prototype.toString.call(value) !== '[object Object]') {
        return false;
    } else {
        var prototype = Object.getPrototypeOf(value);
        return prototype === null || prototype === Object.prototype;
    }
}

Редактировать 2018 : поскольку Symbol.toStringTag теперь позволяет настраивать вывод Object.prototype.toString.call(...), приведенная выше функция isPlainObject может возвращать false в некоторых случаях, даже когда объект начал свою жизнь как литерал , Можно утверждать, что по соглашению объект с пользовательским строковым тегом больше не является простым объектом, но это еще больше запутало определение того, что такое простой объект даже в Javascript.

5
задан Argalatyr 18 July 2009 в 16:08
поделиться

7 ответов

Ну, OO может быть излишним, но это отличная практика. Любая кодовая обезьяна может написать процедурный код. Это путь наименьшего сопротивления в каждом случае, поэтому большинство людей используют его для одноразовых приложений, которые мало что делают. Однако, если вы пишете, чтобы получить опыт работы с объектно-ориентированной архитектурой, лучше всего думать об этом именно так. Вы можете начать с разработки объекта, который управляет финансовой транзакцией, тогда вам также понадобится способ взаимодействия с БД. Возможно, вы могли бы написать уровень БД, где вы абстрагируете вызовы базы данных от объекта транзакции, используя структуру Entity, где вы могли бы изучать LINQ (или любой другой эквивалент JAVA). Все это при условии, что вы делаете это для развлечения и практики.

1
ответ дан 14 December 2019 в 13:43
поделиться

I'd suggest OO - it's not harder than procedural programming, actually easier to maintain with the right tool. Delphi would be my choice - great DB programming support, visual designer, strongly-typed, plenty of components available. There are many great applications that are written in Delphi. Often underestimated, there are many reasons it's got a loyal following.

Now I'll duck as the Delphi-haters load up with tomatoes.

5
ответ дан 14 December 2019 в 13:43
поделиться

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

0
ответ дан 14 December 2019 в 13:43
поделиться

Я бы выбрал Python: без компиляции и с динамической типизацией (вы также можете использовать строгую типизацию, если хотите). Кроме того, у него огромное количество поклонников в сообществе разработчиков ПО с открытым исходным кодом, что означает отличную поддержку, инструменты и бесплатную документацию.

Что касается объектно-ориентированного и процедурного программирования - все эти языки, которые вы упомянули, могут быть написаны в процедурном стиле - - то есть один большой класс / метод, который делает все - но вскоре вы обнаружите, что захотите следовать принципам DRY (не повторяйтесь) и начните с некоторых частных методов, которые хорошо справляются с одной конкретной задачей. С этого момента вы захотите сгруппировать похожие вещи в отдельные классы, а затем оттуда вы захотите абстрагироваться от этих классов ... видите, куда я иду?

0
ответ дан 14 December 2019 в 13:43
поделиться

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

0
ответ дан 14 December 2019 в 13:43
поделиться

In my opinion you should concentrate less on the OO versus procedural thing. If you have the possibility to go procedural in the beginning, then go procedural. It's the easiest thing you can do to get you started. The OO thing, on the other hand, may just as well qualify as YAGNI (You Ain't Gonna Need It).

What you should do though, is to write tests, unit tests and then integration tests. And you should strive to write tests first. This way, even if you begin with a procedural application you may later on refactor it into a full-fledged OO application. But, only if you need objects. These tests will be you're safety net when moving around code in your application.

Trying to think your applications into object from the beginning may lead you to an point where you're stuck with your class hierarchies and architecture.

I'm not a genius, so I may be wrong, but in my experience, starting with simple functions and then thinking about grouping them into objects or modules is better than starting by saying: OK, I'll have this object that interacts with this object, which is implementing pattern X, so this way I'll decouple interface Y from implementation Z. Later on, you may observe that your domain model is weak. Take an evolutionary design path and start with small building blocks.

0
ответ дан 14 December 2019 в 13:43
поделиться

Если вам нужно быстрое приложение, которое можно расширить, ознакомьтесь с Динамическими данными .

0
ответ дан 14 December 2019 в 13:43
поделиться
Другие вопросы по тегам:

Похожие вопросы: