程序编程(不是OOP) [英] Procedural Programming (Not vs OOP)

查看:99
本文介绍了程序编程(不是OOP)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,我对编程整体比较陌生,专注于C#作为一种语言,我希望能够提高效率,并且非常享受。



然而,有一些令我感到困扰的问题,并希望就此主题提出一些意见和建议。虽然我理解以对象为中心的编程的概念和优势,但我总觉得结构化编程方法更具吸引力和逻辑性。



我的主要原因是:



我发现OOP的概念难以在情境中使用 - 而Customer对象在逻辑上(在上下文中)完全有意义,有时对象没有。



例如 - 如果我构建了一个由于某种原因解析HTML信息的应用程序,我将很难以OO方式构建它。



也许是因为我对编程很新,从逻辑上讲它有时候没有意义,我不知道,但在任何情况下;结构化确实。



结构化编程今天甚至被接受作为标准吗?

以结构化方式编程是否有误以OOP为重点的语言?



如果可能,你们中的任何人都处于类似情况?有没有人可以给我这方面的链接或建议?



谢谢大家!

任何建议都会一如既往地受到高度赞赏。



编辑 - 我把它列为'结构化'而非程序 - 我的错误。

Hi guys, I am a relatively new to programming as a whole and focus on C# as a language I would like to become efficient at and enjoy very much.

However there are some concerns that bother me and wanted to ask some views and advice on this topic. Whilst I understand the concept and advantage of object focused programming, I always find the structured programming methodology more appealing and logical.

My primary reason is;

I find the concept of OOP to hard to use in situations - whilst a Customer object makes perfect sense logically (in context), Sometimes objects do not.

For example - If I built an application that parsed HTML information for some reason or another, I would have difficulty in structuring this in an OO way.

Maybe because I am new to programming in general, logically it does not make sense sometimes, I don't know but in any situation; structured does.

Is structured programming even 'accepted' as a standard today?
Would it be wrong to program in a structured way even with an OOP focused language?

If possible have any of you guys been in a similar situation? and is there any links or advice anyone could give me in regard to this?

Thank you all!
Any advice is greatly appreciated as always.

EDITED - I had this listed a 'Structured' rather than Procedural - My Mistake.

推荐答案

非常好的问题!如果你对编程比较陌生,我会说你在学习更多知识的过程中经历了非常常见的阶段。毫不奇怪,程序式编程 [ ^ ]吸引您,因为它易于学习且相对容易申请。但也许并不像你想象的那么容易。编写良好的过程代码倾向于结合面向对象编程的各个方面,但编译器不会帮助您。你会在Win32和POSIX中找到大量的例子,其中对象的所有操作(在这种情况下,它意味着像窗口,文件或进程)需要使用句柄或结构,通常作为第一个参数。这个参数必不可少,其目的与OOP中的 this 指针相同。但最大的区别在于,例如在Win32而不是仅仅处理Windows的 Window 类中,我有一个user32.dll库,可以处理windows等许多其他事情。此外,我有这些自由浮动手柄,我需要跟踪而不是强类型对象引用。



我想说的是,曾经你研究大型真实系统,并最终自己构建它们,你会发现正确完成OOP可以使系统比程序/模块化解决方案更容易理解和维护。当然,OOP也不是银弹(我是正确工具的忠实粉丝)但是现在必须对它有一个很好的理解。至于用C#或C ++等语言编写程序代码,那肯定是你可以做的。但是,您不会利用这些语言的功能,最终会在您自己的代码库和标准库之间产生巨大的脱节。就个人而言,我肯定不鼓励人们尝试这一点。虽然C#和C ++是多范式编程语言,但它们可以说是OOP语言。



这就是说,我鼓励你继续扩展你的OOP知识。掌握它需要很长时间。我经常看到应该知道更好的人创建名为 Util Helper 的类,因为他们无法弄清楚特定的位置方法真的属于。我花了好几年的时间才能获得任何好处,但我仍然没有声称我已经掌握了它。它们目前可能有点令人困惑,但是开始阅读有关OOP的书籍,特别是设计模式(有关OOP语言的书籍通常强调语言本身),例如: 设计模式:可重复使用的面向对象软件的元素 [ ^ ]或< a href =http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/>头部设计模式 [ ^ ]。
Very good question! If you are relatively new to programming I'd say you are going through pretty common phases as you learn more. It is no surprise that procedural programming[^] appeals to you since it is easy to learn and relatively easy to apply. But maybe not as easy as you might think. Well-written procedural code has a tendency of incorporating aspects of object oriented programming but without the compiler helping you. You'll find plenty of examples in Win32 and POSIX where all operations on an object (in this context it means something like a window, a file or a process) require the use of a handle or structure, often as the first argument. This argument essential serves the same purpose as the this pointer in OOP. The big difference though is that for example in Win32 instead of a Window class that deals just with windows I have a user32.dll library that deals with windows among many other things. Also, I have these "free floating" handles that I need to keep track of rather than strongly typed object references.

What I'm trying to say is, once you study large real-world systems, and eventual build them yourself, you'll find that OOP done right can make a system easier to understand and maintain than a procedural/modular solution. Of course OOP is no silver bullet either (I'm a huge fan of the-right-tool-for-the-job) but having a good understand of it is a must these days. As for writing procedural code in languages such as C# or C++, well, that's certainly something you can do. However, you wouldn't take advantage of the capabilities of those languages and you would end up with a huge disconnect between your own code base and the standard libraries. Personally, I would certainly discourage people from attempting this. While C# and C++ are multi-paradigm programming languages they arguably are OOP languages first.

That said, I would encourage you to keep expanding you knowledge of OOP. It takes a long time to master it. I regularly see people who should know better create classes called Util or Helper because they can't figure out where a particular method really belongs. It certainly took me several years to get any good at it and I would still not claim that I've mastered it. They might be a bit confusing at the moment, but start reading books about OOP, design patterns in particular (books about OOP languages usually put emphasis on the language itself), e.g. Design Patterns: Elements of Reusable Object-Oriented Software[^] or Head First Design Patterns[^].


以前的解决方案是正确的..但我会尝试实际操作它。



没有什么可以阻止你这样做: -



The previous solutions are correct .. but Im going to try and walk through it practically.

There's nothing stopping you from doing this :-

static void Main(string[] args)
{
    // Get A Connection To A Web Page OR Get HTML From A File

    // Get The HTML

    // Parse The HTML

    // Do Things With The HTML Parsed results

}





在您的主要部分,将您需要的所有代码放在那里,并使其工作 - 这是困难的部分 - 调试它,支持它等,可能是一个正确的噩梦!



所以,也许,你可能会认为'我需要坐下来并抽象出功能'确定...下一次重写看起来像: -





in your main, putting all the code you need there, and making it work - there's the hard part - debugging it, supporting it etc, could be a right nightmare !

So, maybe, you'd think 'I need to sit back from this and abstract out the functionality' ok ... the next re-write looks like :-

static void Main(string[] args)
{
    // Get A Connection To A Web Page OR Get HTML From A File         (Object : HTMLConnection & Methods)

    // Create Some Kind Of HTML-Worker-Processing Object That :-
    // Gets The HTML (From a File or Web Page)                        (Method) 
    //      If Web Page May Accept HTML Connection As Parameter
    // Parses The HTML (Possibly using someone elses HTML Parser)     (Instanciate Parser And Call Method(s))
    // Does Something With The HTML Like Write It Do A File           (Method)


}





所以,你正在从你的'结构模型'演变为'对象模型'。从结构的角度开始用你所知道的问题开始攻击问题并没有错,并且根据你的需要连续地根据OO进行精炼,你会发现你会及时开始使用结构更少且更多的OO自然



So, you are evolving from your 'strucutured model', to an 'object model'. There's nothing wrong in starting to attack a problem with what you know from a structural perspective, and successively refining it in terms of OO as you need to, and you'll find that in time, you'll start using less structured and more OO naturally


只需一个注释:尽管面向对象和结构化范例不同,但您可以将OO视为结构化范例的扩展。 OO为您提供了结构化模型中缺少的内容(嗯,一个缺少的视图)。你仍然可以获得后者的所有好处。

让我们来看看你的html解析器示例,这对于一个类来说是一个非常好的例子:要创建一个解析器,你需要几个函数和过程,你需要一些变量在这些之间传递信息。如果你不想重新解析整个结构,你需要一个结构来以某种方式存储解析结果。可能会发生您需要同时处理许多html文件。在这种情况下,您需要复制所有变量并注意不要混淆它们。那么为什么不在封闭的实体中封装所需的所有东西,隐藏所有仅内部的方法和变量,并且只展示在需要html解析时应该处理的内容。有关此概念的可能实现,请查看此处:在C#中解析HTML标记 [ ^ ]。

但你最好google一点,阅读一些关于这两种范式比较的文章。
Just a single note: although object oriented and structured paradigms are different, you can see OO as an extension of the structured one. OO gives you what's missing from the structured model (well, one view of what's missing). You still have all benefits of the later.
Let's take your html parser example, which is a really good example for a class: to make a parser, you need several functions and procedures, and you need some variables to pass information between these. And if you don't want to re-parse the structure all over, you need a structure to store the parsing results somehow. And might happen that you need to deal with many html files at once. In this case, you would need to duplicate all variables and take care not to confuse them. So why don't you encapsulate all the thing you need in a closed entity, hide all internal-only methods and variables, and expose only what you should deal with when you need html parsing. For a possible implementation of this concept, look here: Parsing HTML Tags in C#[^].
But you better google a little bit and read some of the many articles written about the comparison of these two paradigms.


这篇关于程序编程(不是OOP)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆