대상을 향한 3대 특성의 다태

카탈로그

대상을 대상으로 하는 3대 특성의 다태

1 다중적 정의

2 다태적 역할

3 오리 타입

대상을 향한 3대 특성의 다태

1 다태적 정의

다태는 같은 사물에 여러 가지 형태가 있다는 것이다

class Animal:
    pass

class People(Animal):
    pass

class Dog(Animal):
    pass

class Pig(Animal):
    pass

2 다태적 역할

다태가 다태성을 가져온다는 것은 대상의 구체적인 유형을 고려하지 않고 대상을 직접 사용할 수 있다는 것을 가리킨다

class Animal: #  
    def say(self):
        #  animal , say , 
        pass

class People(Animal):
    def say(self):
        super().say()
        print(' ')

class Dog(Animal):
    def say(self):
        super().say()
        print(' ')

class Pig(Animal):
    def say(self):
        super().say()
        print(' ')


obj1=People()
obj2=Dog()
obj3=Pig()


obj1.say()	#  
obj2.say()
obj3.say()

abc 모듈을 사용하면 하위 클래스가 반드시 어떤 방법의 정의를 포함해야 한다고 강제할 수 있다

import abc

#  metaclass 
class Animal(metaclass=abc.ABCMeta): #  
    @abc.abstractmethod		#  say 
    def say(self):
        pass
    
obj=Animal() #  

class People(Animal):
    def say(self):
        pass

class Dog(Animal):
    def say(self):
        pass

class Pig(Animal):
    def say(self):
        pass

pig = Pig() #  talk TypeError， 

3 오리 타입

사실 우리는 계승에 의존하지 않고 외관과 행동이 같은 대상을 만들 수 있다.
마찬가지로 대상 유형을 고려하지 않고 대상을 사용할 수 있다. 이것이 바로 파이톤이 숭상하는'오리 유형'(duck typing)이다.'비슷하고 울음소리가 비슷하며 길을 걷는 것이 오리와 같다면 오리다'.
계승 방식에 비해 오리 유형은 어느 정도 프로그램의 결합도를 실현하였다

#  ， 
#  animal , 
def say(animal):
    animal.say()

say(obj1)
say(obj2)
say(obj3)
#  python len() , , , 

#  len()
print('hello'.__len__())
print([1,2,3].__len__())
print({'a':1,'b':2}.__len__())

def my_len(val):
    return val.__len__()

print(my_len('hello'))
print(my_len([1,2,3]))
print(my_len({'a':1,'b':2}))


# def len(val):
#     return val.__len__()
print(len('hello'))
print(len([1,2,3]))
print(len({'a':1,'b':2}))

오리 타입도python의 선을 담고 있다
상속하지 않으면 상속하지 않는다
간단한 것이 복잡한 것보다 낫다

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!