我目前正在尝试将我们的页面模板转换为OOP，我有一种感觉，我为导航类提出的东西从根本上来说并不正确。
- 这些方法中的一些真的属于
drawNav的扩展类吗 getMenuBar->generateMenuBar->generateMenuItems结构是否击穿过多？它应该只是getMenuBar，并将来自generateMenuBar()和generateMenuItems()的所有内容放入getMenuBar()吗
我调用类和方法的方式：
$drawNav = new drawNav();
$breadcrumbTrail = $drawNav->getBreadcrumbTrail();
$menuBar = $drawNav->getMenuBar();
代码：
class drawNav {
public function __construct() {
//I’ve not nothing to put here…
}
public function getMenuBar()
{
return $this->generateMenuBar();
}
public function getBreadcrumbTrail()
{
return $this->generateBreadcrumbTrail();
}
public function getSocialMediaButtons()
{
return $this->generateSocialMediaButtons();
}
private function generateSocialMediaButtons()
{
//return the HTML code with the social media buttons
}
private function generateMenuBar()
{
//Generate the HTML containing the menu and social media buttons
$this->generateMenuItems();
$this->getSocialMediaButtons();
//Generate the HTML closing tags for the container for the menu and social media buttons
}
private function generateMenuItems()
{
//Call to the database and generate each individual menu item and its dropdown
}
private function generateBreadcrumbTrail()
{
//Generate the HTML containing the breadcrumb trail
$this->generateBreadcrumbs();
//Generate the HTML closing tags for the container for the breadcrumbtrail
}
private function generateBreadcrumbs()
{
//Call to the database and generate the pieces of the breadcrumb trail
}
}
getMenuBar->generateMenuBar->generateMenuItems结构是否击穿过多？
是的。绝对没有理由对封装私有方法的单行公共方法进行一对一映射。这不在任何人的最佳OOP实践列表中。
而不是这种怪异：
public function getSocialMediaButtons()
{
return $this->generateSocialMediaButtons();
}
// ...
private function generateSocialMediaButtons()
{
//return the HTML code with the social media buttons
}
你应该简单地这样做：
public function getSocialMediaButtons()
{
//return the HTML code with the social media buttons
}
如果您担心能够在公共接口中混合和匹配私有方法，那么以后重构起来非常容易。但是，编写单行公共方法（其唯一目的是调用与几乎完全相同名称的的私有方法）是一种巨大的代码气味。
否则，您的代码很好，但有一点需要注意：我希望您的"返回带有社交媒体按钮的HTML代码"是在呈现一些外部HTML模板文件，而不是在类内内联编写HTML。后台/前端逻辑的良好分离比代码部分的结构更重要；我宁愿看到干净地分离业务/视图逻辑的过程代码，也不愿看到将它们混合在一起的精心制作的面向对象代码。
我认为如何分离方法并没有什么大问题。我个人宁愿让类方法处理一些特定的操作，然后使用其他方法将"构建块"方法组合成更复杂的操作。例如，如果您需要更改breadcrumb数据库逻辑，则只在该方法中更改它，并且该方法从其他方法中抽象出足够多的内容，从而达到不需要更改的程度。
您所拥有的似乎很好。
我想问您是否有一个Navigation类，因为这一切都可以添加到其中，或者作为Navigation类别的扩展，以保持整洁。