Является ли хорошей практикой в Javascript использование функций в качестве C # -подобных свойств для доступа к частным данным?
Хотя есть много хороших объяснений выше, я пропускаю практический способ разделения шаблонов на заголовок и тело. Моя главная задача - избегать перекомпиляции всех пользователей шаблонов, когда я меняю свое определение. Все экземпляры шаблонов в корпусе шаблона не являются жизнеспособным решением для меня, поскольку автор шаблона может не знать всех, если его использование и пользователь шаблона могут не иметь права его модифицировать. Я принял следующий подход, который также работает и для более старых компиляторов (gcc 4.3.4, aCC A.03.13).
Для каждого использования шаблона в его собственном файле заголовка (сгенерированном из модели UML) имеется typedef, , Его тело содержит экземпляр (который заканчивается в библиотеке, которая связана в конце). Каждый пользователь шаблона включает этот файл заголовка и использует typedef.
Схематический пример:
MyTemplate.h:
#ifndef MyTemplate_h
#define MyTemplate_h 1
template <class T>
class MyTemplate
{
public:
MyTemplate(const T& rt);
void dump();
T t;
};
#endif
MyTemplate.cpp:
#include "MyTemplate.h"
#include <iostream>
template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}
template <class T>
void MyTemplate<T>::dump()
{
cerr << t << endl;
}
MyInstantiatedTemplate.h:
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"
typedef MyTemplate< int > MyInstantiatedTemplate;
#endif
MyInstantiatedTemplate.cpp:
#include "MyTemplate.cpp"
template class MyTemplate< int >;
main.cpp:
#include "MyInstantiatedTemplate.h"
int main()
{
MyInstantiatedTemplate m(100);
m.dump();
return 0;
}
Таким образом, нужно будет перекомпилировать только экземпляры шаблонов, не всех пользователей шаблонов (и зависимостей).
2 ответа
Это хорошая идея для доступа к таким данным?
Я не вижу никакой выгоды, он просто добавляет много шаблонного.
Если позже вам понадобится какой-нибудь метод получения / установки, вы можете прозрачно добавить его, ничего не нарушая.
{ example: "test", } // can be turned into { get example() { /*..*/ }, set example(v) { /*...*/ }, }Насколько я вижу, то же самое относится и к C #:
string example // can be turned to string example { get { //... } }, поэтому я не уверен, о каких «лучших практиках» вы говорите.
... если вы что-то меняете в переменных a и b, вам не нужно менять весь код, который их использует.
Но ... если эти свойства изменяются таким образом, что это влияет на их функциональность, код, использующий его, тоже должен быть изменен, использование getters / setters, чтобы «заставить его все еще работать как-то», не долго срок решения.
Нет, вы не должны писать методы доступа в JavaScript. Вам они не нужны сейчас, они вам не понадобятся в будущем. Сохраняйте свой код простым.
class Obj {
constructor() {
this.a = 5
this.b = 9
}
}
делают код более гибким для будущих изменений.
JavaScript поддерживает свойства getter и setter. Метод доступа не должен быть методом, он работает с обычным синтаксисом свойств (как для доступа, так и для назначения). Если вы позже измените свои свойства данных на свойства доступа, код, использующий их, не нужно будет принимать.
class Obj { constructor() { this.a = 5 } get b() { return this.a + 4; } set b(val) { this.a = val - 4; } } const inst = new Obj; console.log(inst.a, inst.b); inst.b = 46; console.log(inst.a, inst.b);