编写灵活软件的指南?
一段时间以来,我一直在为我的(深奥的,如果你愿意的话)编程语言开发一个 C++ 解释器。我注意到的主要事情之一:我从一个灵活的概念开始,并且我编码得越多(Tokenizer-> Parser-> Interpreter),整个系统的灵活性就越低。
例如:我一开始没有实现 include
函数,但解释器已经启动并运行 - 我在实现它时遇到了极大的困难,就像后来“修补了一些东西”一样。我的系统很快就失去了灵活性。
- 我如何学习在开发过程中保持相对较小的 C++ 项目尽可能灵活和可扩展?
I've been developing an interpreter in C++ for my (esoteric, if you want) programming language some time now. One of the main things that I have noticed: I start with a flexible concept, and the further I code (Tokenizer->Parser->Interpreter) the less flexible the whole system gets.
For example: I didn't implement an include
function at first, yet the interpreter was already up and running - I had extreme difficulties implementing it and it was just like "patching something out" later on. My system had lost flexibility very quickly.
- How can I learn to keep relatively small C++ projects as flexible and extensible as possible during development?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您需要保留
那么你就没有产品规范,没有真正的目标,也没有办法定义成品。
对于商业产品来说,这是最糟糕的情况。套用一位知名博主(不记得是谁)的话说:“除非你定义了你不打算做什么,否则你还没有得到一个产品。”
对于个人项目来说,这可能不是问题。将其记入经验并记住以供将来参考。重构并继续。
If you need to keep
then you haven't got a product specification, you have no real goal and no way of defining a finished product.
For a commercial product this is the worst situation to be in. To paraphrase one well known blogger (can't remember who) "you haven't got a product until you define what you aren't going to do."
For personal projects this might not be a problem. Chalk it up to experience and remember for future reference. Refactor and move on.
在开始编码之前定义项目的结构。概述您的主要目标并思考如何实现该目标。
对标头进行编码。
看看是否可以使用这组接口来实现每个功能
如果不能 ->返回(2)
如果是->代码.cpp文件
享受。
当然,这不适用于真正的大型项目。但如果您的设计是模块化的,那么将项目划分为单独的部分应该不会有任何问题。
Define the structure of the project before you start coding. Outline your main objectives and think about how can you achieve that.
Code the headers.
Look if it's possible to implement every feature using this set of interfaces
If no -> go back to (2)
If yes -> code .cpp files
Enjoy.
Of course, this doesn't apply to really large projects. But if your design is modular, there shouldn't be any problems to divide the project into separate parts.
不要害怕进化(重构)。
如果有许多适合某个主题的类,请创建一个公共基类。
使用指向抽象基类的指针,而不是对数据成员进行硬编码。
例如,不要使用
std::ifstream
,而是使用std::istream
。在我的项目中,我有阅读和写作的抽象类。支持读写的类使用这些接口。我可以将专门的读者传递给这些类,而无需更改任何代码。数据库读取器将从 Reader 基类继承,因此可以在使用读取器的任何地方使用。
Don't fear Evolution (Refactoring).
If there are many class that fit a theme, create a common base class.
Instead of hard coding data members, use pointers to an abstract base class.
For example, instead of using
std::ifstream
usestd::istream
.In my project, I have abstract classes for Reading and Writing. Classes that support reading and writing use these interfaces. I can pass specialized readers to these classes without changing any code. A data base reader would inherit from the base Reader class, and thus can be used anywhere a reader is used.