Java 设计问题 - 类、函数、访问修饰符
我是 Java 新手。我有一些设计问题。
假设我有一个爬虫应用程序,它执行以下操作: 1. 爬取url并获取其内容 2.解析内容 3. 显示内容
如何决定实现函数还是类? -- 解析器应该是爬虫类的函数,还是应该本身就是一个类,以便其他应用程序也可以使用它? -- 如果它应该是一个类,它应该是 protected 还是 public 类?
您如何决定实现公共类还是受保护类? -- 如果我必须创建一个类来从解析的内容生成统计信息,例如,该类应该受到保护(以便只有爬虫类可以访问它)还是应该公开?
谢谢 罗恩
I am newbie to Java. I have some design questions.
Say I have a crawler application, that does the following:
1. Crawls a url and gets its content
2. Parses the contents
3. Displays the contents
How do you decide between implementing a function or a class?
-- Should the parser be a function of the crawler class, or should it be a class in itself, so it can be used by other applications as well?
-- If it should be a class, should it be protected or public class?How do you decide between implementing a public or protected class?
-- If I had to create a class to generate stats from the parsed contents for eg, should that class be protected (so only the crawler class can access it) or should it be public?
Thanks
Ron
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为Andy的回答非常好。我有一些补充:
如果您相信将来会扩展某个类,您可以将所有
private
方法(如果有)设置为protected
。这样,任何未来的扩展类也可以访问这些。我喜欢这样的规则:方法的长度不应超过无需滚动即可看到其左括号和右括号 (
{ }
) 的长度。如果一个方法比这个长,请尝试将其分成多个方法(根据您的喜好private
、protected
或public
)。这使得代码更具可读性,并且还可以节省代码行数。假设一个方法变得越来越大,您将其分成几个
private
方法。如果这些新方法仅在第一个“母”方法中使用,那么将所有这些方法移动到它自己的类中是有意义的。通过这种方式,您将使原始类变得更小并且更具可读性。此外,您还可以使新类的功能更容易理解,因为它不会与原始类的功能混淆。I think Andy's answer is very good. I have a few additions:
If you believe that a class will be extended in the future, you can set all your
private
methods (if any) toprotected
. In this way, any future extending classes can also access these.I like the rule that a method shouldn't be longer than that you can see its opening and closing brackets (
{ }
) without scrolling. If a method is longer than that, try to split it up into several methods (private
,protected
orpublic
by your preference). This makes code more readable, and could also save on lines of code.So let's say a method is getting big and you split it up into several
private
methods. If these new methods are only used within the first "mother"-method, it makes sense to move all of that into a class of its own. In this way you will make the original class smaller and more readable. In addition, you will make the functionality of the new class easier to understand, as it is not mixed up with that of the original class.我见过的针对此类问题的最佳指南是“OO 设计的坚实原则”。
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
其中最基本的原则回答你第一个问题的就是“单一责任原则”。这表明,“一个类应该有一个且只有一个改变的理由。”换句话说,您的每个类都应该只做一件事。如果您最终需要更改某件事的工作方式,则只需更改一个类,并且希望在该类中只有一个地方可以进行更改。在您的情况下,您可能希望一个类从 URL 检索内容,另一个类将其解析为某种内存中的数据结构,另一个类来处理数据(如果需要),以及另一个类(或类)以您需要的任何格式显示内容。显然,您可能会被类冲昏头脑,但测试许多小型的、单操作的类通常比测试一两个大型的、包罗万象的类更容易。
关于公共与受保护的问题取决于您计划如何使用此代码。如果您的类可以在库之外独立使用,您可以考虑将其公开,但如果它完成某些特定或与其他类相关的任务,则它可能会受到保护。例如,从 URL 检索内容的类是一个很好的通用类,因此您可以将其公开,但是执行某些特定类型的数据操作的类在您的库之外可能没有用处,因此可以将其公开受保护。总的来说,事情并不总是非黑即白,但最终,无论哪种方式通常都没什么大不了的。
The best guidance I've seen for these types of questions is the "SOLID Principles of OO Design."
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
The most basic of these principles, and the one that sort of answers your first question is the "Single Responsibility Principle." This states that, "a class should have one, and only one, reason to change." In other words, your classes should each do exactly one thing. If you end up needing to change how that one thing works, you only have one class to change, and hopefully just one place to make the change within that class. In your case, you would probably want a class to retrieve the content from the URL, another class to parse it into some sort of in-memory data structure, another class to process the data (if needed), and yet another class (or classes) to display the content in whatever format you need. Obviously, you can get carried away with classes, but it's typically easier to test a lot of small, single-operation classes, as opposed to one or two large, all-encompassing classes.
The question on public vs. protected depends on how you plan to use this code. If your class could be used independently outside your library, you could think about making it public, but if it accomplishes some task which is specific or tied to your other classes, it could probably be protected. For example, a class to retrieve content from a URL is a good general-purpose class, so you could make it public, but a class that does some specific type of manipulation of data might not be useful outside your library, so it can be protected. Overall, it's not always black and white, but ultimately, it's usually not a huge deal either way.
我喜欢将类视为可以做特定事情“方法”的“人”。
在你的例子中,如果你告诉他哪个网址,他就可以获取网址的内容。
还有另一个人,他非常擅长解析内容。我认为他是用一种叫做罗马的工具做到这一点的,但我不确定。他将其保密(提示;))
然后我们就有了第三个人,他展示了一些东西。他有点弱智,只能理解“另一个人”生产的东西,但嘿,没关系。
最后,该项目需要一个老板,他向其他 3 个人发号施令,并在他们之间传递消息。
ps:我从来没有真正考虑过让类受到保护或不受保护。通常它们只是公开的,没有任何具体原因。只要不痛,又何苦呢?
I like to think of classes as "guys" who can do specific stuff "methods".
In your case, theres a guy who can fetch the content of an url if you tell him which url that is.
Then there is this another guy, that is really good at parsing content. I think he does that with a tool called rome, but i'm not sure. he keeps that private (hint ;) )
Then we have that third guy, who displays stuff. He's a bit retarded and only understands stuff that "another guy" produces, but hey thats fine.
Finally the project needs a boss guy, who gives orders to the other 3 guys and passes messages between them.
ps: I never really though about making classes protected or not. Usually they are simply public without any specific reason. As long as it don't hurt, why bother?