Logic regarding service classes

[rhyslbw]

Is the 'Iso' suffix on the service classes to designate a base class that a singleton is instansiated from, that happens to be available on both the client and server (isomorphic)?

import AccountServiceIso from './iso';
import {AccountHolderRepository} from '../../../domain/model/account-holder/account-holder-repository';

export default class AccountService extends AccountServiceIso {
  static getInstance() {
    if (!this.instance) {
      this.instance = new AccountService();
    }
    return this.instance;
  }
  getCurrentAccountHolder() {
    var user = Meteor.user();
    if (!user) {
      return AccountHolderRepository.getNullAccountHolder();
    }
    return AccountHolderRepository.find(user.accountHolderId);
  }
};

Given the client class has no behaviour, isn't this early optimisation?

[ghost]

Yeah, the Iso stands for isomorphic and AccountServiceIso class is the base class that has the functionality that is shared on server and client.

I also would rather use composition over inheritance for this now.