- Refactoring/BadSmellsInCode . . . . 33 matches
* 같은 클래스내에 2개이상의 메소드들에 중복코드 존재시 - ExtractMethod
* 두개 이상 서브클래스 내 중복코드시 - ExtractMethod 한뒤 PullUpField
* 코드는 비슷하지만 똑같지는 않은 경우 - 비슷한 부분에 대해서 ExtractMethod
ExtractMethod, ExtractClass, PullUpMethod, FormTemplateMethod
== Long Method ==
* 대부분의 경우에 대해서 - ExtractMethod
* ExtractMethod 하는중 parameter를 많이 넘겨야 하거나, 임시변수를 많이 사용하게 되는 경우 - ReplaceTempWithQuery, IntroduceParameterObject, PreserveWholeObject, ReplaceMethodWithMethodObject
ExtractMethod, ReplaceTempWithQuery, ReplaceMethodWithMethodObject, DecomposeConditional
* When you can get the data in one parameter by making a request of an object you already know about - ReplaceParameterWithMethod
ReplaceParameterWithMethod, IntroduceParameterObject, PreserveWholeObject
* 바뀌는 부분들에 대해 MoveMethod, MoveField 하여 하나의 클래스에 넣는다. (없으면 새로 하나 클래스 생성할것)
MoveMethod, MoveField, InlineClass
MoveMethod, MoveField, ExtractMethod
* switch-case 부분을 ExtractMethod 한 뒤, polymorphism이 필요한 class에 MoveMethod 한다. 그리고 나서 ReplaceTypeCodeWithSubclasses 나 ["ReplaceTypeCodeWithState/Strategy"] 를 할 것을 결정한다. 상속구조를 정의할 수 있을때에는 ReplaceConditionalWithPolyMorphism 한다.
* polymorphism을 이용하기에는 너무 작아 오히려 cost가 더 드는 경우 - ReplaceParameterWithExplicitmethods
ReplaceConditionalWithPolymorphism, ReplaceTypeCodeWithSubclasses, ["ReplaceTypeCodeWithState/Strategy"], ReplaceParameterWithExplicitMethods, IntroduceNullObject
MoveMethod, MoveField
* 추상적인 두리뭉실한 메소드 이름 -_-; - RenameMethod 로 지상으로 내려오도록 하라는.. --;
CollapseHierarchy, InlineClass, RemoveParameter, RenameMethod
RemoveMiddleMan, InlineMethod, ReplaceDelegationWithInheritance
- Gof/FactoryMethod . . . . 20 matches
= Factory Method =
Factory Method는 sub 클래스에 대해 구현 사항을 결정할수 있게 만든다.
Factory Method 패턴은 이에 대한 해결책을 제시한다. 그것은 Document의 sub 클래스의 생성에 대한 정보를 캡슐화 시키고, Framework의 외부로 이런 정보를 이동 시키게 한다.
Fatory Method 패턴은 이럴때 사용한다.
* Factory Method가 생성하는 객체에 관한 인터페이스를 정의한다.
* Procunt 형의 객체를 반환하는 Factory Method를 선언한다. Creator는 또한 기본 ConcreteProduct객체를 반환하는 factory method에 관한 기본 구현도 정의되어 있다.
* Product객체를 만들기위한 factory method를 호출한다.
* ConcreteProduct의 인스턴스를 반환하기 위한, factory method를 오버라이드(over ride) 한다.
Creator는 factor method가 정의되어 있는 Creator의 sub클래스에게 의지한다 그래서 Creator는 CooncreteProduct에 적합한 인스턴스들을 반환한다.
Factory method는 당신의 코드에서 만들어야한 Application이 요구하는 클래스에 대한 기능과 Framework가 묶여야할 필요성을 제거한다. 그 코드는 오직 Product의 인터페이스 만을 정의한다.; 그래서 어떠한 ConcreteProduct의 클래스라도 정의할수 있게 하여 준다.
factory method의 잠재적인 단점이라고 한다면 클라이언트가 아마도 단지 특별한 ConcreteProduct객체를 만들기위해서 Creator클래스의 sub클래스를 가지고 있어야 한다는 것일꺼다. 클라이언트가 어떤 식으로든 Creator의 sub클래스를 만들때의, sub클래스를 만드는 것자체는 좋다. 하지만 클라이언트는 이런것에 신경쓸 필요없이 로직 구현에 신경을 써야 한다.
A potential disadvantage of factory methods is that clients might have to subclass the Creator class just to create a particular ConcreteProduct object. Subclassing is fine when the client has to subclass the Creator class anyway, but otherwise the client now must deal with another point of evolution.
자, 역시 Factory Method 패턴에 관련한 두가지의 결론을 이야기 한다.:
Here are two additional consequences of the Factory Method pattern:
1. ''서브 클래스와 소통 통로 제공''(''Provides hooks for subclasses.'') Factory Method를 적용한 클래스에서 객체의 생성은 항상 직접 만들어지는 객체에 비하여 유연하다. Factory Method는 객체의 상속된 버전의 제공을 위하여, sub클래스와 연결될수 있다.(hook의 의미인데, 연결로 해석했고, 그림을 보고 이해해야 한다.)
Ducument에제에서 Document클래스는 factory method에 해당하는, 자료를 열람하기 위한 기본 파일 다이얼로그를 생성하는 CreateFileDialog이 호출을 정의할수 있다. 그리고 Document sub클래스는 이러한 factory method를 오버 라이딩해서 만들고자 하는 application에 특화된 파일 다이얼로그를 정의할수 있다. 이러한 경우에 factory method는 추상적이지 않다. 하지만 올바른 기본 구현을 제공한다.
2. ''클래스 상속 관게에 수평적인(병렬적인) 연결 제공''(''Connects parallel class hierarchies.'') 여태까지 factory method는 오직 Creator에서만 불리는걸 생각해 왔다. 그렇지만 이번에는 그러한 경우를 따지는 것이 아니다.; 클라이언트는 수평적(병렬적)인 클래스간 상속 관계에서 factory method의 유용함을 찾을수 있다.
Figure클래스는 CreateManipulator라는, 서로 작용하는 객체를 생성해 주는 factory method이다. Figure의 sub클래스는 이 메소드를 오버라이드(override)해서 그들에게 알맞는 Manipulator sub클래스의 인스턴스를 (만들어, )반환한다. Figure 클래스는 아마도 기본 Manipulator인스턴스를 (만들어,) 반한하기 위한 기본 CreateManipulator를 구현했을 것이다. 그리고 Figure의 sub클래스는 간단히 이러한 기본값들을 상속하였다. Figure클래스 들은 자신과 관계없는 Manipulator들에 대하여 신경 쓸필요가 없다. 그러므로 이들의 관계는 병렬적이 된다.
Factory Method가 두게의 클래스의 상속 관계에서 어떻게 이러한 연결과정을 정의하는지 주목하라. 그것은 서로 고유의 기능을 부여시키는 작업을 한다.
Factory Method패턴이 적용될때 발생할수 있는 문제에 관해서 생각해 보자.:
- Java/ModeSelectionPerformanceTest . . . . 19 matches
한편으로 느껴지는 것으로는, switch 로 분기를 나눌 mode string 과 웹 parameter 와의 중복이 있을 것이라는 점이 보인다. 그리고 하나의 mode 가 늘어날때마다 해당 method 가 늘어나고, mode string 이 늘어나고, if-else 구문이 주욱 길어진다는 점이 있다. 지금은 메소드로 추출을 해놓은 상황이지만, 만일 저 부분이 메소드로 추출이 안되어있다면? 그건 단 한마디 밖에 할말이 없다. (단, 저 논문을 아는 사람에 한해서) GotoStatementConsideredHarmful.
=== 두번째 - Method reflection ===
import java.lang.reflect.Method;
public class MethodFullReflection {
Method method = null;
method = this.getClass().getMethod("do" + modeExecute[i], new Class[]{int.class});
method.invoke(this, new Object[]{new Integer(1)});
} catch (NoSuchMethodException e) {
단점 : 자바에서는 Method Reflection & Invoke 가 엄청 느리다.; 속도는 밑의꺼 참조.
import java.lang.reflect.Method;
public class MethodTableLookupReflection {
System.out.println("reflection with method initialize table elapsed time :" + (end - start) + "ms ");
System.out.println("reflection with method elapsed time :" + (end - start) + "ms ");
private static Map methodMap;
Method method = (Method) methodMap.get(modeExecute[i]);
if (method != null)
method.invoke(this, new Object[]{new Integer(1)});
private void initReflectionMap(String[] methodNames) {
methodMap = new HashMap();
for (int i = 0; i < methodNames.length; i++) {
- Refactoring/MakingMethodCallsSimpler . . . . 12 matches
= Chapter 10 Making Method Calls Simpler =
== Rename Method ==
The name of a method does not reveal its purpose.
''Change the name of the method''
http://zeropage.org/~reset/zb/data/RenameMethod.gif
A method needs more information from its caller.
A parameter is no longer used by the method body.
You have a method that returns a value but also changes the state of an object.
''Create two methods, one for the query and one for the modification''
== Parameterize Method ==
Several methods do similar things but with different values contained in the method body.
''Create one method that uses a parameter for the different values''
http://zeropage.org/~reset/zb/data/ParameterizeMethod.gif
== Replace Paramter with Explicit Method ==
You have a method that runs different code depending on the values of an enumerated parameter.
''Create a separate method for each value of the parameter''
You are getting several values from an object and passing these values as parameters in a method call.
== Replace Parameter with Method ==
An object invokes a method, then passes the result as a parameter for a method. The receiver can also invoke this method.
''Remove the parameter and let the receiver invoke the method''
- PNGFileFormat/FormatUnitTestInPythonLanguage . . . . 11 matches
# CompressionMethod
compressionMethod = ord(chunkInfo[2][10])
# Filter Method
filterMethod = ord(chunkInfo[2][11])
# InterlaceMethod
interlaceMethod = ord(chunkInfo[2][12])
print '\nBitDepth, ColorType, CompressionMethod, FilterMethod = (%d, %d, %d, %d, %d)' \
% (bitDepth, colorType, compressionMethod, filterMethod, interlaceMethod)
def makeScanline(self, basepixel, ypos, stream, rgbmap): # method 는 PNG filter type, stream은 zlib 으로 decomposite된 값들
method = ord(stream[idx])
if method == 0:
elif method == 1: # sub
elif method == 2:
elif method == 3:
elif method == 4: #paeth
- java/reflection . . . . 11 matches
* classpath를 이용해 현재 프로젝트내의 class가 아닌 외부 패키지 class의 method를 호출하는 방법.
public static void main(String[] args) throws MalformedURLException, ClassNotFoundException, InvocationTargetException, IllegalAccessException, InstantiationException, NoSuchMethodException {
Method[] declaredMethods = helloWorld.getDeclaredMethods();
for (int i = 0; i < declaredMethods.length; i++) {
Method declaredMethod = declaredMethods[i];
System.out.println(declaredMethod.getName());
Method sayHello = o.getClass().getMethod("sayHello", null);
- Refactoring/ComposingMethods . . . . 8 matches
= Chapter 6 Composing Methods =
== Extract Method p110 ==
* You have a code fragment that can be grouped together.[[BR]]''Turn the fragment into a method whose name explains the purpose of the method.''
== Inline Method p117 ==
* A method's body is just as clear as its name. [[BR]] ''Put the method's body into the body of its callers and remove the method.''
== Replace Method with Method Object p135 ==
* You have a long method that uses local variagles in such a way that you cannot apply ''Extract Method(110)''. [[BR]]
''Turn the method into ints own object so that all the local variagles become fields on that object. You can then decompose the method into other methods on the same object.''
http://zeropage.org/~reset/zb/data/ReplaceMethodWithMethodObject.gif
* You want to replace an altorithm with one that is clearer. [[BR]] ''Replace the body of the method with the new altorithm.''
- TestDrivenDevelopmentByExample/xUnitExample . . . . 8 matches
method = getattr( self, self.name )
method()
def testMethod(self):
self.log += "testMethod "
def testBrokenMethod(self):
self.test = WasRun("testMethod")
def testTemplateMethod(self):
assert "setUp testMethod tearDown " == self.test.log
self.test = WasRun("testBrokenMethod")
TestCaseTest("testTemplateMethod").run()
- DesignPatterns/2011년스터디/1학기 . . . . 7 matches
1. Factory Method와 Template Method 방법에대해 나쁜점을 설명하는데 Swing이 나오니까 다시 화난다. 난 Swing디자인이 싫어!!
1. Factory Method, Abstract Factory Method, Template Method, Command, Strategy의 비교를 통해 상속구현의 비효율성에 대해 느꼇다.
1. 지난주에 헷갈렸던 Factory Method 패턴에 대해 이해할 수 있게 됐다.
1. Factory Method 패턴은 상속을 통해 바뀌는 부분을 오버라이딩하여 구현
- LearningGuideToDesignPatterns . . . . 6 matches
=== Factory Method - Creational ===
FactoryMethodPattern 로 시작하라. 이 패턴은 다른 패턴들에 전반적으로 사용된다.
=== Template Method - Behavioral ===
앞에서의 IteratorPattern 의 예제코드에서의 "Traverse" 는 TemplateMethodPattern 의 예이다. 이 패턴은 StrategyPattern 과 FactoryMethodPattern 를 보충해준다.
AbstractFactoryPattern은 두번째로 쉬운 creational Pattern이다. 이 패턴은 또한 FactoryMethodPattern를 보강하는데 도움을 준다.
- Refactoring/DealingWithGeneralization . . . . 6 matches
== Pull Up Method ==
* You have methods with identical results on subclasses.[[BR]]''Move them to the superclass''
http://zeropage.org/~reset/zb/data/PullUpMethod.gif
* You have constructors on subclasses with mostly identical bodies.[[BR]]''Create a superclass constructor; class this from the subclass methods.''
== Push Down Method ==
http://zeropage.org/~reset/zb/data/PushDownMethod.gif
== Form Template Method ==
* You have two methods in subclasses that perform similar steps in the same order, yet the steps are different.[[BR]]''Get the steps into methods with the same signature, so that the original methods become the same. Then you call pull them up.''
http://zeropage.org/~reset/zb/data/FormTemplateMethod.gif
* A subclass uses only part of a superclasses interface or does not want to inherit data.[[BR]]''Create a field for the superclass, adjust methods to delegate to the superclass, and remove the subclassing.''
- 진격의안드로이드&Java . . . . 6 matches
public void methodOperandStack(){
1: invokespecial #1 // Method java/lang/Object."<init>":()V
9: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
public void methodOperandStack();
public void methodOperandStack(){
1: invokespecial #1 // Method java/lang/Object."<init>":()V
9: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
public void methodOperandStack();
private final void methodOperandStack(){
1: invokespecial #1 // Method java/lang/Object."<init>":()V
9: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
- ComposedMethod . . . . 4 matches
=== Composed Method ===
당신이 가장 중요하게 Composed Method를 쓸때는, 당신이 뭔가를 구현하고 있을때 새로운 책임을 발견했을때이다. 당신이 둘 이상의 메세지를 다른 객체로 보낼때, 수신 객체에서는 그 메세지들을 합치는 Composed Method를 만들 수 있다. 이러한 Method들은 당신의 시스템의 다른 부분에서도 유용하게 쓰일 것이다.
- HolubOnPatterns/밑줄긋기 . . . . 4 matches
* 이러한 착각은 흔히 C를 배우고 C++을 배울 때, '객체'가 아닌 문법 클래스'를 쉽게 설명하려고 "클래스는 structure(data) + method(to do) 이다." 라는 요상한 설명을 접하게 되면 하게 되는 것 같습니다. 처음에 이런 설명을 접하게 되면 나중에는 생각을 바꾸기 어려워지죠 (아니 귀찮아지는 건가...) -_-;; - [박성현]
==== Template method와 Factory Method 패턴 ====
* Factory Method 패턴은 좋은 선택이 아니었다. 이번 장의 뒤에서 살펴볼 Strategy 패턴 등은 Factory Method 패턴의 멋진 대안이 된다.
* 사실 거의 대부분의 상황에서 Strategy는 Factory Method의 좋은 대안이 된다.
- InWonderland . . . . 4 matches
[WebMethod(Description="앨리스 가맹점 인증")]
[WebMethod(Description="포인트 조회")]
[WebMethod(Description="포인트 적립")]
[WebMethod(Description="포인트 사용")]
- PatternCatalog . . . . 4 matches
* ["FactoryMethodPattern"]
* ["Gof/FactoryMethod"]
* ["TemplateMethodPattern"]
* ["Gof/TemplateMethod"]
- Spring/탐험스터디/wiki만들기 . . . . 4 matches
* RequestMappingHandlerMapping의 매핑 테이블을 보니 {[ URL ], methods=[ Method 타입 ], params=[],headers=[],consumes=[],produces=[],custom=[]}등으로 Request를 구분하고 있었다.
* 이를 이용해 RequestMapping의 value값, Method 타입이 같아도 특정 파라메터의 유무로 리퀘스트 핸들링을 달리할 수 있다.
* 예를들어 ''@RequestMapping(value = "/helloworld", method = RequestMethod.GET)''와 ''@RequestMapping(value = "/helloworld", method = RequestMethod.GET, params="param=param")''은 다르다. 각각 다른 함수에 mapping될 수 있다.
* RequestMapping의 method 타입을 이용해 signup 페이지 호출과 실제 signup을 구분하여 핸들링
- 작은자바이야기 . . . . 4 matches
* static modifier에 대해 애매하게 알고 있었는데 자세하게 설명해주셔서 좋았습니다. static은 타입을 통해서 부르는거라거나 원래 모든 함수가 static인데 객체지향의 다형성을 위해 static이 아닌 함수가 생긴거라는 설명은 신기했었습니다. object.method(message) -> MyType::method(object, method) 부분이 oop 실제 구현의 기본이라는 부분은 잊어버리지 않고 잘 기억해둬야겠습니다. 근데 파이썬에서 메소드 작성시 (self)가 들어가는 것도 이것과 관련이 있는건가요? -[서영주]
* http://stackoverflow.com/questions/68282/why-do-you-need-explicitly-have-the-self-argument-into-a-python-method
* 제가 "원래 모든 함수가 static"이라는 의미로 말한건 아닌데 오해의 소지가 있었나보군요. 사실 제가 설명한 가장 중요한 사실은 말씀하신 예에서 object의 컴파일 타입의 method() 메서드가 가상 메서드라면(static이 아닌 모든 Java 메서드), 실제 어떤 method() 메서드를 선택할 것이냐에 관한 부분을 object의 런타임 타입에 의한다는 부분이었지요. 그러니까 object는 컴파일 타입과 동일하지 않은 런타임 타입을 가질 수 있으며, 다형성의 구현을 위해 implicit argument인 object(=this)의 런타임 타입에 따라 override된 메서드를 선택한다는 사실을 기억하세요. (Python에선 실제 메서드 내에서 사용할 formal parameter인 self를 explicit하게 선언할 수 있다고 보면 되겠지요.) - [변형진]
* 리플렉션과 제네릭스를 써서 map -> object와 object -> map을 하는 부분을 해봤습니다. 자바의 일반적인 세 가지 방식의 클래스 내 변수에 대해 getClass, getFields, getMethods를 사용해 private, 나 접근자가 있는 경우의 값을 받아왔습니다. getter를 사용해서 변수 값을 받아올 때 이름이 get으로 시작하는 다른 함수를 제외하기 위해 method.getParameterTypes().length == 0 같은 부분은 이렇게 체크해야 된다는 부분은 나중에 제네릭스 관련으로 써먹을만 할 것 같습니다. 그리고 mapToObject에서는 문제가 없었지만 objectToMap의 경우에는 제네릭스의 type erase때문에 Class<T> expectedType = T.class; 같은 코드를 사용할 수 없어서 map.put(field.getName(), (T)field.get(obj));에서 형변환의 타입 안전성을 위해 인자로 Class<T> valueType을 받아오고 valueType.isAssignableFrom(field.getType())로 체크를 하는 부분도 공부가 많이 됐습니다. - [서영주]
* @Target : 만들고자 하는 Annotation의 대상 지정. (ElementType.TYPE, ElementType.METHOD)등
* 함수의 체이닝을 위해서는 generics가 필요함. static method로는 체이닝을 할 수 없음.
* Data 부분을 인터페이스로 분리 - 내부에서 FactoryMethod 패턴을 사용. factory를 통해서 객체를 생성한다. new를 사용하지 않기 때문에 구체 클래스를 숨길 수 있다.
* factory method 패턴 사용 - factory를 숨겨주는 메소드. 뭘 만들지를 인자만 가지고 결정하는 함수. 위에서는 인자로 주는 문자열에 따라("com.mysql.jdbc.Driver") 무엇을 만들어줄지가 결정된다.
* abstract factory패턴과 factory method 패턴의 구분
* 생성 메소드의 인자만으로 생성되는 인스턴스의 타입이 결정될 경우 factory method
* strategy 패턴, command 패턴, template method 패턴
* strategy 패턴 - template method 패턴
반면에 template method 패턴은 부모 클래스에서 전체적인 틀을 만들어 두고 행동에 해당하는 메소드를 상속 + 오버라이드 해서 확장한다.
* template method 패턴이 사용됐다. protected로 선언된 service method가 template method에 해당되는데 abstract가 아닌 이유는 기본 구현을 주고 원하는 호출에 대해 오버라이드를 해서 사용하기 위함이다.
* init : servlet이 불러와지면 먼저 실행되는 method. init이 실행되지 않으면 servlet이 로딩되지 않는다.
* destoy : servlet이 종료될 시 실행되는 method.
* service : 외부에서 서버로 request가 들어올 시 서버에서 servlet의 service method를 실행시킴. service(req, res) 내부에서 req를 통해 request의 값을 받아서 res의 값을 변경시켜 외부로 내보내준다. 해당 결과를 do*의 이름이 붙은 method(doGet, doPost 등)로 전달해준다.
* do* : 해당 httpMethod에 대한 처리를 해주는 method.
* IME(Input Method Editor) - OS 레벨에서 실제 key code - 문자의 mapping과 문자 조합('ㅁ' + 'ㅏ' 같은 경우)의 처리를 해 주는 소프트웨어. Sublime에서는 제대로 처리를 안 해 줬다...
* invokespecial - vtable lookup을 하지 않고 메소드를 호출하는 경우. 어떤 메소드를 호출해야 하는지 정해져 있는 경우에 사용된다. new, private method, super 등.
- 1002/Journal . . . . 3 matches
구조를 살피면서 리팩토링, KeywordGenerator 클래스와 HttpSpider 등의 클래스들을 삭제했다. 테스트 96개는 아직 잘 돌아가는중. 리팩토링중 inline class 나 inline method , extract method 나 extract class 를 할때, 일단 해당 소스를 복사해서 새 클래스를 만들거나 메소드를 만들고, 이를 이용한뒤, 기존의 메소드들은 Find Usage 기능을 이용하면서 이용하는 부분이 없을때까지 replace 하는 식으로 했는데, 테스트 코드도 계속 녹색바를 유지하면서, 작은 리듬을 유지할 수 있어서 기분이 좋았다.
Refactoring Catalog 정독. 왜 리팩토링 책의 절반이 리팩토링의 절차인지에 대해 혼자서 감동중.; 왜 Extract Method 를 할때 '메소드를 새로 만든다' 가 먼저인지. Extract Class 를 할때 '새 클래스를 정의한다'가 먼저인지. (절대로 '소스 일부를 잘라낸다'나 '소스 일부를 comment out 한다' 가 먼저가 아니라는 것.)
factory method를 사용해라.
http://www.utdallas.edu/~chung/patterns/conceptual_integrity.doc - Design Patterns as a Path to Conceptual Integrity 라는 글과 그 글과 관련, Design Patterns As Litmus Paper To Test The Strength Of Object Oriented Methods 라는 글을 보게 되었는데, http://www.econ.kuleuven.ac.be/tew/academic/infosys/Members/Snoeck/litmus2.ps 이다. 디자인패턴의 생성성과 관련, RDD 와 EDD 가 언급이 되는 듯 하다.
* Simple Design 에 대해서 내가 잘못 생각한 것 같다. Up-Front Design 자체를 구체적으로 들어갔을때 얼마나 복잡할 수 있는지도 모르면서 처음부터 Simple Design 을 논할수 있을까 하는 생각도 해본다. 생각해보니, 여태껏 내가 그린 전체 UML Class Design 은 거의 다 Simple Design 이겠군. -_-; (Interface 들 Method 이름도 결정 안했으니까.)
- CollectionParameter . . . . 3 matches
ComposedMethod의 단점중 하나는, 작은 메소드들 사이의 연관때문이다. 큰 메소드 하나에서 공유되었던 임시 변수들이, 이제는 작은 메소드들 사이에 공유된다. 가장 해결하기 쉬운 방법은 ComposedMethod를 없애고 다시 하나의 큰 메소드에 다 때려넣는 것이지만, 안좋다. 또 다른 해결책으로는 이 작은 메소드들 사이에서 공유되는 임시 변수를 멤버변수에 넣는 것이다. 이것은 객체의 생명기간 동안 유효한게 아니라, 저 메소드들이 실행될때에만 유효하다. 역시 안좋다.
ComposedMethod를 적용해보자.
- ConstructorMethod . . . . 3 matches
=== Constructor Method ===
그래서 Constructor Method를 쓰기를 권한다. 즉 인스턴스를 똑바로 만들어주는 각각의 메소드를 추가해주는 것이다.
또다른 예로 반지름과 각도를 받아 x,y를 계산해주는 Constructor method를 만들어보자.
''DesignPatterns 로 이야기한다면 일종의 FactoryMethod 임.(완전히 매치되는건 아니고, 어느정도 비슷) 비교적 자주 사용되는 패턴인데, 왜냐하면 객체를 생성하고 각각 임의로 셋팅해주는 일을 생성자 오버로딩을 더하지 않고서도 할 수 있으니까.
- DesignPatternsAsAPathToConceptualIntegrity . . . . 3 matches
The following summary is from “Design Patterns as a Litmus Paper to Test the Strength of Object-Oriented Methods” and may provide some insight:
1. Some O-O design methodologies provide a systematic process in the form of axiomatic steps for developing architectures or micro-architectures that are optimality partitioned (modularized) according to a specific design criteria.
2. The following methodologies are listed according to their key design criteria for modularization:
3. According to the authors only RDD and EDD have axiomatic rules for OO design and therefore are strong OO design methods.
5. EDD and RDD will generate different design patterns that meet the primary modularization principle “encapsulate the part that changes.” in different ways when applied according to their axiomatic rules. For example RDD generates Mediator, Command, Template Method and Chain of responsibility (mostly behavior) where as EDD generates Observer, Composite, and Chain of responsibility (mostly structure).
EDO 와 RDD 는 이 1차 원리인 "변화하는 부분에 대해 캡슐화하라"와 그들의 명확한 룰들에 따라 적용될때 다른 방법들로 만나서, 다른 디자인 패턴들을 생성해 낼 것이다. 예를 들면, RDD는 Mediator, Command, TemplateMethod, ChainOfResponsibility (주로 behavior), EDD 는 Observer, Composite, ChainOfResposibility(주로 structure) 를 생성해낼것이다.
· Are some O-O design methods better at creating an environment where design patterns are used in a generative sense?
· Will strong O-O design methods produce results for the “many” with the same conceptual integrity as “a few good minds.”
- JavaScript/2011년스터디/CanvasPaint . . . . 3 matches
var color=3,drawmethod=1;
if(drawmethod==1) drawLines();
else if(drawmethod==2) drawDotPoint();
function drawMethod(temp)
drawmethod=temp;
<button type="button" onclick="drawMethod(1)"> LINE </button>
<button type="button" onclick="drawMethod(2)"> DOT </button>
- LazyInitialization . . . . 3 matches
LazyInitialization의 하나의 변수당 두개의 메소드로 나눠서 초기화를 한다. 하나는 변수가 LazyInitialization되는 것을 감추어 주는 getter이고, 다른 하나는 변수에다 디폴트값으로 할당을 해줄 DefaultValueMethod이다. 이 방법은 유연성이 증대된다. 당신이 서브클래스를 만든다면, DefaultValueMethod를 오버라이딩함으로써, 기능을 바꿀 수 있다. 전장에서도 언급했듯이 성능도 증대시킬 수 있다.
변수마다 getter를 만들자. 필요하다면 DefaultValueMethod를 써서 초기화를 하자.
- REFACTORING . . . . 3 matches
Three Strike 법칙은 외우기 쉬워서 처음 Refactoring 을 하는 사람들에겐 적당하다. 하지만, 저 법칙은 주로 중복이 일어날 때의 경우이고, Rename Method/Field/Variable 같은 Refactoring 은 지속적으로 해주는 것이 좋다.
["Refactoring"] 에 의외로 중요한 기술로 생각되는건 바로 Extract Method 와 Rename 과 관련된 Refactoring. 가장 간단하여 시시해보일지 모르겠지만, 그로서 얻어지는 효과는 대단하다. 다른 Refactoring 기술들의 경우도 일단 Extract Method 와 Rename 만 잘 지켜지면 그만큼 적용하기 쉬워진다고 생각.
- Refactoring/MovingFeaturesBetweenObjects . . . . 3 matches
== Move Method ==
A method is, or will be, using or used by more features of another class than the class on which it is defined.
''Create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether.''
http://zeropage.org/~reset/zb/data/MoveMethod.gif
''Create a new class and move the relevant fields and methods from the old class into the new class.''
''Create methods on the server to hide the delegate.''
== Introduce Foreign Method ==
A server class you are using needs an additional method, but you can't modify the class.
''Create a method in the client class with an instance of the server class as its first argument.''
A server class you are using needs serveral additional methods, but you can't modify the class.
''Create a new class that contains these extra methods. Make the extension class a subclass or a wapper of the original.''
- RefactoringDiscussion . . . . 3 matches
Martin Folwer의 Refactoring p326(한서), 10장의 Parameterize Method 를 살펴보면 다음과 같은 내용이 나온다.
* ["Refactoring"]의 Motivation - Pattern 이건 Refactoring 이건 'Motivation' 부분이 있죠. 즉, 무엇을 의도하여 이러이러하게 코드를 작성했는가입니다. Parameterize Method 의 의도는 'couple of methods that do similar things but vary depending on a few values'에 대한 처리이죠. 즉, 비슷한 일을 하는 메소드들이긴 한데 일부 값들에 영향받는 코드들에 대해서는, 그 영향받게 하는 값들을 parameter 로 넣어주게끔 하고, 같은 일을 하는 부분에 대해선 묶음으로서 중복을 줄이고, 추후 중복이 될 부분들이 적어지도록 하자는 것이겠죠. -- 석천
ps. 현실에서 정말 모든 상태 공간/기계가 고대로 유지되는 리팩토링은 없습니다. 가장 대표적인 Extract a Method 조차도 모든 경우에 동일한 행동 유지를 보장할 수는 없습니다. 1+2가 2+1과 같지 않다고 말할 수 있습니다. 하지만 우리에게 의미있는 정도 내에서 충분히 서로 같다고 말할 수도 있습니다 -- 물론 필요에 따라 양자를 구분할 수도 있어야겠지만, 산수 답안 채점시에 1+2, 2+1 중 어느 것에 점수를 줄 지 고민할 필요는 없겠죠.
- StaticInitializer . . . . 3 matches
[Java] 에서 'Class Variable' 또는 'Class Method' 라 불리는, 해당 Class 내에서 공용적으로 쓸 수 있는 변수나 메소드들을 Static Variable 또는 Static Method 라 불린다.
이를 방지하려면, StaticInitializer 를 일반 Method 로 추출한뒤, 생성자에서 이를 호출한다. (단, 인스턴스를 2개 이상 만드는 클래스인경우 문제가 있겠다.)
- 상협/삽질일지/2002 . . . . 3 matches
* 이번 삽질은 정말 중대한 삽질이었다. 1학기 평점을 좌우한다고 볼 수 있는 삽질이었다. 1학기 중간고사 대채용으로 내는 자바 프로젝트에서 소켓 부문을 맡은 친구가 알수 없는 에러때문에 엄청난 삽질을 해서 더이상 나아갈수 없다고 했었다. 메신저에서 통신이 안되다니.. ㅡㅡ;; 그 에러는 "No Such Method Found" 에러다. 그러한 Method가 분명히 있는데도 불구하고 안되었다. 나는 황당했다. 그 친구가 자바는 많이 안했어도 MFC랑 C++을 잘해서 소켓을 맡았는데... 나도 그 에러를 같이 찾기 위해서 삽질을 하였다. 소스도 길고 내가 짠것도 아니어서 정말 못 찾을거 같았다. 그 소스는 특성학 모든 클래스가 딱 서버, 클라이언트 두 파일 안에 들어 있었다. 그래서 난 그 클래스들을 각자 파일로 분리해 보기로 했다. 잘 안풀리니깐 한번 정리나 해보면 뭐좀 어떻게 될까 싶은 마음에 그렇게 했다. 그렇게 정리를 하다 문득.. ㅡㅡ;; 같은 이름의 클래스를 서버, 클라이언트에서 각자 다르게 정의해서 사용하는 소스를 발견... ㅡㅡ;;, 그 친구는 아직 자바에 익숙하지 않아서 이런 실수를 했나 보다.. 나도 만약 소스를 클래스별로 파일로 만들 생각을 안했으면 그 에러의 원인을 발견하지 못했을 것이다. 휴. 큰일날 뻔 했넹.. 앞으로는 "No Such Method Found"같은 에러때문에 고생할일은 절대 없기를.. ㅡㅡ;
- ConstructorParameterMethod . . . . 2 matches
=== Constructor Parameter Method ===
Constructor Method로 인스턴스를 만들때, 그리로 넘겨준 파라메터들을 새롭게 만들어진 인스턴스로 어떻게 갖고 오는가? 가장 유연한 방법은 각각의 변수에 대해 setter들을 만들어 주는 것이다. 즉,
- ConverterMethod . . . . 2 matches
=== Converter Method ===
스몰토크의 String 클래스에 보면 asDate라는 메세지가 있다. 켄트벡이 경험한 정말 극단적인 경우에 하나의 객체마다 다른 형태로 변환시켜주는 Converter Method가 30개씩 있었다고 한다. 새로운 객체가 추가될때마다 저 30개의 메소드를 모두 추가해줘야만 했던 것이다.
- HowToStudyDesignPatterns . . . . 2 matches
''...but I always teach Composite Pattern, Strategy Pattern, Template Method Pattern, and Factory Method Pattern before I teach Singleton Pattern. They are much more common, and most people are probably already using the last two. ... ''
- TFP예제/WikiPageGather . . . . 2 matches
* '생각할 수 있는 가장 단순한 것부터 생각하라.' 디자인은 TFP 와 Refactoring의 과정만으로 어느정도 보장이 된다. TFP을 추구하는 이상 기능와 의도에 의한 모듈화가 기본적으로 이루어진다. (여태껏의 경험 -- 그래봤자 3번째지만 -- 에 의하면, TFP를 하면서 LongMethod 냄새가 난 적이 없었다. (LongMethod와 Bad Smell 에 대해서는 BadSmellsInCode를 참조하라.) 만일 중복코드 등의 문제가 발생하더라도 기존의 막무가내식 방식에 비해 그 빈도가 적다. 만일 Bad Smell 이 난다면 ["Refactoring"] 을 하면 된다. (참고로 밑의 소스는 ["Refactoring"]의 과정은 거치지 않았다.)
- [Lovely]boy^_^/Diary/2-2-10 . . . . 2 matches
* ["SmalltalkBestPracticePatterns/Behavior/ComposedMethod"] 읽고 요약.
* ["SmalltalkBestPracticePatterns/Behavior/ComposedMethod"] read and summary.
- 데블스캠프2006/월요일/연습문제/웹서버작성/변형진 . . . . 2 matches
* GET Method으로 넘어온 Query String를 처리한다.
* POST Method, COOKIE 등으로 넘어온 데이터까지 처리할 수 있으면 더 좋다.
- ACM_ICPC/2012년스터디 . . . . 1 match
- Hungarian Method (가중치가 들어간 매칭)
- CodeConvention . . . . 1 match
* 1980년대 charles simonyi 논문 Meta-programming : A Software Prodution Method
- ComputerGraphicsClass/Exam2004_2 . . . . 1 match
=== Ploygon Rendering Methods ===
- CppStudy_2002_2 . . . . 1 match
|| 8.1 ||["Refactoring/ComposingMethods"]||몇개 소스 리팩토링 해보기||
- DecomposingMessage . . . . 1 match
메세지를 다루는 또 다른 방법은 여러 개의 조각으로 나누는 것이다. 리팩토링의 ExtractMethod이다. 스몰토크는 잘게 쪼개는 것을 좀 더 공격적으로 한다. 그래서 한 메소드의 길이가 3-4줄정도밖에 안된다고 한다. 이것이 가능한 이유는 스몰토크는 다른 언어에 비해 높은 수준의 추상화를 제공해주기 때문이다. self 에게로 메세지를 보내자.
- DefaultValueMethod . . . . 1 match
== Default Value Method ==
- ExecuteAroundMethod . . . . 1 match
=== Excute Around Method ===
- ExtractMethod . . . . 1 match
See ["Refactoring/ComposingMethods"]
- ExtremeProgramming . . . . 1 match
* http://www.martinfowler.com/articles/newMethodology.html#N1BE - 또다른 '방법론' 이라 불리는 것들. 주로 agile 관련 이야기들.
* http://www.freemethod.org:8080/bbs/BBSView?boardrowid=3220 - 4가지 가치 (Communication, Simplicity, Feedback, Courage)
* http://www.freemethod.org:8080/bbs/BBSView?boardrowid=3111 - 4가지 변수 (Resource, Quality, Time, Scope)
- FactoryMethodPattern . . . . 1 match
#redirect Gof/FactoryMethod
- Functor . . . . 1 match
비슷한 구현에 대해서 OO 쪽에서는 MethodObject 라 부르기도 함. (Refactoring에 나옴) 구현 모양상으로 보면 CommandPattern, C++ 진영에서는 Functor 가 일반적인 표현.; --[1002]
- IntelliJ . . . . 1 match
|| F6 || Rename. class 이건 Method 이건. Refactoring 의 ["IntelliJ"] 의 중요 기능중 하나. ||
|| ctrl + alt + M || extract method refactoring||
- Java2MicroEdition/MidpHttpConnectionExample . . . . 1 match
httpConn.setRequestMethod(HttpConnection.GET);
- JavaScript/2011년스터디/김수경 . . . . 1 match
// Add a new ._super() method that is the same method
// The method only need to be bound temporarily, so we
// All construction is actually done in the init method
* Super Method
- JollyJumpers/Leonardong . . . . 1 match
run = staticmethod(run)
처음에 리스트에 차를 집어넣은 후 정렬하려 했다가 집합 개념이 떠올라 그 쪽으로 해결했다. statementForSeries메서드 부분에 있던 CheckJolly메서드를 따로 테스트하면서 ExtractMethod를 하게 되었고, 차가 음수인 경우도 테스트를 통해 알게되었다. 보폭이 아직 좁지만 술술 진행한 문제이다.
- LawOfDemeter . . . . 1 match
objects than you need to either. In fact, according to the Law of Demeter for Methods, any method of an
object should only call methods belonging to:
any parameters that were passed in to the method.
Specifically missing from this list is methods belonging to objects that were returned from some other
SortedList's add method is addElementWithKey()
foo's method to query its key is getKey()
The disadvantage, of course, is that you end up writing many small wrapper methods that do very little but
of maintaining these as separate methods. Why bother?
The last, of course, is why Eiffel requires only side-effect free methods to be called from within an
- NUnit/C#예제 . . . . 1 match
1. 테스트 하고자 원하는 Method 에는 Test를, 속한 클래스에는 TestFixture Attribute를 붙인다.
- NumericalAnalysisClass . . . . 1 match
''Object-Oriented Implementation of Numerical Methods : An Introduction with Java and Smalltalk'', by Didier H. Besset.
- OOP . . . . 1 match
* [Method]
- PluggableSelector . . . . 1 match
실행될 selector를 가지는 변수를 추가한다. 이름 뒤에 Message를 덧붙인다. selector를 실행하기 쉽게 해주는 Composed Method를 만든다.
- ProjectPrometheus/Journey . . . . 1 match
* Side Effect 는 Refactoring 의 적이라는 생각이 오늘처럼 든 적이 없었다. -_-; Extract Method 같은 일을 하는 경우 더더욱.! --["1002"]
- PyIde/BicycleRepairMan분석 . . . . 1 match
코드 분석방법에서 Eclipse 의 Ctrl + Alt + H 를 눌렀을때 나오는 Method call hierarchy 기능으로 코드를 읽어나가는 것이 유용하다는 점을 알아내었다. StepwiseRefinement 를 역순으로 따라가는 느낌이랄까.
- PyIde/SketchBook . . . . 1 match
하지만, 손가락 동선의 경우 - ctrl + O 를 누르고 바로 메소드 이동을 한다. 일반 이동도 메소드 중간 이동은 CTRL +커서키. (이는 VIM 에서의 W, B) 위/아래는 커서키. 클래스로의 이동은 CTRL+SHIFT+T. Source Folding 도 주로 Outliner 에 의한 네비게이팅을 이용한다면 별로 쓸 일이 없다. 보통 의미를 두고 하는 행동들은 클래스나 메소드들 단위의 이동이므로, 그 밑의 구현 코드들에 대해 깊게 보지 않는다. (구현코드들에 대해 깊게 보는 경우가 생긴다면 십중팔구 Long Method 상황일것이다.)
- QueryMethod . . . . 1 match
=== Query Method ===
- ResponsibilityDrivenDesign . . . . 1 match
* Generates DesignPatterns. ChainofResponsibilityPattern, MediatorPattern, CommandPattern and TemplateMethodPattern are all generated by the method.
- STLErrorDecryptor . . . . 1 match
Upload:WorkingMethod.gif
- Spring/탐험스터디/2011 . . . . 1 match
1.2 http의 4가지 method : POST, GET, PUT, DELETE
리소스 함수의 4가지 method : CRUD(Create, Read, Update, Delete)
DB의 4가지 method : Insert, Select, Update, Delete
at java.security.AccessController.doPrivileged(Native Method)
- TddRecursiveDescentParsing . . . . 1 match
대강 다음과 같은 식으로 접근했고요. 테스트코드 2-3줄쓰고 파서 메인코드 작성하고 하는 식으로 접근했습니다. (["Refactoring"] 을 하다보면 FactoryMethodPattern 과 CompositePattern 이 적용될 수 있을 것 같은데, 아직은 일단.)
- TddWithWebPresentation . . . . 1 match
즉, 일종의 Template Method 의 형태로서 Testable 하기 편한 ViewPageAction 의 서브클래스를 만들었다. 어차피 중요한것은 해당 표현 부분이 잘 호출되느냐이므로, 이에 대해서는 서브클래스로서 텍스트를 비교했다.
- TheWarOfGenesis2R/일지 . . . . 1 match
* 리팩토링의 위대함을 계속 느껴 버렸다. Extract Method는 기본이고, 상위 클래스로 올리기, 등등 이것저것 하니까 매우 간단해지는 것을 느꼈다.
- UbuntuLinux . . . . 1 match
http://www.ubuntu.or.kr/wiki.php/InstallingInputMethods#s-1.3
- WhatToExpectFromDesignPatterns . . . . 1 match
== An Adjunct to Existing Methods ==
DesignPatterns are an important piece that's been missing from object-oriented design methods. (primitive techniques, applicability, consequences, implementations ...)
- ZeroPage_200_OK/note . . . . 1 match
=== HTTP Method ===
- 디자인패턴 . . . . 1 match
* http://www.econ.kuleuven.ac.be/tew/academic/infosys/Members/Snoeck/litmus2.ps - Design Patterns As Litmus Paper To Test The Strength Of Object Oriented Methods
- 문제풀이/1회 . . . . 1 match
==== Normal Method ====
- 영호의바이러스공부페이지 . . . . 1 match
Detection Method: ViruScan V64+, VirexPC, F-Prot 1.12+, NAV, IBM Scan 2.00+
AL = method code
- SIMPLE ENCRYPTION METHODS -
One easy way to encrypt data is the XOR method. XOR is a matamatical
While the virus is no great wonder the simple encryption method is what is
- 위키QnA . . . . 1 match
현재의 FrontPage가 하는 역할이 좀 많다고 생각하는데. (Long Method 에 대해서는 Refactoring이 필요한 법. --a) FrontPage가 하는 역할들에 대해 페이지들을 슬슬 나누는 것은 어떨까 생각중. --석천
- 지도분류 . . . . 1 match
||["ExtremeProgramming"]|| Agile Methodology 인 ExtremeProgramming 에 대한 전반적 설명||
Found 73 matching pages out of 7544 total pages (5000 pages are searched)
You can also click here to search title.
