如果C＃项目变得很大，我如何管理？ [英] How do I manage C# project when it gets quite big?

问题描述

您好。我正在开发图形块编程工具 [ ^ ]但似乎我遇到了问题。

因为我基本上使用矩形来绘制块和用于绘制每条线的连续线，用于扩展基本矩形或线类的连续类为该特定对象添加更多功能。



例如，让我采用线类层次结构：

1. WireBaseClass - 有行对象，定义：WireName，WireOrientation，StartPosition，EndPosition等等。

2. WireConnectableClass - 扩展了WireBaseClass，添加了将两条线连接在一起作为双链表的功能。

2. WireMoveClass - 扩展WireBaseClass，添加移动电线的功能



所以现在我几乎没有问题：

a）我已经开始使用h了当我定义新的线对象时，整个项目中的最高线（当时 - WireMoveClass ）。现在我面临的问题是如何在不改变我的整个项目的情况下扩展WireMoveClass（添加更多功能）？



b）如何将已经实例化的类升级到更高层次（一旦满足一些要求，就给它提供更多功能。例如：

WireReferenceClass 应该为 WireMoveClass 添加功能。我是否必须将 WireMoveClass 的每个属性复制到 WireReferenceClass 才能实现这一目标？





我想，换句话说，我正在努力继承。

任何帮助都非常感谢和欢迎。



亲切的问候

Hi. I am developing graphical block programming tool[^] in WPF but it seems I've got myself into problem.
As I am basically using rectangles to draw blocks and lines to draw wires each, successive class that extends basic rectangle or line class adds more functionality to that particular object.

So for example let me take wire class hierarchy :
1. WireBaseClass - has line object, defines : WireName, WireOrientation, StartPosition, EndPosition and so on..
2. WireConnectableClass - extends WireBaseClass, adds functionality to connect two wires together as double linked list.
2. WireMoveClass - extends WireBaseClass, adds functionality to move wire

So now I have few questions/problems :
a) I've started using hierarchically highest wire (at that time - WireMoveClass) throughout project as I defined new wire objects. Now I am facing problem how to extend WireMoveClass (to add more functionality) without changing my whole project?

b) How to 'upgrade' already instantiated class to hierarchically higher (to give it more functionality) once it met few requirements. For example :
WireReferenceClass should add functionality to WireMoveClass. Do I have to copy each attribute form WireMoveClass to WireReferenceClass to achieve that?


I guess, in another words, I am struggling with inheritance.
Any help is much appreciated and welcome.

Kind regards

推荐答案

你最好的选择是坚持像SOLID这样的原则。

并且还使用设计模式：

http://www.dofactory.com/net/design-patterns [ ^ ]



在你的情况下我会建议像Builder，Factory Method，Decorator，Template Method或Visitor这样的模式。



只是试着快速浏览它们并思考这个解决方案如何帮助我们你。



如果你在继承/多态性方面苦苦挣扎，你可以开始阅读这几篇文章es：



OOP潜水（第1天）：多态性和遗传（早期结合/编译时间多态性） [ ^ ]



如果你发布一些你工作的例子，我们可以帮你解决一些具体的例子。

Well your best option is stick to principles like SOLID.
And also use design patterns:
http://www.dofactory.com/net/design-patterns[^]

In you case I would suggest patterns like Builder, Factory Method, Decorator, Template Method or Visitor.

Just try to make a quick look on them and think about how this solution could help you.

If you struggling with inheritance/polymorphism you can for start read this few articles:

Diving in OOP (Day 1) : Polymorphism and Inheritance (Early Binding/Compile Time Polymorphism) [^]

Also if you post some examples of you work we can help you with some concrete examples.

很抱歉，我没有给你任何明确的建议。如果不了解项目的所有基本细节，那将完全不可能。只能给出非常一般性的建议。我想你自己并不期望这样的建议。如果感觉你只是需要一些保证。



我想说已经太晚了，但这会产生误导，可能会出错。当然，修复你的项目永远不会太晚。看起来你希望从根本上改变你的项目开发，而不是做太多的工作，显然，不会让它变得更糟。这可能为时已晚。



首先，请看我的帖子： http://www.codeproject.com/Members/SAKryukov?msg=5157460#xx5157460xx [ ^ ]。



你能看到我来自哪里吗？如果你的架构在这个意义上是好的，你可能根本不会问这个问题，所以可能不是，然后这意味着你必须努力。不要误解我的意思：同样，可能存在一些简单方法存在的变化，但话说再来一次，如果不了解项目的更多细节就不可能看到它。您提供的详细信息不是确定的。通常，类的扩展不是问题，很少需要重新设计，但是沿着层次结构移动类可能是个问题，除非您的体系结构非常灵活。但事实上，即使有一个像扩展这样简单的事情你也有一些问题，这是一个不好的迹象：它告诉我们你很可能必须做一个重大的重新设计。这就是我上面提到的保证：这就是它：如果你觉得你需要重新设计，做重大的重新设计，不要害怕它。



我会告诉你更多：通过观察，真正好的项目至少开发两次，第二次尝试几乎从头开始。这很自然;首先，你创建一个真正工作的原型，并不喜欢它。但是你清楚地看到你所犯的所有错误，所以你很乐意从头做同样的项目。只有这样你才能创造出一个非常好的东西。



看，我看到很多人会抗议这个想法;他们说这很浪费。很糟糕的是，有太多这样的人，他们已经通过否认需要时间来制造这样的原型而造成了巨大的时间浪费。他们假装他们节省了很多时间，但事实上他们创造的项目永远不会成熟，并且浪费了很多时间在所有那些具有无限改进的多个版本上，往往永远不会得到一个可接受的好产品。

-SA

Sorry that I'm not giving you any definitive advice. Without knowing all essential detail of your project, it would be simply impossible. Only a very general advice could be given. I think you do not expect such advice yourself. If feels like you just need some reassurance.

I want to say "it's too late", but it would be misleading and could be taken wrong. Of course, it's never too late to fix your project. It looks like you wish to change your project development radically while not doing too much work and, apparently, not making it worse. And this is something which might be too late.

First of all, please see my post: http://www.codeproject.com/Members/SAKryukov?msg=5157460#xx5157460xx[^].

Can you see where I'm coming from? If your architecture was good in that sense, you probably would not ask this question at all, so probably it is not, and then it means that you have to go hard way. Don't get me wrong: also, there could be some change that the easy way exists, but then again, it would be impossible to see it without knowing a lot more detail of your project. The detail you provided are not definitive. Usually, extension of the class is not a problem and rarely requires any redesign, but moving a class along the hierarchy could be a problem, unless your architecture is extremely flexible. But the fact that you have some problems even with such a simple thing as extension is a bad sign: it tells us that most likely you have to do a major redesign. And this is the reassurance I mentioned above: this is what it is: if you feel you need major redesign, do major redesign, don't be afraid of it.

I would tell you more: in by observation, really good projects are developed at least twice, with second attempt performed nearly from scratch. This is pretty natural; first you create a really working prototype and don't like it much. But then you clearly see all the mistakes you have made, so you gladly do the same project from scratch. And only then you create a really good thing.

Look, I see many people who would protest this idea; they say this is wasteful. Too bad that there are too many of such people, who already caused enormous waste of time by denying the need for the time for such prototype. They pretend they saved a lot of time, but in fact they create projects which never reach maturity, and waste a lot more time on all those multiple version with endless "improvements", often never coming to an acceptably good product.

—SA

这篇关于如果C＃项目变得很大，我如何管理？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！