virtual과 관련된 몇 가지 현상에 대해 좀 더 살펴보자.

자바의 경우
자바의 경우 인터페이스를 구현하거나 다른 클래스를 상속할 경우 항상 virtual로 간주되기 때문에 virtual이라는 키워드가 존재않는다. 따라서 원하지 않는 virtual 적인 행위를 방지하기 위해 final이라는 키워드를 사용할 수 있다. 

 클래스의 상속을 막기 위해 final class로 선언할 수 있고
 public final class Babo { ... }

 상속은 허용하되 일부 메소드의 override를 막기 위해 final 메소드로 선언할 수 있다.
 pubilc class Babo
 {
    public final void tellMe() { ... }
  }
   
 참고로 final은 멤버 변수를 상수로 선언하기 위해 사용되기도 하고
 public class Babo
 {
    private final String name = "바보";
 }

 메소드의 파라메터에 로컬 변수로 선언되기도 한다.
 public void tellMe(final String name) { ... }


 닷넷의 경우 (C#의 경우)
 C#의 경우에는 지난 번에 포스팅했듯이 인터페이스의 구현과 클래스간의 상속을 구분한다. 인터페이스의 구현은 polymorphism 성격을 띄지 않기 때문에 자식이 부모의 메소드를 override 할 수 없다. 또한 상속시의 경우에도 자식이 override 할 수 있는 것과 하지 못하게 할 것을 구분하기 위해 virtual 키워드를 쓴다. virtual 이 아닌 부모의 메소드는 override 할 수 없다.
 자바의 경우 처럼, C#에도 override를 방지하는 키워드 sealed가 있다. 즉, sealed 메소드가 있다. 하지만 자바와 조금 다른데, sealed 메소드는 반드시 상속을 받는 자식 클래스가 부모의 virtual 메소드를 override하면서 자신의 자식 클래스, 즉, 손자 클래스가 더 이상 override하지 못하도록 막는 역할을 한다. 반드시 override 하는 상황에서만 사용된다는 특징이 있다. 즉, 항상 sealed는 override와 함께 다닌다.

 조금 다른 얘기인데 재밌는 사실은...
  interface IMsg
  {
    void Message();
  }
  class Parent : IMsg
  {
    public virtual void Message()
    {
      Console.WriteLine("부모가 불렸네.");
    }
  }
  class Child : Parent
  {
    public sealed override void Message()
    {
      Console.WriteLine("자식이 불렸네.");
    }

C#에서 인터페이스 IMsg에 선언되어 있는 메소드 Message()의 IL 코드를 보면 abstract virtual로 자동 선언된다.
  .method public hidebysig newslot abstract virtual instance void  Message() cil managed

이 인터페이스의 메소드를 구현하고 있는 Parent 클래스의 Message() 메소드는 IL에서 virtual final로 선언된다.
  .method public hidebysig newslot virtual final instance void  Message() cil managed

하지만, 이 인터페이스를 구현하면서 해당 메소드에 virtual을 붙이면 Parent 클래스의 Message() 메소드는 IL에서 그냥 virtual로 선언된다.
  .method public hidebysig newslot virtual instance void  Message() cil managed

인터페이스를 구현한 Parent를 상속받은 Child 클래스의 sealed override Message() 메소드는 IL에서 virtual final로 선언된다. 즉, 더이상의 override는 불가하다.
  .method public hidebysig virtual final instance void Message() cil managed

 정리하면, C#에서도(??) 인터페이스의 구현시에 자동 virtual이 선언되나 final이 있기 때문에 virtual적인 형태를 띄지 않아 override가 되지 않는 것으로 추정되며, 구현 클래스에서 명시적으로 virtual을 붙이게 되면 final이 아닌 virtual로 선언되기 때문에 override가 가능하게 되는 것 같다. 또한 위에서 보듯이 이를 상속받은 자식 클래스에서 sealed 메소드로 선언해버리면 다시 vritual fianl이 되어 더 이상의 override는 불가능하다.

자바는 모든 것을 virtual적인 것으로 간주하여 풀고 final을 써서 필요한 부분을 막고, C#의 경우 모든 것을 일단 막고 virtual 키워드를 써서 필요한 부분을 풀고 ... 이런 것인가 ? 

 마이크로소프트 오피스 2007의 기본 문서 포맷은 OOXML (Office Open XML)이며, 현재 ECMA 표준으로 등록되어 있으며 ISO 표준을 위한 절차를 밟고 있다. OOXML과는 다른 표준으로는, 썬 마이크로시스템즈가 인수한 스타오피스의 소스를 공개하여 시작된 Open Office 로 부터 스키마 등을 추출하여 표준화시킨 ODF (Open Document Format)가 있다. 이 두 문서 표준은 기본적으로 각각 표준 XML 스키마가 존재하고 관련된 화일(텍스트, 이미지 등)을 Zip 포맷으로 묶어 단일한 파일로 저장하는 등 비슷한 형태를 취하고 있다. 크게 보면 결국 서로 다른 스키마 사이의 변환이라고 봐도 무방하다. 다만, 여기에 태생적인 특성이 있어 OOXML은 지금껏 만들어진 방대한 분량의 마이크로소프트 오피스 문서 포맷과의 호환성을 가지고 있고, ODF의 경우는 이런 면에서는 그다지 신경을 쓰지 않는 듯하다. 또한 OOXML이 문서를 관장하는 문서 수혜자 즉, 여러 나라 도서관, 애플, 도시바 등이 주축인 반면, ODF는 문서 처리기를 만드는 벤더 위주라는 차이도 있다. 또한 관점의 차이이긴 하나, OOXML이 자체적으로 완벽한 문서 포맷을 추구하는 반면, ODF는 여타 다른 표준에 의존하는 형태를 취하고 있다. 이 두 표준은 각각 ECMA, ISO 표준이라는 즉, 공개 표준이라는 특징을 가지고 있다.

 OOXML은 마이크로소프트 오피스 만이 유일한 구현이라고 잘못 알려져 있으며, 현재 OOXML을 지원하는 제품으로는 몇 가지만 들면, MS Office 2007, Corel Office, Altova XML Spy, PythonOffice, 썬의 스타오피스, 맥용 Neo Office, 리눅스 용 Gnumeric (스프레드쉬트) 등 플랫폼을 막론하고 다수의 제품에서 지원하고 있다. 또한 한글과 컴퓨터 자회사인 ThinkFree 오피스도 OOXML을 지원하기로 하였다.
 근래에 구글과 IBM도 OOXML을 지원하는 것으로 나타났다. 구글에서 검색을 하면 마이크로소프트 오피스 2007의 문서 내용까지도 함께 검색이 되고 이 결과를 온라인에서 보여주는 기능("HTML 버전")에서 마이크로소프트 오피스 2007의 화일까지도 브라우저에서 렌더링이 되는 것으로 나타났다.
 얼마전 IDC가 OOXML에 아주 우호적인 리포트를 발표한 적이 있다. 여기에 대해 ODFA (Open Document Format Alliance) 차원에서 반박문을 발표하기도 하였다. 완전히 동일한 목적을 가지고 동일한 기능을 하는 것이 아닌 서로 다른 배경과 목적을 가진 두 개의 문서 표준에 대해 일반적인 기준으로 비교하는 것이 무리가 있을 수 있으며, 두 문서 표준에 대한 깊은 지식없이는 단편적인 스키마 수준에서의 기능 비교밖에는 이루어질 수 없다. 또한 지속적으로 변하는 두 표준의 스펙에 대해서, 그리고 XML이라는 스키마의 특성상 무한 확장성을 염두해 둔다면 비교가 어쩌면 무의미할 수도 있다. 두 스펙에 관한 비교를 원하는 사람을 위 링크를 참조하기 바란다.

 관련 기사
- http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9058038
- http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=311757&intsrc=news_ts_head
- http://blogs.zdnet.com/microsoft/?p=1121

 닷넷 프로젝트에서 사용할 수 있는 프레임웍을 한눈에 볼 수 있도록 정리해보자
프레임웍을 구분하는 방법은 여러가지이나 간단하게 티어별로 구분하도록 한다.

프리젠테이션 티어 (웹)
1. ASP.NET MVC - 2008년 1사분기에 출시 예정이 ASP.NET 기반의 MVC 프레임웍. 마이크로소프트 제공
   - 소개
   - 다운로드
   - 포럼
2. MonoRail - 오픈 소스 Castle 프로젝트에서 만든 Rail와 유사한 MVC 웹 프로임웍
3. Maverick.NET - 자바 Maverick의 닷넷 버전으로 오픈 소스 MVC 웹 프레임웍, 업데이트 안됨
4. DotNetNuke - 포털 프레임웍에 가까움. 오픈 소스

비지니스 티어 (DI Container)
1. Spring.NET - 오픈 소스. 자바 Spring의 닷넷 버전. 대표적인 DI Container.
2. ObjectBuilder - Enterprise Library(EntLib)에 들어 있으며, EntLib, Composite UI Application Block 등에 사용된 DI Container
3. Windsor Container - 오픈 소스 Castle 프로젝트 일환
4. StructureMap - 닷넷에서 가장 오래된 DI Container. Martin Fowler가 있는 ThoughtWorks에서 프로젝트 진행한 결과물이 정제된 것이라고 함

데이터 티어
1. ADO.NET
2. LINQ to SQL - .NET Framework 3.5의 기본 기능. 엔티티와 테이블의 1:1 매핑. VS2008 툴 지원
3. ADO.NET Entity Framework (LINQ to Entity)
4. NHibernate - 자바 Hibernate의 닷넷 버전. 오픈 소스
5. iBatis.NET - 자바 iBatis의 닷넷 버전. 오픈 소스
6. Active Record - 오픈 소스 Castle 프로젝트의 일환. Active Record 패턴을 구현. NHibernate 기반이나 Configuration을 XML이 아닌 Attribute을 이용
7. LLBLGen Pro - 상용.
8. WilsonORMapper - 상용.
9. LightSpeed - 상용.
10. Codus - 상용.
11. Sooda - 폴란드에서 만든 오픈 소스 ORM 으로 폴란드에서는 구직시 도움되는 기술.
12. SubSonic - 오픈 소스 ORM. ASP.NET 3.5 Extension에 포함된 ASP.NET Dynamic Data 기능 구현에 사용됨. 

기타 범용 프레임웍 (혹은 라이브러리)
1. Enterprise Library - MS patterns and practices(PnP) 팀이 Codeplex를 통해 제공. 캐싱, 로깅, 암호화 등등
2. NVelocity - 템플릿 엔진. 진전이 없어 Castle 프로젝트에서 별도 진행
3. NUnit - 단위 테스트
4. NAnt - 빌드
5. log4net - 로깅
6. CruiseControl.NET - 통합 빌드, ThoughtWorks에서 개발한 오픈 소스

 어제 저녁부터 운행중에 라디오가 꺼지고 시계 글자가 알아보기 힘들 정도로 희미해진 것을 보고 미루어왔던 배터리 교체 시기가 다가왔음을 짐작하고 오늘 배터리 교체하려 했었는데...
 출근 내내 자동차가 이상 신호를 보내왔다.
가장 먼저 희미해진 시계 글자는 당연하였고, 냉각수 온도 게이지가 힘겹게 기준선 이하에 매달려있는게 보였다. 
조금 지나자 ABS 경고등이 들어왔다. 오호, ABS가 전자 어쩌구 하더니 전기공급이 원활치 않으니 문제가 발생할 수 있나보다.. 마치 하나 하나 알아가는 것 마냥 뿌듯하기 까지 했다.
잠시후, Air Bag 경고등이 들어왔다. 오호.. 에어백까지 전기가 부족하면 안되는 구나..
잠시후, 라디오가 제멋 대로 꺼졌다가 약간 전기가 모아 졌나 싶으나 다시 들어오고.. 또 나가고를 반복하고
잠시후, 속도계가 춤을 추더니 0으로 떨어졌다.. 우와 속도계 게이지도 전기 없으니까 이렇구나...
잠시후 눈에 들어온 건 언제부터인지 0를 가리키고 있는 RPM 게이지.. 모든 게이지가 전기 영향을 받네,,, 근데, 기름 탱크 게이지는 수동인가 ?.. 제대로 동작하는거 같네... 이런 생각을 하면서 계속 운전을 했는데,
헉.. 이거 브레이크 작동 안하면 ? 아냐.. 브레이크는 유압식인것으로 언젠가 들었으니... 괜찮을 거야.. 괜찮아... 음.

 그리고 믿는 구석이 하나 있었다. 배터리는 시동 걸때만 필요하고 일단 시동 걸리면 발전이 되니까 시동꺼질일은 없을거라고..이대로 쭉 카센터까지 가는 거야..

신호 대기... 차가 힘없이 재체기를 하더니 시동이 꺼지고 더 이상 움직일 줄을 모른다.
견인차 출동.. 이거 발전기 나갔네.. 헉.. 배터리외에 발전기까지...
카센터 기사... 운전석 등속 조인트도 나갔네.. 저거 보이죠..베어링이 다 보이네..  브레이크 패드로 갈아야하고..엔진 오일 간지도 5000넘은 거 같은데...허거덕..

평소, 때 되면 부품 갈아주어 견인차에 끌려가는 경우가 없었는데.. 오늘 제대로 걸렸다.

카센터 기사의 훈시를 정리하면, 
발전기는 통상 10만 Km 안팎, 15만 Km 정도까지 견딘다고 한다. 울 뷰롱이는 17만을 탔으니.. 갈만했다.
배터리는 통상 2~3년 마다 갈아준다. 이전에 우리 애 돌 전날 갈았으니 2년하고 5일 지났네..갈만했다.

배터리는 시동 걸때만 필요하고 일단 시동이 걸리면 발전기가 전기를 생산하여 전기를 필요로하는 각종 전자 장치에 배전을 하고 남는 전기를 배터리에 다시 보관한다고 한다. 따라서 배터리가 문제가 생기면 시동이 안 걸릴 뿐 가던 차가 꺼지지는 않는다고. 하지만 발전기에 문제가 생기면 전기 생산이 안되므로 전기를 필요로하는 전기 장치에 전기를 줄 수가 없어서 배터리에서 전기를 끌어온다고 ... 만약 배터리에 충전된 양이 목적지 까지 충분하다면 시동이 꺼지지 않겠지만, 오늘 처럼 성능이 시원치 않은 배터리의 경우 전기가 바닥나면 차가 설 수도 있다고... 

10년 경력의 운전 초보 일기