Tag: oop

如何向上转换Java 8可选对象？

是否有一种有效的方法在使用Optional对象时执行向上转换。 这是一个示例代码： class A{} class B extends A{} B func(){ //do something return new B(); } Optional func2(){ //do something return Optional.of(new B()); } main() { A a = func(); // Upcasting works fine B b = func(); // Upcasting works fine Optional b = func2(); // 1. Upcasting works fine Optional a = func2(); […]

面向对象设计 – 法术

我正在开发我的第一个Java项目，这是一个基本的角色扮演游戏。 现在我处理法术，我需要一些OOD指导。 我有Character ，这是一个abstract class 。 Character有一些subclasses （如mage ， fighter ， rogue ， cleric ）。 Mage和cleric （至于now ，牧师没有法术力 ，但可能会改变）都是施法者。 我还有一个Spell课，有一些信息（如spell name ， mana cost等）。 MageSpellsList和ClericSpellsList是另一个类，都有类Spell列表。 而且我也有Effects类（施放法术应该使用它）。 什么是一个很好的面向对象设计来处理法术（解决方案不应该包括Effects类，我可以稍后处理）？ 也许使用“SpellCaster”界面和一些方法，比如castSpell和showSpellbook，那么Mage和Cleric会实现这个界面吗？ 。 也许MageSpellsList和ClericSpellsList应该是Spell的子类？ 我的目标是使用castSpell（“spell name here”）并让castSpell通过使用一个好的OOD来完成工作，而不是为每个法术编写一个特定的方法（并且在mage和Cleric之间没有重复的代码） Mage.java： public class Mage extends Character { private List spellBook; private int mana; private int CurrentMana; public Mage(String name) { super(name); setName(name); […]

想要在java中的复杂结构上建议（DAO和服务层链接/耦合）

介绍 我试图在Java中使用接口，抽象类和generics构建一个相当复杂的结构。 由于没有仿制药的经验，只有平均创建优质OOP设计的经验，这开始certificate是一个相当大的挑战。 我有一种感觉，我正在尝试做的事情实际上无法完成，但我可以接近它。 我会尽量简短地解释一下。 我只想告诉我，这个结构将代表我的DAO和服务层来访问数据库。 使这个问题更抽象只会让它变得更加困难。 我的DAO层完全没有问题。 有一个通用的DAO接口，每个实体都有一个DAO接口，它扩展了generics接口并填充了generics类型。 然后是每个DAO实现扩展的抽象类，后者又实现相应的接口。 很可能会混淆读取，所以这里是以产品DAO为例的图表： 现在，对于服务类，我有一个类似的结构。 无论如何，服务类中的大多数方法都映射到DAO方法。 如果您使用“服务”替换上图中的每个“DAO”，您将获得我的服务层的基础。 但根据我的以下想法，有一件事我想做： 实体的每个服务类至少将访问一个DAO对象，即它所针对的实体的DAO。 哪个是…… 问题/问题 如果我可以进行适当的OO设计， 使每个服务类都有一个实例变量用于各自实体的DAO对象，我认为服务层将是完美的。 对我的建议是受欢迎的，以防我的设计看起来不那么好。 我已经像这样实现了它： 类AbstractService public abstract class AbstractService { EntityDAO entityDAO; public AbstractService() { entityDAO = makeEntityDAO(); //compiler/IDE warning: overridable method call in constructor } abstract EntityDAO makeEntityDAO(); } 类ProductServiceImpl public class ProductServiceImpl extends AbstractService { […]

Java – 应该通过getter和setter方法在构造函数中访问私有实例变量吗？

我知道私有实例变量是通过他们的公共getter和setter方法访问的。 但是当我在IDE的帮助下生成构造函数时，它直接初始化实例变量，而不是通过setter方法初始化它们。 Q1。 因此，我应该为构造函数更改IDE生成的代码，以通过其setter方法初始化这些实例变量。 Q2。 如果是，那么IDE为什么不以这种方式生成构造函数代码？ ============================= EDITED ==================== =================== 我使用Eclipse和Netbeans IDE 这是一个普遍的问题。 但正如@Lords所要求的那样，答案取决于我们的构造函数是公共的还是受保护的，还是私有的还是私有的？

将null传递给优先使用String的方法，而不是Object

我在我的程序中遇到了一个问题，我在下面的一个小代码片段中说清楚了。 任何人都可以解释为什么会这样吗？ class ObjectnullTest { public void printToOut(String string) { System.out.println(“I am null string”); } public void printToOut(Object object) System.out.println(“I am null object”); } class Test { public static void main(String args[]) { ObjectnullTest a = new ObjectnullTest(); a.printToOut(null); } } 这总是打印I am null string 。 我想知道原因，以便我可以修改代码。

为什么Scanner会实现Iterator ？

我只是想知道为什么java.util.Scanner实现java.util.Iterator ？ Scanner实现remove方法并抛出UnsupportedOperationException 。 但是，在实现接口时，不应该是一个类，履行接口的契约？ 实现iterator和添加抛出exception的方法有什么用？ 为什么不避免接口的实现并保持简单？ 可以认为它被定义为可以扩展Scanner的类可以实现该方法，例如AbstractList有一个抛出UnsupportedOperationException的add方法。 但是AbstractList是一个abstract类，而Scanner是一个final类。 这不是一个糟糕的设计实践吗？

建筑师设计模式的缺点

使用构建器设计模式的缺点是什么。 有没有？ 编辑 – 我想知道使用构建器设计模式是否有任何不良后果？ 与GOF书中一样，他们提到了设计模式的好坏后果。 但他们没有提到建筑师设计模式的任何不良后果。

计算每个派生类的类实例

有没有办法让所有派生类计算他们的实例？如何（用C ++，C＃，Java之一编写代码）？ 想象一下，我可以访问根类（例如对象），并且每个其他类（直接或间接）都是从这个类派生的。 我想要的是： AnyDerivedClass.InstancesCount() 问题是，必须跟踪静态变量中的计数，但是不可能将静态变量“注入”到基类的派生类中，这仅适用于成员变量。 也就是说，我必须写下这样的东西： class object { private static int count = 0; protected object() { ++count; } protected ~object() { –count; } public static InstancesCount() { return count; } }; class derived : object { private static int count = 0; public derived() { ++count; } public ~derived() { –count; } […]

私有成员在Java中真的更“安全”吗？

学习Java我有时被教导使用private访问修饰符，以免将“敏感信息”暴露给其​​他类，好像这可能会打开一个合法的安全漏洞。 但是我从来没有遇到过限制成员可见性不仅仅是以面向对象的方式建模程序的便利的情况。 Java类中的private字段和函数实际上是否比其他类更“安全”？ 编辑 – 汇编最佳答案。 为什么private并不意味着“安全”： 反编译器允许静态查看字节码 reflection库允许运行时访问私有成员 private有什么好处： 由于强制方法级访问而导致的代码可维护性 隐藏实现细节的代码模块化

Java 8是否提供了访问者模式的替代方案？

这个关于Stack Overflow的流行答案有关于函数式编程和面向对象编程之间的区别： 当你对事物进行固定的操作时，面向对象的语言是很好的，随着代码的发展，你主要添加新的东西。 这可以通过添加实现现有方法的新类来完成，并且现有类保持不变。 当你有一套固定的东西时 ，函数式语言是很好的，随着代码的发展，你主要在现有的东西上添加新的操作 。 这可以通过添加使用现有数据类型计算的新函数来实现，并且现有函数是独立的。 说我有一个Animal界面： public interface Animal { public void speak(); } 我有一只Dog ， Cat ， Fish和Bird都可以实现界面。 如果我想向Animal命名为jump()添加一个新方法，我将不得不浏览所有子类并实现jump() 。 访问者模式可以缓解这个问题，但似乎随着Java 8中引入的新function特性，我们应该能够以不同的方式解决这个问题。 在scala我可以很容易地使用模式匹配，但Java还没有真正拥有它。 Java 8实际上是否更容易在现有的东西上添加新操作 ？