blocks|key|1428138|text|实例的数量与类是否应该存在的事实无关。一个类只实例化一次是完全正常的。您的BaseHero设计听起来很合理。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1428139|entityMap^0|11|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

The number of the instances isn't connected to the fact if the class should exist or not. It is completely normal to instantiate a class only once. Your design with <code>BaseHero</code> sounds reasonable.

blocks|key|5447332|text|我会让BaseHero变得抽象，这样你就不能在不将其子类化为不同字符的情况下实例化它，同时仍然可以获得一些很好的继承好处。您还可以强制使用单例模式，以便一次只能创建其中的一个，不过也可以像您所说的那样，简单地设置一个标记，以确定该字符是否被占用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|5447333|CharacterList应该是其他的东西。如果需要字符列表，只需创建一个List<BaseHero>即可。对我来说，将所有其他逻辑放在一个List类中是没有意义的。|5447334|此外，在制作角色时，尽量遵循组合而不是继承。例如，角色有一个异能，而不是角色ISA+characterWithAbility。|5447335|entityMap^0|3|8|0|0|D|11|E|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|T|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|K|$]]

I would make <code>BaseHero</code> abstract so that you cannot instantiate it without subclassing it into different characters, while still getting some nice inheritance benefits. You could also enforce the singleton pattern so that only one of each can be created at a time, though it would also be easy to just set a flag for whether that character is taken or not like you said.

<code>CharacterList</code> should be something else. If you need a list of characters you can just create a <code>List&lt;BaseHero&gt;</code>. It wouldn't make sense to me to put all that other logic into a List class.

Also, try to follow composition over inheritance while making your characters. For example, character HASA ability instead of character ISA characterWithAbility.

blocks|key|3978523|text|我认为应该使用两个抽象方法specialAbility和someFlavorText.来使BaseHero成为抽象类您可以根据需要在角色自己的类中根据需要定义两种方法。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3978524|entityMap^0|D|E|S|E|19|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

I think BaseHero should be made abstract class and with two abstract methods specialAbility and someFlavorText. You can define the two methods as per needed in the characters own classes as needed.

blocks|key|3978559|text|也许接口/抽象类是我的解决方案，例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3978560|//+the+abstract+interface+which+can+be+called+"BaseHero"
public+interface+Character+{

++++void+action();

++++void+special();

++++//+another+general+methods

}


//+The+true+implementation+of+the+characters
public+class+HeroOne+implements+Character{

++++@Override
++++public+void+action()+{
++++++++//+do+the+actions
++++}

++++@Override
++++public+void+special()+{
++++++++//+do+the+specials
++++++++HeroOneShapeAfterSpecial();
++++++++//+and+so+on
++++}

++++public+void+HeroOneShapeAfterSpecial(){
++++++++//+Hero+One's+special+method
++++}
}


//+another+implementation
public+class+HeroTwo+implements+Character{

++++@Override
++++public+void+action()+{
++++++++//+Hero+Two+action
++++}

++++@Override
++++public+void+special()+{
++++++++//+Hero+Two+Special
++++}
}



//an+example+to+use+them
public+class+Main+{

++++//+a+way+to+use+those+Characters
++++public+static+void+main(String[]+args)+{
++++++++Character+heroOne+=+new+HeroOne();
++++++++Character+heroTwo+=+new+HeroTwo();

++++++++//+some+commands+from+what+ever+input
++++++++heroOne.action();
++++++++heroTwo.action();
++++++++heroOne.action();
++++++++heroTwo.special();

++++++++//and+so+on

++++++++//+another+way
++++++++LinkedList<Character>+charactersTeam+=+new+LinkedList<Character>();
++++++++charactersTeam.add(heroOne);
++++++++charactersTeam.add(heroTwo);

++++++++for(Character+character+:+charactersTeam){
++++++++++++character.special();
++++++++}

+++}
}|code-block|syntax|javascript|3978561|一般来说，OO设计更倾向于组合而不是继承(+HAS-A关系比is+-A更好、更灵活)|3978562|但是如果你想使用继承，你可以看一下Decorator模式|3978563|如果你不希望这些子类被多次实例化，你可以让你的子类成为单例……像这样：|3978564|Character+heroOne+=+HeroOne.getInstance();
Character+heroTwo+=+HeroTwo.getInstance();|3978565|对于您所说的特殊能力，special()方法可以承载每个字符的特殊能力，因为它是抽象的，所以每个字符都将实现它|3978566|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Maybe Interfaces/abstract classes is the solution from my point of view, for example:

<pre><code>// the abstract interface which can be called "BaseHero"
public interface Character {

 void action();

 void special();

 // another general methods

}


// The true implementation of the characters
public class HeroOne implements Character{

 @Override
 public void action() {
 // do the actions
 }

 @Override
 public void special() {
 // do the specials
 HeroOneShapeAfterSpecial();
 // and so on
 }

 public void HeroOneShapeAfterSpecial(){
 // Hero One's special method
 }
}


// another implementation
public class HeroTwo implements Character{

 @Override
 public void action() {
 // Hero Two action
 }

 @Override
 public void special() {
 // Hero Two Special
 }
}



//an example to use them
public class Main {

 // a way to use those Characters
 public static void main(String[] args) {
 Character heroOne = new HeroOne();
 Character heroTwo = new HeroTwo();

 // some commands from what ever input
 heroOne.action();
 heroTwo.action();
 heroOne.action();
 heroTwo.special();

 //and so on

 // another way
 LinkedList&lt;Character&gt; charactersTeam = new LinkedList&lt;Character&gt;();
 charactersTeam.add(heroOne);
 charactersTeam.add(heroTwo);

 for(Character character : charactersTeam){
 character.special();
 }

 }
}
</code></pre>

Generally speaking, OO Design favors Composition over inheritence (the HAS-A relations is better and more Flexible than the IS-A)

but if you want to use inheritence, you can take a look at the Decorator Pattern

and if you want the subclasses to not to be instantiated more than once, you can make your subclasses Singletons ... like :

<pre><code>Character heroOne = HeroOne.getInstance();
Character heroTwo = HeroTwo.getInstance();
</code></pre>

and for the special abilities as you say, the special() method can hokd the special abilities of every character, and since it is abstract, each character will implement it

blocks|key|3978589|text|我更愿意把它建模为一个有文字和一些能力的英雄。文本源自属性文件。可以先将普通文本加载到Properties对象中，然后再将特殊文本加载到Properties对象中。我会用一个不同的类别来模拟每种能力。这允许您使用不同的能力集对新角色类进行建模。也许飞马有飞行和魔法，而飞马有飞行和速度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3978590|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'd rather model this as a hero having text and some abilities. The texts origin from properties files. May you first load the common texts and than the special ones into a Properties object. I would model each ability with a distinct class. This allows you to model new character classes using different sets of abilities. Maybe the fay has flying and magic while pegasus has flying and speed or so.

I'm attempting to make a port of a board game. Each player in the board game selects one of eight different characters. Each character has a special ability and some flavor text but aside from that they are more or the less the same.

Currently I have a <code>BaseHero</code> class. I created a class for each of the eight different characters and had them extend <code>BaseHero</code>. However, there will never be multiple instances of the same character. Is this the best way of implementing this?

My alternate idea was to create a <code>CharacterList</code> class that would include the code for all of the special abilities and boolean tests to determine whether or not they exist in the game, but I feel that would be too unwieldy and distinctly un-modular.

(OOP/Java) How should I handle this subclass-superclass relationship?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正试着把棋盘游戏变成一个港口。棋盘游戏中的每个玩家从八个不同的角色中选择一个。每个角色都有特殊的能力和一些风格的文字，但除此之外，它们或多或少是相同的。目前我有一个BaseHero类。我为8个不同的字符创建了一个类，并让它们扩展BaseHero。但是，同一个角色永远不会有多个实例。这是实现这一点的最佳方式吗？我的另一个想法是创建一个CharacterList类，其中包含所有特殊能力和布尔测试的代

问(OOP/Java)我应该如何处理这种子类-超类关系？
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问(OOP/Java)我应该如何处理这种子类-超类关系？EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问(OOP/Java)我应该如何处理这种子类-超类关系？
EN