实用类和Facade Pattern的例子 [英] Utility Class and example of Facade Pattern

问题描述

我读到了Facade模式，并相信它通过提供一种更简单，更简洁的方式来隐藏子系统的复杂性。



如果我创建一个实用程序类DateUtility用于管理与日期相关的活动，例如它可以使用GetDateFormatDDMMYYY，CompareDate等方法。所有与日期相关的实用程序方法都是静态的。



将此类DateUtilityqualify为作为Facade Pattern的一个例子，因为我正在创建一个用于管理日期的子系统。



我正在使用.NET。



回应将受到高度赞赏。



谢谢。



问候，

Sakshi

I read about Facade pattern and believe that it hides the complexity of a subsystem by offering a simpler and more concise way to access it.

If I create a utility class DateUtility to manage date related activities like it can have methods like GetDateFormatDDMMYYY, CompareDate etc..all date related utility methods which are static.

Will this class DateUtilityqualify to be an example of Facade Pattern as I am creating a sub system for managing dates.

I am using .NET.

Responses will be highly appreciated.

Thanks.

Regards,
Sakshi

推荐答案

请参阅问题的评论，特别是Richard MacCutchan的好主意。不，这不是立面图案的例子。实用工具类是实用工具类。我害怕过于通用，但我认为没有一个实用程序类可以代表一个外观模式。



嗯，关于设计模式......它甚至很尴尬讨论的主题，但......嗯，这些模式很好理解和了解，至少是大多数已知的模式。但是......你明白有事物的名字和背后的一些普遍概念吗？来想一想，如果你完全理解它们并了解它们的价值和缺点，那么你谈论某些技巧的方式就不同了，最重要的是，它们与你所拥有的目标之间的关系有何限制？你需要先考虑事物的内在本质，然后才能将它们分类为明确定义或众所周知的类别。这样的分类对于某些现实元素来说可能过于粗糙，或者只是缺失，但它并没有把事情的本质置于疑问之内。



我想如果你读到的话模式文章中的批评部分，它可能很有用： http://en.wikipedia.org/wiki/Software_design_pattern#批评 [ ^ ]。



此外，请参阅有关此问题和我的答案的讨论：软件设计困境 [ ^ ]。



部分讨论专注于评论中的设计模式。我想，有一些有趣且有用的想法。请参阅。



此外，我想重申，理解，识别和检测反模式更为重要。请参阅： http://en.wikipedia.org/wiki/Anti-pattern ...

-SA

Please see the comments to the question, especially good ideas conducted by Richard MacCutchan. No, this is not the example of the facade pattern. Utility class is a utility class. I'm afraid to be too generic, but I would think that none of the utility classes can represent a facade pattern.

Well, about design patterns… it's even awkward topic for discussion but… Well, the patterns are good to understand and know, at least most known ones. But… do you understand that there are names of things and some universal notions behind them? Come to think about, that's the difference how you talk about some techniques, if you perfectly understand them and know their values and drawbacks, and, most importantly, their limitations in relations to the goals you have? You need to think about inner essence of things first and only then about classification of them into well-defined or well-known category. Such classification can be too rough for some elements of reality or simply missing, but it does not put the essence of things under question.

And I think if you read about "Criticism" section in the pattern article, it can be useful: http://en.wikipedia.org/wiki/Software_design_pattern#Criticism[^].

Also, please see the discussion over this question and my answer: Software Design Dilemma[^].

Part of the discussion is devoted to design patterns, in the comment. There are some interesting and useful thoughts, I think. Please see.

Also, I want to reiterate that it's more important to understand, identify and detect anti-patterns. Please see: http://en.wikipedia.org/wiki/Anti-pattern...

—SA

这篇关于实用类和Facade Pattern的例子的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！