새로운 방식의 강의가 업데이트 되고 있습니다.

안녕하세요. 강요천입니다.

예전에 공지해 드린 대로 강의장에서 녹화되는 강좌를 추가하고 있습니다.

강의 작업은 매주 토요일에 녹화가 되고 있습니다.


chap12 이후의 모든 강의는
강의장에서 녹화되는 방식으로 우선 진행 됩니다.

상속과 인터페이스는 워낙 중요하고
어렵기 때문에
한 번이라도 다시 정리해 드리는 것이 좋다고 생각하여
다시 녹화를 하여서 강의실에 업데이트 됩니다.

2월 20일 현재 새로 갱신된 강의는 다음과 같습니다.

chap 7. 객체지향 패러다임
chap 10. 상속
chap 11. 인터페이스
chap 12. 문자열

강의가 고르지 못한 점 죄송합니다.
하지만 지난번 공지해 드린 것처럼 항상 여러분들이 더 좋은 자료를 얻으실 수 있도록
노력하고 있으니
많은 시행착오가 있더라도 너그러이 양해해 주시면 감사하겠습니다.

이제 또 저는 다음 약속처럼
추가적인 원고를 제작하려고 합니다.

객체중심Java 원고를 만들면서 몇 가지 제 스스로 약속한 것이 있습니다.
* 하나의 평가라도 공정한 평가를 받겠다.
* 공부하는 사람들이 계속해서 도움을 받을 수 있는 책을 만들겠다.
* 공부하고 싶은데 현실적으로 제약이 많은 사람들에게 도움이 되겠다.

앞으로도 많은 시행착오와 변경이 있겠지만
위의 세 가지 사항은 제 스스로의 자존심입니다.

부디 고르지 못한 강의에 언짢아 하지 마시고..
앞으로 더 노력하겠습니다.
감사합니다.

안드로이드 지도 프로그래밍 자료 올립니다.

안드로이드를 이용하는 지도 프로그램 만드는 부분

추가 원고로 제공용으로 만든 것입니다.

주요 내용은 다음과 같습니다.

- Activity에 지도 보이는 설정 및 예제 만드는 요령
- Location Manager를 이용해서 자신의 위치를 파악하는 방법
- 지도 상에서 원하는 좌표로 이동하기

- Overlay를 이용해서 지도위에 마커 표시하기
- 일반 Overlay와 ItemizedOverlay의 차이 및 사용법
- 지도 상의 주소 데이터 얻기, 주소 데이터 변환하기

안드로이드지도프로그래밍자료얻기


- 파일 용량이 4M정도인데 Google 문서로 열면 조금 로딩 속도가 걸리네요..

- 다운로드 받으실 분들은 Freelec 출판사의 강의실에서 다운로드 받으실 수 있습니다.

헥...헥

보통 겨울이 끝날때 쯤이면 한번씩
몸이 쳐지곤 하는데..

이번 겨울은 유난히 춥고, 바빠서 그랬는지..
좀 심하네요,,

게다가 치아도 망가져 있고. 귀도 망가져 있고..

이거 완전히 사고난 중고차 같네요..

2월말까지 해야하 일들이 많네요..

우선 PPT자료 완성해서 출판사에 보내줘야 하고..

공개 강의 녹화해야 하고..

지금 운영하는 고급반도 신경써야 하고.. 지난 기수 프로젝트도 봐야하고...

이래저래 하는 거 없이 치여서 사네요..

2월 지나면 좀 많이 블로깅 할 예정이구요..

현재 강의하는 내용들도 많이 정리해서 올리도록 하겠습니다.

clone( ) 방식 - 깊은 복사/ 얕은 복사- deep copy shallow copy

사실 예전의 자바가 속도가 좋지 않았다는 사실은 누구나 공감하는 사실이다. Hotspot VM 이 나온 이유역시 이러한 데에서 비롯되었고..

자바가 느린 이유중에 하나는 역시 객체 생성이다. 메모리에 새로운 공간을 할당하고 거기에 데이터를 넣는 방식의 처리는 OOP에서는 피해갈 수 없지만 또한 이때문에 발생하는 성능의 저하는 어쩔 수 없다.

결국 OOP는 속도를 개선하기 위해서 다양한 방법을 시도했는데.. 대표적인 것들이 바로 pooling, caching기법, clone기법이라고 할 수 있다.

Cloneable 인터페이스를 이용하면 우리는 객체를 손쉽게 복사할 수 있다. 객체 생성을 해서 넣는 과정을 생략하고도 원본에 대한 또 다른 객체를 만들 수 있다. clone의 스펙을 보면 equals()가 반드시 true여야 한다는 보장은 하지 않아도 되기 때문에 복사본 객체가 아니라 데이터의 카피로도 사용할 수 있다는 얘기이다.

Shallow Copy

간단히 말하면 객체를 복사하는데 그 안의 내용물 마저 복사하지는 않는다는 얘기이다.

public class Origin implements Cloneable
{

 private String id;

 private String pw;

 private SubOrigin sub;
 ...

위와 같은 객체를 복사한다고 가정하자.

  Origin origin = new Origin();


  Origin cloneObj = (Origin) origin.clone();


위의 객체를 System.out.println()으로 보면 두 객체는 다른 주소값을 사용한다. 하지만 문제는 SubOrigin 에 있다.

ShallowCopy는 특정 객체를 복사할 때 피상적인 복사만 하게 된다.

ShallowCopy는 복사본 객체안에 있는 sub의 주소값이 원복 객체의 sub의 주소값과 동일하게 나온다.

이렇게 표면만 복사하는 것을 Shallow Copy라 하고, sub와 같은 하위 객체마저도 복사하는 방식을 deep copy라고 한다.


 protected Object clone(){
  try {
   //shallow copy
   //return super.clone();
   Origin cloneObj = (Origin)super.clone();
   cloneObj.setSub((SubOrigin)this.sub.clone());
  
   return cloneObj;
  
  } catch (CloneNotSupportedException e) {
   e.printStackTrace();
  }
  return null;
 }

위에 있는 소스를 보면 현재 객체의 복사본을 만든후에 하위 객체의 복사본을 만들어 주입하는 방식으로 작성한다.

Android에서 Context의 개념

 사실 Android쪽 프로그램을 만들다 보면 계속해서 이 Context라는 용어에 마주하게 됩니다. Context라는 클래스가 존재하기도 하고, Context라는 용어가 존재하기도 하기 때문에 여러분이 개념을 잡는 수준에 설명해 볼까 합니다.

개인적으로 Android를 공부하기 전에 Web Programming이나 Framework들을 공부할 필요가 있다고 생각하는데, 그 이유 중에 하나가 바로 이 Context라는 개념 때문입니다. 아니면 운영체제를 공부해 보신 분들에게는 Context라는 개념이 그리 낯선 개념은 아닙니다.

 Context를 한국말로 번역하자면 '문맥'이라는 우스운 말이 됩니다만, 디자인 패턴과 같은 곳에서는 '상황, 정황'이라는 말로도 사용됩니다. 하지만 좀 더 쉬운 개념으로 설명하자면 개인적으로 '울타리'라는 표현이 가장 좋다고 생각합니다. 즉 어떤 객체 n개가 동일한 Context에 놓여 있다는 것은 다른 표현으로는 'n개의 객체가 동일한 실행 환경에 있다'는 것을 의미합니다.

 예를 들어 static 변수를 생각해 봅니다.  static 변수(클래스변수)를 사용한다는 것은 현재 JVM내의 모든 객체가 동일한 값을 사용하게 됩니다. 반면에 여러 객체가 두 개의 Context내에 있다는 것을 그림으로 표현하면 아래의 그림처럼 됩니다.

따라서 어떤 객체가 어느 Context에 놓여 있느냐에 따라서 사용하는 값이 달라지게 됩니다.       

 Android의 경우는 거의 모든 객체를 단일한 Singleton객체로 관리합니다. 만일 다른 프로세스나 App에 의해서 특정한 데이터가 계속해서 변경된다면 이 때문에 App이 실행 도중에 원치 않는 결과를 만들어 낼 수 있습니다. 따라서 현재 App이 실행되는 하나의 '울타리'가 필요하게 되는데 이런 존재를 Context라고 합니다. Android에서는 코드를 물려주는 상속을 주로 사용하기 때문에 모든 Activity들은 자신이 어떠한 Context에서 동작해야 하는지를 알 필요가 있습니다.

간단한 디자인패턴-Command패턴

음.. 한 6년전에 정리하면서 만든 자료지만..
정리차 올립니다.

Command 패턴
Command 패턴은 인터페이스를 이용해서 내부에서 실행되는 객체가 무언지 모르는 상태에서
동일한 과정으로 메쏘드를 수행하고 싶을 때 사용하는 패턴이다.



다음과 같은 경우를 생각해 보자.
. Escm에서 여러개의 매니저가 존재한다.

. 각 매니저는 자신이 수행하기에 적합한 메쏘드가 있다.
. 매니저에게 동작을 시키고자 할 때 통일성을 갖게 하고자 하고 싶다.
예를 들어 파라미터의 값에 따라 자동적으로 특정 객체를 찾아내는 로직을 분리하고
특정 객체의 메쏘드는 인터페이스를 구현하도록 하면 다음과 같은 장점이 생길 수 있다.
. 어떤 객체이건간에 동일한 메쏘드 호출하면 된다.
. 새로운 객체를 추가할 때에도 인터페이스에 맞게 구현해 주면 된다.
이를 위해서 개발자가 먼저 해야 하는 것은 단 하나이다.

****인터페이스에서 코딩을 시작하라 *****
-----------------------------------------------------
Processable
-----------------------------------------------------
package command;
public interface Processable {

 public Object process()throws Exception;
}
-----------------------------------------------------
DocManager
-----------------------------------------------------
package command;
public class DocManager implements Processable {
 public Object process() throws Exception {
  System.out.println("DocManager의 처리 ");

  return null;
 }
}
-----------------------------------------------------
PodManager
-----------------------------------------------------
package command;
public class PodManager implements Processable {
 public Object process() throws Exception {
  System.out.println("PodManager의 처리 ");
  return null;
 }
}

-----------------------------------------------------
CommandTest
-----------------------------------------------------
package command;
public class CommandTest {

 Processable process = null;
 public static void main(String[] args) {

  CommandTest ct = new CommandTest();
  if(args.length < 1){
   System.out.println("args is null");
   return;
  }
  ct.test(args[0]);
 }
 private void test(String param) {

  Executor executor = new Executor();

  if(param.equals("1") == true ){
   process = new DocManager();
  }else{
   process = new PodManager();
  }

  executor.doJob(process);
 }
}
-----------------------------------------------------
Executor
-----------------------------------------------------
package command;
public class Executor {
 Processable command = null;

 public void doJob(Processable command){
  this.command = command;

  try{
   Object result = command.process();
 
  }catch(Exception e){
   e.printStackTrace();
  }
 }
}
디자인 패턴의 원칙이 '구현이 아니라 구성이다'이라는 원칙대로 인터페이스를 설계하고
인터페이스에 따라서 동작이 가능하게 하는 방식이다.
일반적인 경우에 Command패턴과 Strategy Pattern을 적용해서 많이 사용한다.