One of the ProgrammingParadigm 객체지향(ObjectOriented)프로그래밍([[OOP]]). ProcedualProgramming은 프로그램이 점점 복잡해지면서, 그 한계를 드러내기 시작했다. [[OOP]]의 시작은 세포를 모델링하면서 부터라고 한다. 생명현상의 관찰이 이 세상을 좀 더 적절하게 프로그램에 구현할 수 있게끔 했다는것이다. 이는 다시 역으로, 생물정보학으로 생명현상 모델링을 하고싶으면, [[OOP]]를 제대로 이해해야한다는 의미도 될 수 있을 것이다. {{http://www.obsolete.com/dug/sorcery/image12.gif}} {{http://www.obsolete.com/dug/sorcery/image11.gif}} 프로그램설계과정에서도 이 개념은 적용된다. [[UML]]로 ObjectOrientedDesign한다. === 중심개념 === * Abstraction * Encapsulation * Inheritance * MultipleInheritance * Polymorphism * Message sending * Association * Aggregation === Class사이의 관계 === * Association * Multiplicity * Qualified Association * Reflexive Association * Generalization * Dependency === OOP 원칙들 === * LiskovSubstitutionPrinciple * DryAndOrthogonality * DesignByContract * LawOfDemeter * ModelViewController * OpenClosedPrinciple == Discussion == [[Bioinformatics]]관련 ComputerProgramming하면서 [[OOP]]개념을 응용하면 느낌이 새롭다. [[OOP]]가 세포를 본땄다는 그 말그대로, 세포속을 [[OOP]]로 시뮬레이션한다. HackersHeroesOfTheComputerRevolution에 등장하는 해커들이야 [[OOP]]를 몰랐지만, BioSequence를 해킹해야하는 우리에겐 [[Life]]의 비밀을 풀 수 있는 열쇠가 그 안에 있다고 믿는다. 얼마전 대량[[EST]]서열을 PeptideMassFingerprint용 [[Database]]로 전환하는 [[Python]]스크립트를 작성한 적이 있다. 내 생각에 이 스크립트는 최대한 [[OOP]]적으로 작성되었고, 훌륭히 동작하며, 개념적이해/유지보수가 무지 좋다. {{{EstRetriever}}}라는 객체가 [[Database]]접속을 통해 4000여개의 [[EST]]서열을 추출하고, 각각 Est 객체를 만든다. 각 Est객체는 translate라는 메소드로 Protein객체를 리턴하고, 각 Protein은 {{{cutTrypticFragment}}} 메쏘드를 통해 절단된 새로운 [[Protein]]객체를 리턴한다. [[Protein]]객체의 __repr__ 메소드는 FastaFormat으로 해당 서열을 출력한다. 흐~~~ 여기서 하나 좀 고민해야 할 문제는 있다. [[Protein]]객체의 {{{cutTrypticFragment}}}메쏘드는 과연 새로운 단백질객체를 리턴해야 하는가, 아님 자신의 서열을 고쳐야하는가... 이건 최대한 real world를 묘사해야 할것이다. [[rulebend]]씨와의 짧은 대화로 내린결론은 트립신처리는 자신이 직접하는게 아니라, 외부해서 해주는 것이므로, [Protein]클래스에 구현될 필요가 없다는것... 대안으로 {{{getCutTrypticFragment}}}라는 메소드로 단백질객체를 리턴하는것은 타당해보임. 따라서... 메소드이름을 바꾸기로... 하여간 생물문제를 [[OOP]]로 푸는건 신나는일임에 틀림이 없다. --[[yong27]], 2002-11-9 ---- See also AspectOrientedProgramming, ValueOrientedProgramming ---- 참고사이트. * Seminar:OopIntroduction