我正在编写一个 WPF 组件，它显示一个看起来像帕累托图的图表​​。它工作正常，但我觉得这很垃圾，原因如下：

• 它使用了这么多容器，对于一个简单的图表，可能有大约 50 个容器构成它；

• 我使用边距（存储在 ViewModel 中）将矩形放在好的位置，我觉得这真的很难看，但我还没有想到更好的方法；

• 我需要知道 ViewModel 中图形组件的大小才能将组件放置在正确的位置并根据它进行缩放；

• 我正在使用两层来渲染图表，一层用于图表，另一层用于显示图表的比例，我认为这根本不好

它看起来如何

http://hpics.li/fd2b0bd （无法显示图像，因为我是新人）

视图模型

顶部对象是ParetoChartVM，包含 SerieVM 的 ObservableCollection 和 AxisVM 的另一个，标题和图表的当前大小。

SerieVM由 ValuePointVM 的 OservableCollection 组成（在图表中表示一个矩形）。

ValuePointVM包含一个画笔、一个数值、一个宽度和高度以及边距（厚度对象）。

AxisVM包含 ScaleVM的MinimumValue、MaximumValue、NumberOfScales 和 ObservableCollection。

ScaleVM包含一个 Value、一个ValuePercentage（在顶部显示值，在底部显示最大值的百分比）、一个 TopMargin 和一个 BottomMargin（两个厚度对象）。

看法

View 层仅包含一个 ParetoChartV WPF 组件。这个组件只包含一个ParetoChartVM，他的DataContext设置为这个ParetoChartVM。

这个怎么运作

每次调整图表容器的大小时，我都会通知 ParetoChartVM，它会重新计算每个位置/宽度/高度，并使用这些属性上的绑定来更新界面。

现在这里是 XAML（它非常大）：

因此，对于每个 ObservableCollection，我创建了一个 ItemsControl 来存储和显示它们，我还需要在 ItemsControl.ItemsPanel 中放置一个 Canvas 以将每个组件放置在我想要的边距位置。这些项目也在 ObservableCollection 中，因此我需要将它们也放在 ItemsControl 中，并将 Canvas 作为 ItemsPanel。

你觉得我的代码结构有问题吗？如果您确实看到了一些，请告诉我，尽可能多地解释它们，因为我开始使用 WPF 和 MVVM 模式。

（我使用的是 dotnet 框架 3.5 版，所以我不能对容器的 SizeChanged 事件使用交互性）

感谢您的帮助和时间

编辑（一个相关的问题）

我遇到的一个附带问题是我做了一个转换器，以将 Textblocks 居中在特定点上（将显示比例值的文本居中，并在图表中使用垂直虚线）。

这是我的做法：

在 XAML 中，我像这样更改了 Textblocks：

所以我命名它们并将多个值传递给转换器。

所以它可以工作，只是当受到压力时，这个转换器会使组件变得疯狂，然后转换器每秒被调用大约 10 000 次，似乎处于无限循环中。图表将不再调整大小（但窗口中的其他组件仍在响应调整大小）。请注意，我提供的屏幕截图是我使用这个转换器的地方，因为这个问题我停止使用它。

你知道为什么会这样吗？

编辑n°2（关于侧面问题）

我做了一些测试，转换器问题似乎与转换器的 ActualWidth 参数有关。Textblock 似乎有浮点问题。事实上，我没有改变的宽度突然从〜8.08变为〜28.449。以下屏幕截图显示了此值：

http://hpics.li/63af790

（左边的值是调用转换器的次数，右边的是作为参数传递的实际宽度）

ActualWidth 值在 28.44999999... 和 28.45 之间变化，每次都会触发转换器，让图表变得疯狂。

知道如何解决吗？（我试图理解为什么宽度突然跳跃，因为我从来没有碰过它（我改变了 Textblock 的左边距和上边距，而不是它的宽度））

编辑n°3（关于侧面问题）

我检查了边距是否可以改变文本块的宽度，但只有左边距和上边距会改变，下边距和右边不会改变。我在 xaml 中将绑定从 Margin 更改为 Canvas.Left 和 Canvas.Top ，如下所示：

然后错误消失了，文本块的宽度不再改变，这导致了这个错误。所以问题解决了，但我仍然不明白为什么。

我刚刚开始了一个完全用 Assembly 编码的大型项目。有多个子例程、宏、内存表等。我想知道如何最好地将代码拆分为多个文件。目标显然是更好的结构和更好的可读性。

目前我使用一个包含所有常量定义（.equ）的 .inc 文件，但是如何处理我的许多子例程？如果我想将它们放在另一个文件中，是否需要使用 .asm 文件（因为它包含可执行代码）？更笼统地说：.asm- 和 .inc-文件之间有什么区别，尤其是在最终将它们包含到一个主文件中时？

一旦我拆分了文件，我该如何处理多个依赖项（即文件 A 包括文件 B 和文件 C ，其中文件 B 也包括文件 C）。由于显然我当前的环境 Atmel Studio 6 不喜欢双重包含。

我无法让方法覆盖工作。现在我有一个名为 Sprite 的类和两个子类；我们称他们为 Goomba 和 Koopa。Koopas 和 Goombas 的实例存储在名为 spriteList 的 sprite 的 std::list 中，迭代器遍历此列表并调用每个 sprite 的行为() 函数。

通过将行为函数定义为 Sprite::behave()，我可以单独使用 Goombas。但是如果我尝试对 Koopas 做同样的事情，编译器会发疯，因为 Sprite::behave() 已经在 Goomba 中定义了。我究竟做错了什么？我觉得答案是一个非常简单的语法问题，但是在网上查看并没有发现与我的代码非常相似的示例。

我会粘贴一些代码，希望它会有所帮助。这不是我的确切源代码，所以对于任何拼写错误，我深表歉意。

这是一个简单的案例：

这是一个类级别的字段，因此将其称为匿名类似乎并不正确。嵌套类的 Oracle 教程页面中的其他名称或描述似乎都不合适。

我猜它类似于“单次使用对象”，但我什至很难描述它而不说“类级别命名匿名类”之类的东西

对于那些不熟悉 Java 和 AWT 的人，我正在创建一个类的实例，该类具有无操作方法来实现侦听鼠标操作的接口。我想要一个实际的实例，所以我可以将它添加为多种类型的侦听器（滚轮、运动和点击），但使用相同的对象进行控制。这个问题本身并不是 AWT 特有的。

假设有一个场景如下： 有一个与设备边框大小相同的场景。场景中有一个红色的球，它可以在“世界”中移动。这个世界是由黑色和白色区域定义的，球只能在白色区域内移动。这是一张帮助解释的图片：

可以擦除部分黑色区域，就像用户在场景上用白色绘制一样。这意味着可以移动球的区域不断变化。现在，如何为白色和黑色区域之间的边缘实现一个物理体？

我尝试在每次更改物理体时重新定义它，但是一旦形状变得足够复杂，这根本不是一个可行的解决方案。我尝试创建一个不可见的“盒子”二维数组，并指定每个盒子内的大部分区域是白色还是黑色，如果球碰到黑色盒子，它将被推回。但是，这需要大量的渲染和对数组的过多迭代。由于我的原始数组包含比像素大一点的框，我尝试让这些框更大以使运动稍微平滑一点，但这最终导致球的一部分被白色区域停止并看起来在黑色区域内。这是不希望的，因为用户可以感觉到他们似乎正在撞击的无形障碍。

我尝试寻找其他方法来实现这种“可破坏地形”类型的场景，但我找到并尝试的解决方案是使用其他游戏引擎。为了进一步澄清，我使用的是 Objective-C 和 Apple 的 SpriteKit 框架；而且我不是在寻找一个充满代码的详细类，而是在寻找一些伪代码或实现想法，它们会引导我找到解决方案。

谢谢你。

样式 xml 取自：

https://code.google.com/p/google-styleguide/source/browse/trunk/eclipse-java-google-style.xml

在 Eclipse Luna（版本 4.4.1）中，转到：

1. 窗户
2. 喜好
3. 爪哇
4. 代码风格
5. 格式化程序
6. 导入 eclipse-java-google-style.xml

但我收到这条消息：

此配置文件是使用比您正在使用的版本更新的 Eclipse 构建创建的。一些较旧的设置可能会重置为其默认值，而较新的设置将被忽略。请注意，完全支持将配置文件从旧版本升级到新闻版本。

有人知道这个问题吗？目前 eclipse Luna 4.4.1 应该是最新的 eclipse 版本，那么我该怎么做才能解决这个问题？

或者另一个问题：有人知道其他符合 java 编码标准的好格式 format.xml 吗？

我们有一些像这样的配置存储类：

优点：

• IDE 提供的重构和导航支持。

缺点：

• 我不确定，它看起来有问题。

我什至不确定，它应该被称为配置。我应该用 XML 替换这些类吗？像这样：

I have quite a complex setup, and am looking for advice in how to structure my code. What I'm trying to do is something similar to twitter when you press one of a users images and can swipe through them. This is what I have at the moment:

• A UIViewController subclass that gathers data from a server, and passes it to a UITableViewController subclass through a variable called theData
• This UITableViewController subclass also gathers more data as the users scrolls to the bottom of the table view and appends it to theData (i.e. uses pagination). This UITableViewController subclass is reused throughout the app so that data from a different source can be passed to it.
• When a user clicks on a UITableViewCell, a UIWindow is created which has a UIPageViewController inside it. The window uses the UITableViewController as a delegate to access theData, and passes the theData from the delegate to the UIPageViewController in a variable called pageData
• Each page of the UIPageViewController is a UIViewController that loads images from the pageData

The next stage is to do pagination as the user swipes to the end of the pageData in the UIPageViewController. However I don't think my code is structured well enough to reuse the pagination code from the UITableViewController. Please could someone give me advice on how to improve this code structure?

Thank you

EDIT

The UIViewController in the first bullet point does more than just downloading data (it has other views within it).

I use a UIWindow to encapsulate the UIPageViewController because I want it to expand from the frame of the UITableViewCell and "take over" the full screen - covering the status bar.

我有一个UIView子类充当内部“通知”系统，它内部有一个标签，显示通知文本并从视图顶部向下动画并备份。我需要创建一个系统来创建这些通知的队列（可以从我的应用程序中的任何位置添加），并一个一个地显示它们，但想知道我应该如何构建它。

我应该使用管理这些UIViews 队列的单例吗？还是应该有UIViewController一个队列？或者是其他东西？

谢谢！

所以，这是另一个“好的”编程练习题。我确实搜索了一下，但这样的事情通常很难用几句话来定义。

问题是：从专业的角度来看，保持代码精简和简短（不一定更高效）或显式定义实例变量只是为了分配它们并立即返回是更好的编程实践吗？例如：

从上面，我们可以立即看到foobar返回 a FILE *。因此，从这种编程风格中，我们可以更快地提取重要信息。与以下内容相比，这是正确的：

当然，它完成了同样的事情。但是，必须更深入地寻找才能找到相同的信息。我倾向于支持后一种编程风格，仅仅是因为它看起来更好。由于该程序运行方式的性质，我怀疑使用其中任何一种都会立即获得性能提升，因为任何一种选择仍然需要内存 - 区别在于用户或编译器是否分配它。

作为另一个保持代码简洁的例子：

TL:DR 问题>> 明确显示正在做的事情是否更好，或者是否可以，有利于简洁明了，缩短完成相同任务但不一定提供性能提升的代码？