Inheritance w/ Angular's 'Controller As' vs. $scope - angularjs

Question

tl:dr;
I want to consider the 'controller as' approach to simplify my inheritance process however I see some pitfalls around dependency injection and use in directives.
preface
I've been working on a pretty big Angular application for the last 6 months. I come from a more OOP language background but feel I've adapted fairly well to some of the quirkiness of javaScript and Angular.
With an application of this complexity, I think it necessitates great architectural solutions. I've elected to have baseController classes that UI controllers can inherit from using the current approach below.
current approach
All the current UI views/components/etc. are utilizing the $scope as the view model approach, aka. the classic approach. I achieved the controller inheritance like so:
NxBaseUiController
var NxBaseUiController = function($scope)
{
$scope.isLoggedIn = function(){}
$scope.doSomethingElse = function(){}
}
Here's a subclass base controller and it's inheritance
NxBaseListUiController
var NxBaseListUiController = function($scope)
{
var NxBaseUiController = require( './NxBaseUiController' )
NxBaseUiController.apply( this, arguments )
NxBaseListUiController .prototype = Object.create( NxBaseUiController.prototype );
$scope.query = require( './QueryModel' ).new()
}
What's crazy about this approach is that I'm having to maintain 2 series of inheritance all while keeping in mind of the existing NG scope inheritance that takes place in the view hierarchy. You can see this in the following UML diagram:
src - http://i.imgur.com/LNBhiVA.png
This all works so far, but moving onto a new section of the app, I want to start looking at the 'Controller As' syntax to see if there can be any simplification of the above approach.
questions
In all the examples I've seen of the 'controller as' approach, any methods attached are not defined on the prototype but rather the actual constructor like so:
function SomeController($scope)
{
this.foo = function(){};
}
Is there a reason why you wouldn't want to define the controller methods on the prototype?
The only reason I see attaching to the prototype as being problematic is you lose reference to your injected dependencies.
I realize I am coming at this from a very OO approach, however w/ an application of this size, being able to draw upon development patterns like inheritance seems necessary to solve code duplication.
Am I approaching this completely backwards? Are there any proven methods to achieving some semblance of inheritance in the controllers that doesn't require some wonky hack to work w/ the $scope?

Answer 1

There is no reason you can't use the prototype so long as you are OK with losing the ability to have actual private data vs having conventionally private data.
Let me explain with code:
function MyClass($http){
var privateData = 123,
$this = this;
$this.getAnswer = function(){
return privateData;
};
}
MyClass.$inject = ['$http'];
In that example you can't actually change privateData once the class has been instantiated.
function MyClass($http){
this._privateData = 123;
this.$http = $http;
}
MyClass.$inject = ['$http'];
MyClass.prototype = {
getAnswer: function(){
return this._privateData;
},
callHome: function(){
var _this = this;
_this.$http.get('/api/stuff')
.success(function(data){
_this.stuff = data;
});
}
};
In that example I am simply using a convention of prefixing my properties with an underscore (_) to signal that they should be treated as private.
Unless you are building a re-usable library however, this might not be a big deal.
Mind you some of this get's much simpler with ES6, so I would look into something like 6to5 or TypeScript if I were you. It might gel a little better with your OO background to write code like this:
//100% valid ES6
class MyClass extends BaseClass {
constructor(something){
super(something, 'foo');
}
someMethod(){
return this.foo;
}
}