여행하는 개발자

<객체와 클래스> <객체> 상태와 행동을 갖는다 프로그램에서 객체는 소프트웨어 객체로서 상태(변수)와 행동(메쏘드)를 갖는다 객체는 클래스로부터 생성된다 객체의 생성은  클래스의 인스턴스 생성과 같은 의미이다 객체의 초기화는 클래스의 생성자를 사용한다 객체가 속한 클래스가 그 객체의 자료형이다 객체 사용의 의미 객체의 변수를 읽거나 쓴다 객체의 메쏘드를 호출한다(객체에게 메시지를 보낸다) 객체와 클래스는 사실 의미가 다르지만 객체는 실세계 객체의 전자공학적 모델이어서 쉽게 구분이 가지 않는다  종종 객체를 클래스와 인스턴스 모두의 의미로 사용된다 자전거 - 객체,  자전거를 만드는 설계도 - 클래스 동일한 설계도로 많은 자전거를 만들 수 있다 <class> 객체를 생성하는 설계도이다 선언 class Name [extends Super] [implements Interface [,Interface, ...]] {몸체} 클래스명에 알파벳, _, $을 사용한다.   관례적으로 대문자를 사용한다 상위 클래스명이 없을 경우 자동적으로 Object 클래스가 상위 클래스가 된다 하나의 파일 안에 여러 개의 클래스를 정의할 때 단지 한 개의 클래스에만 public 접근 변경자를 붙여야 한다  응용 프로그램 클래스와 애플릿 클래스  응용 프로그램 클래스는 main 메쏘드가 있으며 아래와 같이 고정된 형식으로 쓰인다 public  static  void  main (String a...

Java Development Framework 1. Development Framework의 필요성 예를 들어 각종 자동차 부품과 냉장고 부품이 전부 분해되어 바닥에 즐비하게 서로 섞여 있는 모습을 상상해 보겠습니다. 수많은 볼트와 넛트, 게스킷, 파이프, 심지어 팬치와 드라이버까지 마구 섞여 있습니다. 이러한 부품과 연장을 이용하여 우리가 만들려는 것은 청색의 카렌스입니다. 물론 완전히 분해된 부품들을 하나하나 조립해서 청색의 카렌스를 만들어 낼 수는 있습니다. 상당한 시간이 걸리겠죠. 카렌스를 만드는 데는 전혀 쓸모없는 냉장고 부품은 걷어내고, 엔진조립부터 시작하여 패인트칠까지 하다 보면, 갖가지 일이 발생합니다. 엔진의 성능을 높이위해 이렇게도 해보고 저렇게도 해보고, 그러다 보면 납기는 가까이 오고 결국 카렌스를 만들지 못하고 '티코'를 만들고 있는 자신의 모습을 보게 됩니다. 그러나, 엔진과 기어변속장치, 동력전달장치 등 각종 단위 부품을 미리 조립해 둔 반제품을 이용한다면 최종적으로 카렌스를 만드는 기간은 엄청나게 빨리 끝낼 수 있겠지요. 완제품을 만드는 사람은 엔진구조공학은 모르지만 단지 최종적인 조립을 위한 최소한의 '조립공정'과 기술만 보유하고 있으면 됩니다. 카렌스가 SI 프로젝트를 통해 완성시켜야 할 최종적인 시스템에 비유한다면, 각종 부품들은 API(Application Programming Interface)에 해당될 수 있습니다. 물론 지금의 SI프로젝트가 직면한 문제가 위에서 예를 든 것과 비슷한 상황인가란 질문에는 의견이 분분...

package kr.co.lecture.socket; import java.io.BufferedReader; import java.io.File; import java.io.FileReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.OutputStream; import java.io.PrintWriter; import java.net.ServerSocket; import java.net.Socket; public class SocketServer { /** * @param args * @throws IOException */ public static void main(String[] args) throws IOException { //서버 포트 예약 ServerSocket serverSocket = new ServerSocket(9090); //클라이언트 접속 대기 Socket clientSocket = serverSocket.accept(); //클라이언트 전송 데이터 수신 스트림 InputStream clientIs = clientSocket.getInputStream(); InputStreamReader isr = new InputStreamReader(clientIs); BufferedReader br = new BufferedReader(isr); ...

자바에서 파일 쓰기 할 때 BufferedWriter file = new BufferedWriter(new FileWriter("filename")); 대개의 경우 이런식으로 코딩을 했었는데, 이 코드는 파일을 덮어쓴다. 파일을 덮어쓰지 않고 이어쓰기하는 방법이 없을까 하고 고민하고 찾아봤다. RandomAccessFile 클래스를 사용하는 방법도 있었고 그리고 파일을 쭉 읽어서 변수에 저장을 한 뒤 새로 추가할 내용을 덧붙여서 파일에 쓰는 방법도 있었다. 하지만 뭔가 더 간편한게 있을 것 같아서 찾아봤더니 이 한문장이면 파일 이어쓰기가 가능하다.         BufferedWriter file = new BufferedWriter(new FileWriter("filename", true)); 이 코드는 파일이 없으면 새로 만들고 있다면 덮어쓰지 않고 이어서 쓰게한다. 그리고 파일에서 개행문자를 쓰려고할 때 C나 C++에서처럼 당연히 ""이 먹힐거라 생각을 하고 str = str + ""; file.write(str, 0, str.length()); 이렇게 썼는데 파일에는 줄바꿈이 되어있지 않았다. 알아본 결과 저 위에서 사용한 FileWriter가 가독성때문에 ""을 지원하지 않기 때문이었다. BufferedWriter를 통해서 개행문자를 쓸 수 있다. 바로 이렇게.. file.write(str, 0, str.length()); file.newLine(); 간단하다. 하하하;;; 이 사실을 난... 어제 알았다. 쿨럭 -_-;;; 까먹을까봐... ...

java.io.File의 경로를 얻어오는 방법은 여러 가지가 있다. 우선 getPath()는 File 객체를 생성할 때 넣어준 경로를 그대로 반환한다. 그리고 getAbsolutePath()와 getCanonicalPath는 getPath()와는 달리 프로그램을 실행시킨 위치 정보도 함께 반환해 준다. File file = new File("src", "test"); System.out.println("getPath: " + file.getPath()); System.out.println("getAbsolutePath: " + file.getAbsolutePath()); System.out.println("getCanonicalPath: " + file.getCanonicalPath()); 실행해보면?? getPath()는 src/test 그대로 반환한 반면, getAbsolutePath()와 getCanonicalPath()는 현재 프로그램을 실행한 경로(D:\workspace\Test)를 포함하고 있다. getPath: src\test getAbsolutePath: D:\workspace\Test\src\test getCanonicalPath: D:\workspace\Test\src\test 어라?? 그런데.. absolute path와 canonical path는 결과가 같은데 대체 왜.. 구분해서 메소드를 제공하는 걸까?? 그건 현재 경로(".")나 상위 경로("..")를 함께 사용하면 차이를 알 수 있다. File file = new File("../../workspace");...

mkdirs() 라는 메서드(함수)로, 디렉토리(폴더)를 만들 수 있습니다. mkdirs() 는 디렉토리 생성에 성공하면 true 를 반환하기에, 실패시 에러를 출력하려면 if문 속에서 느낌표를 붙여, 논리값을 반전시켜 주어야 합니다. 같은 이름의 디렉토리가 이미 있을 때나 디렉토리명에 허용되지 않는 문자(*, ? 등)가 있을 때 에는 아래 예제의 경우, "디렉토리 생성 실패"라는 메시지가 출력됩니다. 여러 개의 중첩된 폴더를 한꺼번에 생성하려면 슬래시(/) 기호로 패스를 구분해 줍니다. mkdir() 이라는 단수형 이름의 메소드로도 디렉토리를 만들 수 있지만, 여러개를 한꺼번에 만들 수는 없습니다. 디렉토리 만들기 예제 소스 파일명: Example.java import java.io.*; public class Example { public static void main(String[] args) { // MY_TEST_DIR 이라는 하위 폴더 만들기 File f = new File("MY_TEST_DIR"); if (!f.mkdirs()) System.err.println("디렉토리 생성 실패"); // MY_TEST_DIR 이라는 하위 폴더 밑에 // 333 이라는 하위 폴더 또 만들기 // 즉, MY_TEST_DIR/333 이렇게 중첩된 폴더 한꺼번에 생성 f = new File("MY_TEST_DIR/333"); if (!f.mkdirs()) System.err.println("디렉토리 생성 실패"); }...

mysql>use mysql; mysql>update user set password=PASSWORD("여기다비번입력")where User='root'; mysql>flush privileges; mysql>quit; mysql>mysql -u root -p

며칠전에 어느 대학교 4학년 분에게 메일 한통을 받았습니다. 그 분은 소프트웨어 아키텍트(Software Architect)를 꿈꾸시는 분이셨습니다. :-) 참 멋진 생각을 하고 계신것 같습니다. 소프트웨어 아키텍트라는 본인의 꿈을 이루기 위하여 조언을 구하시는 그분의 모습을 보면서 이러한 노력들이 나중에 훌륭한 소프트웨어 아키텍트로 성장하실 수 있는 좋은 밑바탕이 될 것이라고 생각하였습니다. 사실 저는 아직 큰 규모의 소프트웨어 프로젝트에서 소프트웨어 아키텍트로 많은 일은 하지 못하였습니다. 다만 제가 맡은 프로젝트나 아니면 중급규모의 회사의 프로젝트에서 나름 소프트웨어 아키텍트라는 역활을 수행하곤 하였습니다. 아울러 소프트웨어 아키텍트가 되기 위한 정식적인 교육을 받은 적은 없습니다. 따라서 그 분에게 제가 조언한 것은 소프트웨어 아키텍트가 되기 위한 정식적인 코스나 아니면 알아야할 지식들이 아니었습니다. 제 생각에 소프트웨어 아키텍트처럼 많은 것들을 알아야하는 직업은 없는 듯합니다. 소프트웨어 아키텍트는 고객에게는 소프트웨어 전체를 책임지는 책임자이자 컨설턴트입니다. 개발팀에게 있어 소프트웨어 아키텍트는 전반적인 구현 기술과 일정 및 인력을 책임지는 총괄 책임자입니다. 기업입장에서 소프트웨어 아키텍트는 정해진 예산과 일정 범위안에서 소프트웨어를 훌륭하게 구축하여 기업의 이익을 만들어내야 하는 책임이 있습니다. 사실 이렇게 본다면 소프트웨어 아키텍트는 알아야할 것도 많고 책임도 많은 그야 말로 슈퍼맨과 같은 존재가 아닌가 생각됩니다. 특히 우리나라의 소프트웨어...

Convention over Configuration(CoC) 우리나라에서는 일부 "설정 이상의 관례", "설정보다 관례", "설정을 넘은 관례" 혹은 "설정보다 규범" 등으로 번역하고 있는 Convention over Configuration는 최근 국내에서 CoC로 번역이 통일되어 가고 있는 것 같습니다. 저 역시 CoC를 어떻게 번역할까 많은 고민을 하였으며, 지인들에게도 물어보기도 하였는데, 우리나라에서 사실상의 표준(De-facto)로 CoC로 자리잡혀 가고 있는것 같으며, 저 역시 애매한 번역보다는 CoC가 표기 및 의미 면에서 독자들에게 더 쉽게 이해될 것으로 생각되어 CoC로 번역하기로 결정하였습니다. CoC의 모습이 마치 이모티콘 같아서 쉽게 기억될 것 같습니다. :-) Convention over Configuration(이하 CoC)는  Coding by Configuration이라고도 알려져 있습니다. 항상 개념이란것이 그러하듯이 CoC 개념 자체는 매우 단순합니다. CoC는 개발자가 내려야할 수 많은 결정들(decisions)을 줄여주어, 단순성(simplicity)을 확보하면서, 유연성(flexibility)을 잃어버리지 않도록 하기 위한 소프트웨어 디자인 패러다임 입니다. CoC의 단어상의 근본적인 의미는 개발자는 단지 어플리케이션에서 관습적이지않은 면(unconventional aspects of the application)만 정의할 필요가 있다는 것입니다. 예를들어 Model에 Sale이란 클래스가 있다면, 데이터베이스 내에 대응하는 테이블은 ...

항상 고민했던 부분이 소프트웨어(Software)란 무었인가?라는 물음이었습니다. 정말 어려운 이 문제에 관심을 가지는 이유는 제가 소프트웨어를 좋아하고 좋은 소프트웨어를 만들어 내고 싶기 때문입니다. 출처: http://www.gnu.org/philosophy/compromise.html 즉 소프트웨어에 대한 제 자신만의 생각을 명확하게 가지고 있어야, 삶을 위한 소프트웨어에 대한 구체적인 생각을 정리할 수 있다고 생각하고 있기 때문입니다. 따라서 저는 항상 소프트웨어란 무었인가?(What is the software?)란 질문을 스스로에게 던지곤 하였습니다. 많은 문헌들과 인터넷에서도 수 많은 소프트웨어의 정의가 있습니다. 하지만 대부분 소프트웨어의 분류를 정하고 각 분류별로 소프트웨어의 특징을 설명하여 정의하거나, 아니면 소프트웨어 개발 방법론 차원에서 소프트웨어를 바라보고 있습니다. 물론 이러한 정의 역시 틀린 것은 아닙니다. 하지만 소프트웨어는 그렇게 쉽게 정의할 수 있는 것이 아니란느 생각이 많이 듭니다. 여러분들은 소프트웨어가 무었이라고 생각하시나요 :-) 한때는 소프트웨어를 생명체과 같다고 생각하기도 하였습니다. 마치 살아있는 동물과 같은 생명체 말이죠 ;-) 현재 저와 여러분들은 모두 소프트웨어를 통하여 제가 쓴 글을 보고 계십니다. 마치 생명체가 다른 생명체에게 이야기를 하듯이요~ 제가 쓴 글은 웹 어플리케이션 서버(WAS)라는 생명체에게 전달되고 이 글은 다시 DBMS라는 생명체에 전달됩니다. 그리고 DBMS는 제 글을 잘 보관하고 ...