我不太确定如何说这个,但我会试试.
假设您在某个程序中有一些设置,其中80%的人确定您不必再次修改.你怎么知道在多变的代码上划线？您知道将设置一直带到用户定义的XML文件是过度的.但是,您也知道稍后可能需要更改这些设置的几率为20%,因此在橡胶与道路相遇的位置进行编码也不是最佳选择.
我想我想要问的是,你应该在多大程度上允许你的程序容易改变抽象树？
许多示例中的一个是手动编写网站的HTML代码与让程序自动生成它.直接编写HTML代码不会花费太多时间.编写程序以自动生成HTML代码需要更长的时间.
过程(或函数,模块等)设计中有哪些常见的最佳实践,用于平衡信息隐藏的需求和过程接口中的适当抽象级别以及引入隐藏依赖项所固有的问题？
更具体地说,假设我编写了一个名为getEmployeePhoneNbr(employeeId)的过程.在内部,通过查询从employeeId键入的数据库表来实现该过程.我想隐藏这些实现细节,但现在该过程依赖于外部文件,如果环境发生变化则会阻碍其使用.
只要程序使用外部资源(文件,数据库等),就会发生同样的情况.以某种方式在程序中硬编码该资源的使用感觉是错误的,但我不确定替代方案是什么.
请注意,我不是使用面向对象的语言; 在可能的范围内,我最感兴趣的是那些广泛适用于任何类型语言的答案.
谢谢,马特
我正在编写一个带有使用Tkinter模块构建的GUI的Python程序.我正在使用一个类来定义GUI,因为它可以更容易地将命令传递给按钮,并使整个事情更容易理解.
我的GUI的实际初始化需要大约150行代码.为了使这更容易理解,我写了__init__这样的函数:
def __init__(self, root):
self.root = root
self._init_menu()
self._init_connectbar()
self._init_usertree()
self._init_remotetree()
self._init_bottom()
where _init_menu(),_init_connectbar()等等进行所有初始化工作.这使我的代码更容易遵循,并防止__init__变得太大.
但是,这会产生范围问题.由于我定义的Entry小部件_init_connectbar()位于函数作用域中而不是类属性,因此我无法在类中的其他方法中引用它.
我可以通过执行大部分初始化来消除这些问题__init__,但是我将失去我用第一种方法获得的抽象.
我应该扩展__init__,还是找到另一种方法将小部件带入类范围？
我在应用程序架构中遇到了障碍.我刚刚开始使用访问者模式在抽象对象上执行特定的算法,这些抽象对象在运行时我不知道.我的问题是我的算法也取决于嵌套抽象类型的类型.
我有一个抽象的DataSource类.从这里我实现了concerete DataSourceReference和DataSourceExplicit类.我还有一个抽象的Report类(反序列化的元数据),我从中实现具体的Report类ReportTypeA和ReportTypeB.创建这些对象时,它们的DataSource可以是任何扩展的DataSource类.
我需要两者,实际的Report类型和DataSource类型,所以我可以相应地执行.我可以使用访问者模式获取协同报告类型,但不知道如何在之后/也为DataSource执行相同操作.
访问报告后我无法访问DataSource,因为我将失去报告的具体类型(因为您必须让它接受基本报告类型:Accept(SomeDataSourceVisitor d,MetaReport m) - 或者为每个可能的报告类型重载,这违背了访客模式的目的.看到我的问题？
有任何想法吗？我不想使用动态,因为它不需要新报表类型的开发人员确保调度程序(访问者)支持新报表.
public abstract class DataSource
{
}
public class DataSourceReference : DataSource
{
// reference thing(s)
}
public class DataSourceExplicit : DataSource
{
// explicit thing(s)
}
public abstract class Report
{
// some shared Report attribute(s)
// ...
public DataSource DataSource { get; set; }
public abstract FinalReport Execute(IReportExecutionDispatcher d);
}
public class ReportA : Report
{
// ReportA specific attribute(s)
// ... …architecture abstraction multiple-dispatch double-dispatch visitor-pattern
有没有办法使用Scala的类型系统来简明地指定完整对象图的上下文相关子图？
DCI认为你经常有一个相当复杂的对象图,但在任何一个用例中你通常只想使用一个子图.你有一个Fooa Bar和a Bat,但是当你处于用例1时,你只关心Bar用例2和用户2时的情况Bat.
例如,假设您拥有此结构,Foo->Bar->Baz->Bin并且Role1用例需要和Role2用例需要Foo->Bat->Baz->Buz:
class Foo{
val bar = new Bar() //Only relevant to Role 1
val bat = new Bat() //Only relevant to Role 2
}
class Bar {
val baz = new Baz()
}
class Bat {
val baz = new Baz()
}
//Relevant to both Role 1 and 2 (via Bar or Bat)
class Baz {
val bin = new Bin() //Only relevant to …由于Mark Seemann的引用,我可能无法完成任务:
如果您有一个特定的ORM,那么请明确它.不要将其隐藏在界面后面.它会产生一种幻觉,即您可以将一种实现替换为另一种实现.在实践中,这是不可能的.
但我想要完成的是通过改变我在启动时的依赖关系来切换我的实体框架ORM与MongoDb驱动程序.
但是我一直遇到问题,我没有提供足够的灵活性,或者只是new NotImplementedException();在我的MongoDb实现中有太多的问题.
我的接口当前结构如下所示:
public interface IReadEntities
{
IQueryable<TEntity> Query<TEntity>() where TEntity : Entity;
}
public interface IWriteEntities : IUnitOfWork, IReadEntities
{
TEntity Get<TEntity>(object firstKeyValue, params object[] otherKeyValues) where TEntity : Entity;
Task<TEntity> GetAsync<TEntity>(object firstKeyValue, params object[] otherKeyValues) where TEntity : Entity;
IQueryable<TEntity> Get<TEntity>() where TEntity : Entity;
void Create<TEntity>(TEntity entity) where TEntity : Entity;
void Delete<TEntity>(TEntity entity) where TEntity : Entity;
void Update<TEntity>(TEntity entity) where TEntity : Entity;
}
public interface IUnitOfWork …c# abstraction entity-framework dependency-injection mongodb
我想阅读有关抽象的内容，但阅读有关它的不同帖子使我感到非常困惑。
所以，这是我无法理解的问题：
1） “抽象是通过抽象类和接口实现的吗？” 我已经搜索过这个，我得到了三种类型的答案：
哪一个是真的？请举一个简单的例子。
2） “抽象意味着隐藏不必要的细节。就像专注于一个对象的作用而不是它是如何完成的。”
这样对吗？
3）在抽象类中，我们可以定义具体的实现和方法签名，我们强迫开发人员（使用抽象类的人）自己编写实现。那么，如果他正在编写自己的实现，那怎么可能是抽象的呢？我认为抽象是隐藏实现。在接口中，开发人员必须编写每个方法实现。
那么，抽象从何而来？
4）抽象的字典定义意味着“处理想法而不是事件的质量” - 我认为这是接口的正确定义，部分是抽象类的定义。但是计算机领域/领域中抽象的定义是“隐藏不必要的细节”（简而言之）。
我区分它们是否正确？
请使用示例或简单的陈述来解释/回答这个问题。
谢谢！
我知道我们可以通过接口实现100%抽象,使用抽象类实现部分抽象.
在采访中,面试官让我告诉任何其他方式实现100%抽象,除了接口.还有其他方法吗？
我意识到这可能属于库设计和功能实现的范围，但想问问我们是否可以在不同来源（例如 Observable 和 Completable）上使用 Transformer，因为它们共享很多方法，特别是侧面效果。我们没有通过扩展来创建我们自己的操作符，而是创建了转换器来处理我们通常与可观察对象和可完成对象一起使用的逻辑。
例如，我们没有包装 subscribe 调用返回的一次性对象，而是为它创建了一个 Transformer 函数：
public static <T> ObservableTransformer<T, T> dispose(CompositeDisposable compositeDisposable) {
return observable -> observable.doOnSubscribe(compositeDisposable::add);
}
现在，这不适用于 Observable 以外的任何其他来源，我们需要添加另一种方法来完成
public static CompletableTransformer disposeCompletable(CompositeDisposable compositeDisposable) {
return completable -> completable.doOnSubscribe(compositeDisposable::add);
}
这已经成为一种模式，只处理 2 个具有完全相同方法的不同源的转换器
例如
public static <T, V extends Progressive & Erroneous> ObservableTransformer<T, T> progressiveErroneous(V view) {
return observable -> observable
.compose(progressive(view))
.compose(erroneous(view));
}
public static <V extends Progressive & Erroneous> CompletableTransformer progressiveErroneousCompletable(V view) {
return observable -> observable
.compose(progressiveCompletable(view))
.compose(erroneousCompletable(view));
}
对于这些，我们必须实现 …
我没有在 Google 甚至 StackOverflow 上找到任何明确的答案来回答这个问题。
根据我的理解
但是锁如何以及为什么会破坏抽象和可组合性呢？