分析規劃~是一門學問！

無論任何一門專業知識~都離不開分析和規劃~

例如~學習資訊這門學問，在編寫程式時，可以執行的程式未必“漂亮”的~
至於程式內部，使用者當然不懂嘞，就只有程式師瞭解。

編寫程式時，如果是一組程式師一起編寫的話，講求的是團隊精神~
需要良好的分析，規劃才可以開始分工去編寫程式~

缺了良好的分析和規劃，結果就會像“一條大橋，從河岸兩端開始建立，建到中間時才發現，原來是接不上去的”~

當然如果程式是個人開發而已~可以不用太在意~
要怎麼寫，隨個人習慣和喜歡。
但是如果缺了良好的程序~會影響到日後的維護工作~

什麽叫做維護呢？
維護就是對已經編寫好的程式，做修改，去蟲等。
好的程序會大大提升日後的維護工作~

如果在一支程式中，要修改一些東西，改的行數越少，也可以代表此程式是好的~
所以除了會寫還不厲害~還要會分析及規劃問題~
有興趣著可以找找關於“軟體工程"的書籍來閱讀

来自jess 私有blogger 

Thursday, 8 September 2011

如果看不懂

如果看不懂就不在繼續看~放棄就很可惜了~
要相信只要不放棄地看，不放棄地學，中有一日一定懂的！

看不懂就放棄之前所花費的時間不就是白“花”的嗎？
決定了無論如何就該走下去~
要怎樣的生活是自己選的~自己可以決定自己的人生，可以把握自己的時間~

人生有時候的矛盾是正常的~
那天看見給創業者提個醒，不要癡迷于從閱讀成功人士的傳記中找經驗，這些書大部分都經過了精緻的包裝，很多重要的事實都不會告訴你。

例如，比爾蓋茨的書不會告訴你他母親是ＩＢＭ董事，是她給兒子促成了第一筆大生意；巴菲特的書只會告訴你，他８歲就知道去參觀紐交所，但不會告訴你，是他當國會議員的父親帶他去的，而且是高盛的董事接待的。

這才是很多事情的真相！！}

哈哈，的確有意思~

来自jess 私有blogger ~

Monday, 5 September 2011

類別圖介紹 (UML)

在開始學習設計模式（Design Pattern）之前，應該先學會看類別圖吧，類別圖在（軟體業）是常見的東西，可以讓團隊開發容易溝通，理解。

這文章主要的只是介紹一些基本的。

一個類別圖分成三層，

第一層代表類別名字，

第二層代表（屬性,欄位），

第三層代表（方法，行為）。

前面的符號代表 + （Public），- （Private） ，# （Protected），

這幾個是常用的，當然還有一些其他的，當遇到時不懂再自行找找吧！

斜字體 （Italic Type）類別名稱 - 代表抽象類別（Abstract Class）。

（空心三角形+實線） 代表 繼承（Inheritance）。

基本的大約就這樣子吧！當然還有好多如組合， 聚合，關聯，介面，實現 等。

也看看 設計模式介紹（Design Pattern） 
物件導向 概念（Object-Oriented Concept ） 

设计模式 （Design Pattern） 介绍&读后感

开始对设计模式（design pattern）理解更多了，也重复地阅读之前所读过的书籍，如框架设计，GOF Pattern  。也许之前在台湾时阅读这类书本时，根本就不理解设计模式是该怎么使用，用处在哪？

我第一次阅读设计模式的感觉？！
什么是设计模式啊（怎么软体工程需要学设计模式）？
何时应该使用设计模式？
怎么好好很直接的程式需要绕一圈来写？这就是所谓的模式吗？
因为设计而设计？这样对吗？

最近翻回之前所购买的书，感觉对设计模式（design pattern）领悟得更多，也许程式员就不能因为阅读而阅读吧！当有使用到时，再翻阅回去会感觉领悟更多。

现在就开始回顾设计模式的历史叻！其实设计模式是为了解决软件开发,更改的复杂度降低，
经过之前开发人员的经历，他们把一些常见的问题给设上模式，以让程式开发的错误降到最低（希望将软件业工程化）。当然也不是100% 工程化，开发人员常见的问题就是客户想改变这些问题，所以也只能接受改变，而让客户的改变可以容易地套上之前所编写设计的系统。

设计模式基本上可被分为3大类
创建型模式(Creational Pattern) ：解决物件创建的问题
                                                           （Solution for （new） Object）
结构型型模式（Structural Pattern）:处理类和物件间的组合
                                                      （Identifying a simple way to realize relationships between entities）
行为型模式 （Behavioral Pattern）：类和物件交互的责任分配
                                                        （Common communication patterns between objects and realize）

少和模式接触当然就不可能牢记23种模式，个人觉得重点还是理解过程。

设计原则(Design Principle) 
1、"开－闭"原则——模块应对扩展开放，而对修改关闭。
2、里氏代换原则——如果调用的是父类的话，那么换成子类也完全可以运行。里氏代换原则是  继承复用的一个基础。
3、合成复用原则——要少用继承，多用合成关系来实现。
4、依赖倒转原则——抽象不应该依赖与细节，细节应当依赖与抽象。
                   要针对接口编程，而不是针对实现编程。
5、接口隔离原则——每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。
6、抽象类
7、迪米特法则——最少知识原则。不要和陌生人说话。  

好好地理解这些设计原则，就可以很自然地思考在编写程式时使用适当的模式。

续。。。 应该先介绍UML （类别图）吧~

参考文献 
http://baike.baidu.com/view/66964.htm 
《Head First Design Pattern》

Linq 发音（link）~到底是什么？

自从毕业后，都在编写一些小小的系统，一起毕业的同学也不例外！
一些同学编写php，apx.net ，由于有时和同学会见面，见面时都会讨论到最近在公司编写什么系统，使用什么语言，工具，等。当中发现了很多人都混乱在威力强大的工具，例如VS IDE ，第三方库如Telerik等~这些威力强大的东东的出现是好或坏？软件业上尤其是在发商业软体的都会使用框架（Framework），许多刚毕业入软体业的同学都知道框架可以帮助快速达到目的，缺混乱在框架当中。为什么会发生这样的混乱？大多数都是因为在学校都没真真理解到低阶语言例如C,C++，因为高阶语言都是由低阶语言包装以方便程式开发人员不用顾虑太多底层的东西如记忆体方面等等。请别忘记多强大的高阶语言到最后还是会转到机器语言以跟机器沟通~所以高阶语言的出现是让开发人员加速开发时间，而避免考虑太多底层的运作。

linq是什么呢？才发现我朋友竟然会把linq ,ado.net,entity framework 概念给混乱了，
ado.net , entity framework（ORM） 其实只是资料库存取技術，linq 其实就是.net 高阶语言当中可以对物件用似sql 语法去对物件取得资料，别忘了c#（ Everything is an object），例如说，entity return 回一个object 所以就可以使用linq 对物件取出需要的资料。
简单的linq例子：

using System;

using System.Linq;

class linqtest
{
    static void Main()
    {    //宣告一个阵列
 int[] arr = { 1, 2, 3, 6, 7, 8 };
 
 var elements = from element in arr
         orderby element descending
         where element > 2
         select element;
 
 foreach (var element in elements)
 {
     Console.Write(element);
     Console.Write(' ');
 }
 Console.WriteLine();
    }
}

然後再閱讀所需 LINQ 技術的文件：

• SQL Server 資料庫：LINQ to SQL
  
• XML 文件：LINQ to XML
  
• ADO.NET Dataset：LINQ to DataSet
  
• .NET 集合、檔案、字串等等：LINQ to Objects
  
  基本概念有了吧？再看看文件吧，这样应该会比较容易吸收。