How to get the controller in which it is wrapped in a directive?

Question

Angular

At first I started asking a more general question, but then I realized that it was caused by ignorance of how to get the controller in which the directive is wrapped.

<div ng-controller="SomeControeller as someControeller">
  <some ng-click="someControeller.run()">####</some>
</div>

function SomeController(){
  this.run = function(){
    console.log('SomeController');
  }
}

function someDirective(){
  return {
    controller: 'SomeControeller',
    link: function($scope, iElm, iAttrs, controller) {
      console.log(controller);
      controller.run = function(){
        console.log('directive');
      }
    }
  };
}

var app = angular.module('app', []);
app.controller('SomeControeller', [SomeController]);
app.directive('some', [someDirective]);
angular.bootstrap(document, ['app']);

Just now I found out that the controller in the link is just another instance of the controller,
and not the one in which the directive is wrapped. I couldn't google it myself because I don't know what to ask.
Therefore, it remains only to ask you - how to get the desired controller, or if it does not need to be received according to ideology, then why?
UPD: 0.0.0
And this question arose when I tried to call the click event handler in the directive. It turned out that in order to call the handler, it must be either in the scope of the controller, or in the scope. I immediately discarded the second option, because if you hang handlers on an osprey, then the controller was given in general, and even in the directive .. So I was left with the option in which the controller contains handlers, but I don’t understand how to adapt it.

Answer 1

or if it is not necessary to receive it according to ideology, then why?

because it makes the directive dependent on the context in which it is used. Follow the logic
1) the operation of the directive requires that it be wrapped in SomeController one level higher.
2) the directive becomes part of SomeController, or to be precise, of the piece of view controlled by SomeController.
3) there is no point in the directive, since we can no longer reuse it elsewhere
4) if the directive depends on the controller SomeController, why not take out from SomeController what the directive needs in its own controller?
something like this. All interaction with the directive must occur either through directive controllers (the directive's require parameter) or through attributes (isolated scope, bindToController in angular 1.4). And even more strange is the desire to replace the controller methods from link.
is shorter essence in misunderstanding of that that there is a directive as I understand. A directive is a self-sufficient unit (an independent small MVC application). For good, it can only depend on other directives, but it should not care where and how it is used. She's doing her little piece of logic. Some directives act as facades, encapsulating in themselves and making it easier to work with multiple directives.
Further, regarding handlers, a vivid example is the ng-click directive. This directive looks something like this:

function myNgClick() {
    return {
        restrict: 'A',
        scope: {
            callback: "&myNgClick"
        },
        link: function (scope, el) {
            el.bind('click', function (e) {
                scope.$apply(function () {
                     scope.callback({$event: e});
                });
            });
        }
    }
}

As we can see in this example, we have a directive whose main job is to call something when the element is clicked. And that's all. Through this directive, we say we can pull the controller method of another directive. This shows the power of angular, we can decompose interface elements as deeply as we want. make extremely isolated, small and simple directives that are very easy to cover with tests and easy to use.
The link directive is ONLY needed to link the DOM and the logic. That is, in 99% of cases, the directive will contain only a link or only a controller. Both are already dumb, in this case it is better to take out the logic that you want to shove into the link into a separate directive.
the controller (we're going to deviate a little from MVC now just for the sake of simplifying everything) implements all the logic (or delegates to the models). All logic not related to the DOM, for example, related to data processing, should be placed in the controller.
A few words about ng-controller. This is also a directive that allows you to attach some kind of controller to an element. This thing is essentially (like ng-include in principle) only needed to speed up development and simplify. In general, an angular application should be perceived as an HMVC application consisting exclusively of directive trees. The first step towards web-components (in fact, the angular directives served as a good breath of inspiration).
Something like this.