Нужны ли комментарии для наследуемых методов?

[SiZE]

class A {
 /**
  * That function do nothing
  * @return void
  */
 function foo(){
 }
}

class B extends A {
 /**
  * That function do nothing
  * @return void
  */
 function foo(){
 }
}

Задумался, а стоит ли дублировать комментарии? Мб есть какие-то случаи в каких стоит, а в каких не стоит? Для себя, для других, для phpDoc?

 

[Вурдалак]

Я вообще критически отношусь к подобному комментированию. Оно в общем-то нахрен не нужно (да, да, документация, да кому это нужно, лучше код пиши понятней). Обычно пишу только @return, когда IDE совсем тупит (привет, PhpStorm). Да и то не всегда помогает.

А вообще для наследования описания есть http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.inlineinheritdoc.pkg.html.

 

[флоппик]

Если уж подходить совсем правильно с точки зрения ООП — наружное поведение метода не должно меняться в наследниках.

 

[SiZE]

Если уж подходить совсем правильно с точки зрения ООП — наружное поведение метода не должно меняться в наследниках.

Согласен.

Я обычно пишу комментарии только к новым методам, а к тем, которые наследованы пропускаю.. Получается половина методов класса имеют комментарии, половина нет. Стало интересно кто как делает? Иногда бывает полезно видеть комментарий к методу, но дублировать комментарии очень не нравится, т.к. если поменять его у родителя, придется менять и для наследников..

 

[keltanas]

Мне так комментарии позволяют визуально разделять различные методы. Даже если там будет только @return. Скажу даже больше: методы без комментариев у меня сливаются в один (( привычка...

 

[Adelf]

keltanas
а я в шторме включил галку - отделять методы линиями. и еще есть линия вертикальная - на 80 или 120 позиции. красиво получается.

По теме: копировать - бред. Но вот мне в C# приходится. StyleCop ругается: типа нет коммента - давай досвидания.

 

[Absinthe]

Adelf там какого-нибудь {@inheritdoc} разве нет? Либо настроек этого самого стайлкопа.

 

[Тугай]

Нет и только нет! Хватит перкладыааь на програмистов проектирование и документирование. Все эти коменты и рефакторинг - тупая эксусплуатация. Если потрачено время на ТЗ и постановку звдачи, то в таком говне нет потребности. Код должен и так читаться.
Если это не говно код, то я не знаю что им еще назвать.

 

[Вурдалак]

рефакторинг - тупая эксусплуатация

Щито?

 

[WMix]

писал всегда @see класс::метод где все описано

 

[Тугай]

Вурдалак
Речь не идет об рефакторинге своего кода, в текущем интерсном проекте. Сам пишешь сам меняешь.
А об том, то что нанимают програмииста и принуждают его освоить и спаравиться с использоанием инструментов, сегодня это различные фреймворки, и выполнить работу, за это время инстументы дряхлеют и программист становится не нужен, потому-что инструменты стали не те.
И вот в в этот самый момент, когда ты должен все оставить и выучитть новые инстркменты, потому что старые просто динозвры, твой рефакторинг это не улучшение старого кода - это тупая эксплуатация твоих возможностей, на новой базе в новой среде.

Поэтому писать пустые коменты - это бред, не для себя - альтуризм, а для себя - самое то.

А на буржйское buzword рефакторинг, я вообще ложу. Каждый его поймет как захочет.

 

[Adelf]

Тугай
ты свои посты в бредогенераторе чтоли генеришь?

 

[SiZE]

По итогу то чо? =)

 

[MiksIr]

По итогу то чо? =)

нужны

 

[Вурдалак]

По итогу то чо? =)

По-моему, я замечательно ответил тут: http://phpclub.ru/talk/threads/Нужны-ли-комментарии-для-наследуемых-методов.76595/#post-689213

 

[Тугай]

Включу, очредной бредогениратор, напишу такое.
"Не до ООП язык" типа Visual Basic, считался полным говном в сравнении с Delphi, только из-за того что в нем просто не было вобще наследования как такогого.
Кто помнит это - его считали как говно впрочем как и сегодня принимают PHP.
Сегодня "великие умы" нам вещают программируйте интрефесами (короче тупо программируйте на Visual Basic), простая диалектика . Ну и где наследование ?
Это чистый теоретический пуризм. Нужно так свои мозги выстроить, чтоб наследования в проекте вообще не было, тогда и вопроса с дублированием комментов вообще не будет.
Можете снова поприкалываться, но ответ где-то тут.
ИМХО, этот вопрос пересекается с задачей сделать крутую IDE, где возникают "реальные" противоречия с анализом кода.

 

[Adelf]

Тугай
вообще у меня большое желание есть ознакомиться с твоим кодом. Оно осуществимо?

 

[Vladson]

"Не до ООП язык" типа Visual Basic, считался полным говном в сравнении с Delphi, только из-за того что в нем просто не было вобще наследования как такогого.

Только по этому ???? Спешу вас удивить, 99% тех кто считали его "говном" даже не знали что такое ООП ))) Просто тогда другие времена были..

 

[Тугай]

Adelf
Да не вопрос, сейчасас надергаую помелочи кину в личку ссылку.

А для остальных, поделюсь как реализовал недавно "HMVC" в ZF2. Это будет как раз не офтоп, потому как ZF2 - конкретный пример фреймворка построенного на интерфейсах, в котором нет ситуации при которой метод дочернего класса переопределяет базовый.

AbstractBlock.php

<?php
namespace Application\Block;

abstract class AbstractBlock
{
    private $controller;

    public function __construct($controller)
    {
        $this->controller = $controller;
    }

    public function getController()
    {
        return $this->controller;
    }
}

CategoryListBlock.php

<?php
namespace Application\Block;

use Application\Block\AbstractBlock;
use Zend\View\Model\ViewModel;

class CategoryListBlock extends AbstractBlock
{
    public function render($category_id = 0)
    {
        $categoryManager = $this->getController()->getServiceLocator()->get('Application\EntityManager\Category');

        if ($list = $categoryManager->getListByParentId($category_id)) {
            foreach ($list as &$item) {
                $item['sublist'] = $categoryManager->getListByParentId($item['id'], 0, 7);
            }
        }
        $view = new ViewModel(array('list' => $list)); 
        $view->setTemplate('application/block/category-list');
        return $view;
    }
}

CategoryController.php

<?php
namespace Application\Controller;

use Application\Block\NavBarBlock;
use Application\Block\NavMenuBlock;
use Application\Block\CategoryListBlock;
use Application\Block\CategoryListSidebarBlock;

use Zend\Mvc\Controller\AbstractActionController;
use Zend\View\Model\ViewModel;

class CategoryController extends AbstractActionController
{
    public function indexAction()
    {
        $blockNavBar = new NavBarBlock($this);
        $blockNavMenu = new NavMenuBlock($this);
        $blockCategoryList = new CategoryListBlock($this);
        $blockCategoryListSidebar = new CategoryListSidebarBlock($this);

        $view = new ViewModel();
        $view->addChild($blockNavBar->render(), 'blockNavBar');
        $view->addChild($blockNavMenu->render(), 'blockNavMenu');
        $view->addChild($blockCategoryList->render($this->params('id')), 'blockCategoryList');
        $view->addChild($blockCategoryListSidebar->render($this->params('id')), 'blockCategoryListSidebar');
       return $view;
    }
}

То что предлагает Ромер в своей книжке про ZF2 через forward()->dispatch() -- для виджетов это страшный оверхед.

 

[WMix]

покажи плиз \Application\EntityManager\Category::getListByParentId()