如果你自己写一些东西，无论是练习，解决个人问题，还是只是为了娱乐，偶尔会有公共场地吗？可能？
答案 0 :(得分：31)
让我给你一个比喻 我来自世界上英语不是主要语言的地方。但这对生活中的一切都是必要的 在我青少年时期的平常日子中，我说了一些非常有趣的英语。然后我的爸爸说，“儿子，用英语思考。然后你会得到流利的“
我认为它完全适用于这种情况。
在你的操场上思考，试试best practices。你很快就会意识到什么是最好的。为什么首先需要物业。为什么要这是公开的？为什么我不应该从构造函数中调用虚拟成员？让我尝试使用“new”修饰符进行方法调用。 What happens when I write 10 nested levels of if-then-else and try reading it again after 10 days。为什么我应该使用factory pattern作为一个简单的项目。等等。
然后你 意识到没有在你的脚下射击 ，为什么设计模式是模式......
答案 1 :(得分：10)
我认为如果你之后有意识地抛弃代码，这是合理的。特别是，如果你正在尝试完全不同的东西，那么采取捷径是有道理的。只是不要让它导致跨越“真实”代码的习惯。
答案 2 :(得分：4)
违反一般原则总是“好”！违反原则并非错误，但这是一种权衡。软件生存的时间越长，不编写干净代码的成本就越高。我对此的看法是：如果有疑问，请将其清理干净！
答案 3 :(得分：3)
当然没关系。 这是你的代码，你可以用它做任何你想做的事。就个人而言，我也试图在我的私人代码中坚持良好的做法，只是为了让它成为一种自然习惯，所以我不必考虑它。
答案 4 :(得分：2)
简短的回答是肯定的，如果你认为你通过公开而不是私人访问者获得了很多，那么欢迎你这样做。我认为，一致性是最重要的事情。例如，不要将某些变量直接公开，有些则不公开。如果您打破最佳实践，请全面执行相同的操作。它又回到了权衡之中。几乎没有人遵循许多IEEE规范，关于如何执行和记录软件工程，因为开销太大，而且可能无法管理。对于个人轻量级编程也是如此。做一些快速而又脏的东西是可以的，只是不要习惯它。
答案 5 :(得分：1)
Data Transfer Object design patter：
中可以接受公开成员通常，Transfer Object中的成员被定义为public，因此不需要get和set方法。
答案 6 :(得分：1)
OOP的一个主要优势是扩展和可维护性。通过封装代码，可以隐藏实现。这意味着其他程序员不必了解实现，也无法更改对象的内部状态。如果您的语言不支持属性，那么您最终会得到大量代码，这些代码会使项目变得模糊不清。如果代码不需要由多个程序员处理，那么您就不会生成可重用的组件，并且您是维护程序员，然后以任何方式编写代码都可以完成任务。
为了练习正确的床，女佣是否需要在早上自己铺床？
答案 7 :(得分：0)
旁注：它还取决于语言：
在 Scala 中，根据Uniform Access Principle，客户端读取和写入字段值就像它们是公共可访问的一样，即使在某些情况下它们实际上是在调用方法。该类的维护者可以自由地更改实现，而不必强迫用户进行代码更改。
Scala将字段和方法名称保存在同一名称空间中 许多语言（如Java）将字段和方法名称保存在不同的名称空间中 但是，这些语言不能支持统一访问原则，除非它们在语法或编译器中构建临时支持。
所以真正的问题是：
您正在公开哪些服务（这里有一个公共字段）？
如果服务（获取/设置给定的类型值）对您的API有意义，那么“快捷方式”是合法的。
只要您最终封装该字段，是否正常，因为您为“正确”原因（API和服务公开）制定了快捷方式，而不是“错误”原因（快速临时访问）。
一个好的单元测试（与API的用户一样）可以帮助您检查是否应该直接访问该字段，或者它是否仅对程序中其他类的内部开发有用。
答案 8 :(得分：0)
这是我的看法：
我建议避开公共领域。他们有一种讨厌你的习惯，因为你无法控制它们。 （你在这里找的是 volatility。）此外，如果你决定改变他们的内部实现，你必须触及更多的代码。
然后，这就是重构工具的用途。如果你有一个不错的重构工具，那就不那么困难了。
没有银弹。我不能重复这一点。如果你有工作要做，并且你需要赶时间完成它，那么编写一行代码而不是八行（就像Visual Basic中的情况一样）肯定会更快。
规则被打破了。如果规则不一定适用于您的情况，请不要使用它。设计模式，编码指南，法律和最佳实践不应被视为一种紧身衣，需要您不必要地将代码复杂化到极其复杂且难以理解和维护的程度。不要让某人强迫你进入练习只是因为它不符合你的要求而受欢迎或“标准”。
同样，这是一个主观意见，你的里程可能会有所不同。