함수와 메소드의 차이

Posted by epicdev Archive : 2013. 4. 18. 00:02

여태껏 함수와 메소드, 변수와 필드등의 용어들을 혼재해서 막 써왔었는데 이번 기회에 확실하게 기억해 놓아야 겠습니다.

아래의 표를 보시면 각 객체지향언어에서 멤버 변수와 멤버 함수들을 어떻게 지칭하는지 알 수 있습니다.


출처: http://blog.naver.com/cdincdin?Redirect=Log&logNo=30129625682



  

출처: http://hyukmini.tistory.com/entry/%EC%84%9C%EB%B8%8C%ED%83%80%EC%9D%B4%ED%95%91Sub-Typing%EA%B3%BC-%EC%84%9C%EB%B8%8C%ED%81%B4%EB%9E%98%EC%8B%B1Sub-Classing


[요약]

서브클래싱은 구현되어 있는 클래스를 상속하는 것

서브타이핑은 정의되어 있는 인터페이스를 구현하는 것


두 의미를 살피기 전에 Class(클래스)와 Type(타입)의 의미를 짚고 넘어가겠습니다.

     Integer a = new Integer(7);

객체 a를 생성하기 위해 앞에 붙인 Integer를 부를 때 Class 혹은 Type 이라고 부릅니다. 우리는 무의식적으로 둘을 혼용해서 쓰고 있습니다. 차이점이 없는 것 같지만 둘은 차이가 존재하고 개발자는 이를 구분지을 수 있어야 상속을 통한 상황에 맞는 적절한 객체지향 프로그래밍을 구사할 수 있습니다.

클래스는 "객체가 수행할 행동에 대한 연산의 집합"으로 정의할 수 있습니다. 
클래스는 값을 저장할 변수와 행동에 대한 연산이 구현된 메소드들로 구성되어 있습니다. 

타입은 "객체가 수행할 행동에 대한 약속의 집합"으로 정의할 수 있습니다.
타입은 수행할 행동만 약속함으로써 메소드의 선언들로만 구성되어 있습니다.
Java, C# 같은 언어에서는 interface를 통해 타입을 정의할 수 있습니다.

이제 상속 이야기로 가볼까요? 객체지향에서는 2가지 상속 메카니즘이 존재합니다.
상속이란 부모와 자식이 존재할 때 자식이 자신의 행동과 부모의 행동을 받아들일 수 있는 관계를 뜻합니다.
상속은 클래스와 타입을 구분하듯이 클래스를 상속하는 Subclassing과 타입을 상속하는 Subtyping으로 구분됩니다.

Subclassing
Super Class(슈퍼 클래스)에 구현된 코드와 내부 표현 구조를 Sub Class(하위 클래스)가 이어받습니다.
클래스 상속으로 불리기도 하며 하위 클래스에서 슈퍼 클래스에 구현된 코드의 재사용이 가능합니다.

C#을 통해 서브클래싱(클래스 상속)의 예를 들어 보겠습니다.

class A  {
    public String Name()  {
        return "Class name is A";
    }
}
class B : A {
    public String Name() {
        return "Class name is B";
    }
}
public static void PrintName(A obj) {
    Console.WriteLine(obj.Name());
}
static void Main(string[] args) {
    A objA = new A();
    A objB = new B();
    PrintName(objA);   => Class name is A   - (1)
    PrintName(objB);   => Class name is A   - (2)
}

(2)의 결과는 예상과 조금 다르게 나옵니다.  클래스 상속은 부모 클래스의 코드를 재사용하기 때문에 위와 같이 슈퍼클래스의 객체를 하위클래스의 객체로 대체하더라도 하위 클래스의 행동으로 대체되어 동작하지 않습니다. 이는 메소드 재정의(method overriding)를 통해 부모 클래스의 메소드를 대체하여야 합니다. C#에서는 부모에는 virtual 키워드를 넣어 가상함수로 정의하고 자식에는 override 키워드를 넣어 메소드 구현을 재정의를 합니다.

class A  {
    public virtual String Name()  {
        return "Class name is A";
    }
}
class B : A {
    public override String Name() {
        return "Class name is B";
    }
}


Subtyping
Super Type(슈퍼 타입)의 객체가 수행할 행동의 약속을 Sub Type(서브 타입)이 이어받습니다. 행동들을 공통된 타입으로 묶어 Runtime에 슈퍼 타입의 객체를 서브 타입의 객체로 대체가 가능하도록 해줍니다. 이를 통해 프로그램 변경에 대한 영향을 최소화하여 변경에 대한 유연한 대처가 가능토록 제공합니다.
 
C#을 통해 인터페이스를 통한 서브타이핑의 예를 들어 보겠습니다.

interface MyClass  {
    String Name();
}
class A : MyClass {
    public String Name()  {
        return "Class name is A";
    }
}
class B : MyClass {
    public String Name() {
        return "Class name is B";
    }
}
public static void PrintName(MyClass obj) {
    Console.WriteLine(obj.Name());
}
static void Main(string[] args) {
    MyClass objA = new A();
    MyClass objB = new B();
    PrintName(objA);   => Class name is A   - (1)
    PrintName(objB);   => Class name is B   - (2)
}

인터페이스 상속은 부모 타입의 행동의 약속만 상속받습니다. (C#에서 인터페이스에 메소드만 기술할 수 있습니다.) 따라서 슈퍼타입의 객체를 하위타입의 객체로 대체하면 동적으로 하위 타입의 행동으로 대체되어 호출이 됩니다.

  

출처: http://stackoverflow.com/questions/8100376/class-forname-vs-classloader-loadclass-which-to-use-for-dynamic-loading


Class.forName()의 경우 이 메소드를 호출한 클래스의 class loader를 사용한다. 그리고 생성되는 클래스의 전역 초기화 코드가 실행된다.


ClassLoader.loadClass()의 경우 주어진 class loader를 사용하며, 생성되는 클래스의 전역 초기화 코드가 실행되지 않는다.

  

Effective Java 목차

Posted by epicdev Archive : 2013. 4. 3. 01:35

이 항목들을 가끔씩 보면서 각각의 아이템들이 어떤 것을 의미했었는지 되새겨 보는 것도 좋을 것 같습니다.


1. Creating and Destroying Objects

Item 1: Consider static factory methods instead of constructors

Item 2: Consider a builder when faced with many constructor parameters

Item 3: Enforce the singleton property with a private constructor or an enum type

Item 4: Enforce noninstantiability with a private constructor

Item 5: Avoid creating unnecessary objects

Item 6: Eliminate obsolete object references

Item 7: Avoid finalizers


2. Methods Common to All Objects

Item 8: Obey the general contract when overriding equals

Item 9: Always override hashCode when you override equals

Item 10: Always override toString

Item 11: Override clone judiciously

Item 12: Consider implementing Comparable


3. Classes and Interfaces

Item 13: Minimize the accessibility of classes and members

Item 14: In public classes, use accessor methods, not public fields

Item 15: Minimize mutability

Item 16: Favor composition over inheritance

Item 17: Design and document for inheritance or else prohibit it

Item 18: Prefer interfaces to abstract classes

Item 19: Use interfaces only to define types

Item 20: Prefer class hierarchies to tagged classes

Item 21: Use function objects to represent strategies

Item 22: Favor static member classes over nonstatic


4. Generics

Item 23: Don't use raw types in new code

Item 24: Eliminate unchecked warnings

Item 25: Prefer lists to arrays

Item 26: Favor generic types

Item 27: Favor generic methods

Item 28: Use bounded wildcards to increase API flexibility

Item 29: Consider typesafe heterogeneous containers


5. Enums and Annotations

Item 30: Use enums instead of int constants

Item 31: Use instance fields instead of ordinals

Item 32: Use EnumSet instead of bit fields

Item 33: Use EnumMap instead of ordinal indexing

Item 34: Emulate extensible enums with interfaces

Item 35: Prefer annotations to naming patterns

Item 36: Consistently use the Override annotation

Item 37: Use marker interfaces to define types


6. Methods

Item 38: Check parameters for validity

Item 39: Make defensive copies when needed

Item 40: Design method signatures carefully

Item 41: Use overloading judiciously

Item 42: Use varargs judiciously

Item 43: Return empty arrays or collections, not nulls

Item 44: Write doc comments for all exposed API elements


7. General Programming

Item 45: Minimize the scope of local variables

Item 46: Prefer for-each loops to traditional for loops

Item 47: Know and use the libraries

Item 48: Avoid float and double if exact answers are required

Item 49: Prefer primitive types to boxed primitives

Item 50: Avoid strings where other types are more appropriate

Item 51: Beware the performance of string concatenation

Item 52: Refer to objects by their interfaces

Item 53: Prefer interfaces to reflection

Item 54: Use native methods judiciously

Item 55: Optimize judiciously

Item 56: Adhere to generally accepted naming conventions


8. Exceptions

Item 57: Use exceptions only for exceptional conditions

Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

Item 59: Avoid unnecessary use of checked exceptions

Item 60: Favor the use of standard exceptions

Item 61: Throw exceptions appropriate to the abstraction

Item 62: Document all exceptions thrown by each method

Item 63: Include failure-capture information in detail messages

Item 64: Strive for failure atomicity

Item 65: Don't ignore exceptions


9. Concurrency

Item 66: Synchronize access to shared mutable data

Item 67: Avoid excessive synchronization

Item 68: Prefer executors and tasks to threads

Item 69: Prefer concurrency utilities to wait and notify

Item 70: Document thread safety

Item 71: Use lazy initialization judiciously

Item 72: Don't depend on the thread scheduler

Item 73: Avoid thread groups


10. Serialization

Item 74: Implement Serializable judiciously

Item 75: Consider using a custom serialized form

Item 76: Write readObject methods defensively

Item 77: For instance control, prefer enum types to readResolve

Item 78: Consider serialization proxies instead of serialized instances




Effective Java, 2/E(Paperback)

저자
Block, Joshua 지음
출판사
Addison-Wesley | 2008-06-09 출간
카테고리
과학/기술
책소개
Designed to help Java programmers m...
가격비교



[업데이트 2013.04.03]


한글 목차도 올려봅니다


1. 객체의 생성과 소멸

[항목 1] 생성자 대신 static 팩토리(factory) 메소드 사용을 고려하자

[항목 2] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자

[항목 3] private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자

[항목 4] private 생성자를 사용해서 인스턴스 생성을 못하게 하자

[항목 5] 불필요한 객체의 생성을 피하자

[항목 6] 쓸모 없는 객체 참조를 제거하자

[항목 7] 파이널라이저(finalizer)의 사용을 피하자


2. 모든 객체에 공통적인 메소드

[항목 8] equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자

[항목 9] equals 메소드를 오버라이드 할 때는 hashCode 메소드도 항상 같이 오버라이드 하자

[항목 10] toString 메소드는 항상 오버라이드 하자

[항목 11] clone 메소드는 신중하게 오버라이드 하자

[항목 12] Comparable 인터페이스의 구현을 고려하자


3. 클래스와 인터페이스

[항목 13] 클래스와 그 멤버의 접근성을 최소화하자

[항목 14] public 클래스에서는 public 필드가 아닌 접근자(accessor) 메소드를 사용한다

[항목 15] 가변성을 최소화 하자

[항목 16] 가급적 상속(inheritance)보다는 컴포지션(composition)을 사용하자

[항목 17] 상속을 위한 설계와 문서화를 하자. 그렇지 않다면 상속의 사용을 금지시킨다

[항목 18] 추상 클래스보다는 인터페이스를 사용하자

[항목 19] 타입을 정의할 때만 인터페이스를 사용하자

[항목 20] 태그(tagged) 클래스보다는 클래스 계층을 사용하자

[항목 21] 전략을 표현할 때 함수 객체를 사용하자

[항목 22] static 멤버 클래스를 많이 사용하자


4. 제네릭(Generics)

[항목 23] 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자

[항목 24] 컴파일 경고 메시지가 없게 하자

[항목 25] 배열보다는 List를 사용하자

[항목 26] 제네릭 타입을 애용하자

[항목 27] 제네릭 메소드를 애용하자

[항목 28] 바운드 와일드 카드를 사용해서 API의 유연성을 높이자

[항목 29] 타입 안전이 보장되는 혼성(heterogeneous) 컨테이너의 사용을 고려하자


5. 열거형(Enum)과 주석(Annotation)

[항목 30] int 상수 대신 enum을 사용하자

[항목 31] 서수(序數) 대신 인스턴스 필드를 사용하자

[항목 32] 비트(bit) 필드 대신 EnumSet을 사용하자

[항목 33] 서수(序數) 인덱스 대신 EnumMap을 사용하자

[항목 34] 인터페이스를 사용해서 확장 가능한 enum을 만들자

[항목 35] 작명 패턴보다는 주석(annotation)을 사용하자

[항목 36] Override 주석을 일관성 있게 사용하자

[항목 37] 타입 정의는 표시 인터페이스를 사용하자


6. 메소드(method)

[항목 38] 매개 변수가 유효한지 검사하자

[항목 39] 필요하면 방어 복사본을 만들자

[항목 40] 메소드 시그니처를 신중하게 설계하자

[항목 41] 오버로딩(overloading)을 분별력 있게 사용하자

[항목 42] 가변 인자(varargs)를 분별력 있게 사용하자

[항목 43] null대신 비어있는 배열이나 컬렉션을 반환하자

[항목 44] 외부에 제공하는 모든 API 요소에 대해 문서화 주석을 넣자


7. 프로그래밍 일반

[항목 45] 지역 변수의 유효 범위를 최소화 하자

[항목 46] 종전의 for 루프보다는 for-each 루프를 사용하자

[항목 47] 라이브러리를 배우고 사용하자

[항목 48] 정확한 계산에는 float나 double 타입을 쓰지 말자

[항목 49] 박스화 기본형보다는 기본형을 사용하자

[항목 50] 다른 타입을 쓸 수 있는 곳에서는 String 사용을 피하자

[항목 51] 문자열 결합의 성능 저하를 주의하자

[항목 52] 객체 참조는 그 객체의 인터페이스 타입으로 하자

[항목 53] 리플렉션보다는 인터페이스를 사용하자

[항목 54] 네이티브 메소드를 분별력 있게 사용하자

[항목 55] 잘 판단해서 최적화하자

[항목 56] 보편화된 작명 규칙을 따르자


8. 예외(Exceptions)

[항목 57] 예외 상황에서만 예외를 사용하자

[항목 58] 복구 가능 상황에는 checked 예외를 사용하고 런타임 예외는 프로그램 에러에 사용하자

[항목 59] checked 예외의 불필요한 사용을 피하자

[항목 60] 표준 예외를 사용하자

[항목 61] 하위 계층의 예외 처리를 신중하게 하자

[항목 62] 메소드가 던지는 모든 예외를 문서화하자

[항목 63] 실패 상황 정보를 상세 메시지에 포함하자

[항목 64] 실패 원자성을 갖도록 노력하자

[항목 65] 예외를 묵살하지 말자


9. 동시성(Concurrency)

[항목 66] 공유하는 가변 데이터에 접근 시 동기화하자

[항목 67] 지나친 동기화는 피하자

[항목 68] 스레드 그룹보다는 실행자와 작업을 사용하자

[항목 69] wait와 notify 대신 동시성 유틸리티를 사용하자

[항목 70] 스레드 안전을 문서화 하자

[항목 71] 늦 초기화를 분별력 있게 사용하자

[항목 72] 스레드 스케줄러에 의존하지 말자

[항목 73] 스레드 그룹을 사용하지 말자


10. 직렬화(Serialization)

[항목 74] Serializable 인터페이스를 분별력 있게 구현하자

[항목 75] 독자적인 직렬화 형태의 사용을 고려하자

[항목 76] 방어 가능한 readObject 메소드를 작성하자

[항목 77] 인스턴스 제어에는 readResolve 메소드보다 enum 타입을 사용하자

[항목 78] 직렬화된 인스턴스 대신 직렬화 프록시의 사용을 고려하자




이펙티브 자바(EFFECTIVE JAVA)(제2판)

저자
JOSHUA BLOCH 지음
출판사
대웅 | 2009-04-13 출간
카테고리
컴퓨터/IT
책소개
더 명쾌하고, 더 정확하고, 더 강력하고, 재사용 가능한 코드를...
가격비교


  

Scala foldLeft 예제들

Posted by epicdev Archive : 2013. 4. 1. 05:12
  
 «이전 1  다음»