카테고리 보관물: Chat-GPT
SVN commands
singleton class vs static class
static class 를 사용하려 하다 문득 singleton과의 차이점이 궁금하여 찾아보았다. 아래 4가지가 내가 여러 포스트에서 본 것을 정리해둔 것 같다.
- Singleton objects are stored in Heap, but static objects are stored in stack.
- We can clone (if the designer did not disallow it) the singleton object, but we can not clone the static class object .
- Singleton classes follow the OOP (object oriented principles), static classes do not.
- We can implement an
interfacewith a Singleton class, but a class’s static methods (or e.g. a C#static class) cannot.
https://stackoverflow.com/questions/519520/difference-between-static-class-and-singleton-pattern
참고해볼 다른 포스트
https://postpiglet.netlify.app/posts/csharp-singletone-vs-staticclass/
C# 생성자와 필드 초기화
생성자와 필드 초기화 순서가 궁금하여 다음과 같은 예제 코드를 작성했다. 위 링크의 포스트에 비슷한 예제가 있으니 궁금하면 한번 확인해보기 바란다.
class Apple
{
public Apple(string text)
{
Console.WriteLine(text);
}
}
class Orange
{
Apple apple = new Apple("Orange apple");
Apple apple1 = new Apple("Orange apple1");
public Orange()
{
Console.WriteLine("Orange write");
}
}
class Melon : Orange
{
Apple greenApple = new Apple("Melon apple");
Apple blueApple = new Apple("Blue melon apple");
public Melon()
{
Console.WriteLine("Melon write");
}
public void Shape()
{
Console.WriteLine("melon is sphere");
}
}
class Program
{
static void Main(string[] args)
{
new Melon();
}
}결과는 다음과 같다.
초기화 리스트는 derived class -> base class 순으로 그리고 위에서 아래쪽으로 실행 되었다.
하지만 생성자는 base class -> derived class 로 호출되었다.
Ottinger’s Rules for Variable and Class Naming
Ottinger’s Rules for Variable and Class Naming
Tim Ottinger
Brad Appleton took the time to convert the original textual version to hypertext, and I thank him for the this encouragement.
This is an archived copy; the original (and maintained) version lives here.
This paper grew out of some postings made on usenet, specifically comp.object, in 1997. There was some response, and so it is presented here in entirety, enhanced a bit.
- Use Pronounceable names
- Avoid Encodings
- Don’t be too cute
- Most meanings have multiple words. Pick ONE
- Most words have multiple meanings
- Nouns and Verb Phrases
- Use Solution Domain Names
- Also Use Problem Domain Names
- Avoid Mental Mapping
- Nothing is intuitive
- Avoid Disinformation
- Names are only Meaningful in Context
- Don’t add Artificial Context
- No Disambiguation without Differentiation
Introduction
When a new developer joins a project which is already in progress, there is a steep learning curve. If the new developer already knows the methodology and programming language, some of this is reduced. If the new developer already knows the problem domain fairly well, this also shortens the ramp-up time.
There is often a great deal of artificial curve which is added to a project by decree or by accident. This has the opposite effect; it increases ramp-up time and can hurt the new developer’s time-to-first-contribution considerably. And not only the first contribution, but the next several.
The goal of these rules set is to help avoid creating one type of artificial learning curve, that of deciphering or memorizing strange names.
The rules were developed in group discussions, largely by examining poor names and dissecting them to determine the cause of their "badness".
Use Pronounceable names
If you can’t pronounce it, you can’t discuss it without sounding like an idiot. "Well, over here on the bee cee arr three cee enn tee we have a pee ess zee kyew int, see?"
I company I know has genymdhms (generation date, year, month day, hour, minute
and second) so they walked around saying "gen why emm dee aich emm ess".
I have an annoying habit of pronouncing everything as-written, so I started saying "gen-yah-mudda-hims".
It later was being called this by a host of designers and analysts, and we still sounded
silly. But we were in on the joke, so it was fun. Fun or not, don’t do that.
It would have been so much better if it had been called generation_timestamp. "Hey,
Mikey, take a look at this record! The generation timestamp is tomorrow! How can that
be?"
Avoid Encodings
Encoded names require deciphering. This is true for Hungarian and other `type-encoded’ or otherwise encoded variable names. To allow any encoded prefixes or suffixes in code is suspect, but to require it seems irresponsible inasmuch as it requires each new employee to learn an encoding "language" in addition to learning the (usually considerable) body of code that they’ll be working in.
When you worked in name-length-challenged programs, you probably violated this rule with impunity and regret. Fortran forced it by basing type on the first letter, making the first letter a `code’ for the type. Hungarian has taken this to a whole new level.
We’ve all seen bizarre encoded naming standards for files, producing (real name) cccoproi.sc
and SRD2T3. This is an artificially-created naming standard in the modern world
of long filenames, though it had it’s time.
This isn’t intended as an attack on Hungarian notation out of malice toward Microsoft or
Windows. It’s a simple rule of simplifying and clarifying names. HN was pretty important
back when everything was an integer handle or a long pointer, but in C++ we have (and
should have) a much richer type system. We don’t need HN any more. Besides, encoded
names are seldom pronounceable ([#1]).
Of course, you can get used to anything, but why create an artificial learning curve for new hires? Avoid this if you can avoid it.
Don’t be too cute
If the names are too clever, they will be memorable only to people who share your sense of humor and remember the joke. Will the people coming after you really remember what HolyHandGrenade is supposed to do in your program? Sure, it’s cute, but maybe in this case ListItemRemover might be a better name. I’ve seen Monty Python’s The Holy Grail, but it may take me a while to realize what you are meaning to do.
I’ve seen other similar cutesy namings fail.
Given the choice, choose clarity over entertainment value. It’s a good practice.
Most meanings have multiple words. Pick ONE
Pick one word for one abstract function and stick with it. I hear that the Eiffel libraries excel at this, and I know that the C++ STL is very consistent. Sometimes the names seem a little odd (like pop_front for a list), but being consistent will reduce the overall learning curve for the whole library.
For instance, it’s confusing to have fetch, retrieve and get as same-acting methods of the different classes. How do you remember which method name goes with which class? Sadly, you often have to remember who wrote the library in order to remember which term was used. Otherwise, you spend an awful lot of time browsing through headers and previous code samples. This is a considerably worse practice than the use of encodings.
Likewise, it’s confusing to have a controller and a manager and a driver in the same process. What is the essential difference between a DeviceManager and a ProtocolController? Why are both not controllers, or both not managers? The name leads you to expect two objects that have very different type as well as having different classes.
We can take advantage of this to create consistent interfaces and simplify learning dramatically.
Most words have multiple meanings
Don’t use the same word for two purposes, if you can at all avoid it.
This is the inverse of the previous rule. When you use different terms, it leads one to think that there are different types underlying them. If I use DeviceManager and ProtocolManager, it leads one to expect the two to have very similar interfaces. If I can call DeviceManager::add(), I should be able to call ProtocolManager::add(). Why? Because the name created an association between the two. I expect to see *Manager::add() now.
If you use the same word, but you have very different interfaces, this isn’t a total evil (see #12 ), but it does cause some confusion. If you system or your module is small enough, or your controls rigorous enough to prevent synonyms, then that’s great.
If you’re learning a framework, though, you need to be most careful not to be fooled by synonyms. While you should be able to count on the names denoting type, you frequently cannot.
Remember also that it’s not polite at all to have the same name in two scopes.
Nouns and Verb Phrases
Classes and objects should have noun or noun phrase names.
There are some methods (commonly called "accessors") which calculate and/or return a value. These can and probably should have noun names. This way accessing a person’s first name can read like:
string x = person.name();
Other methods (sometimes called "manipulators", but not so commonly anymore) cause something to happen. These should have verb or verb-phrase names. This way, changing a name would read like:
fred.changeNameTo("mike")
As a class designer, does this sound boringly unimportant? If so, then go write code that uses your classes. The best way to test an interface is to use it and look for ugly, contrived, or confusing text. This really helps.
Use Solution Domain Names
Go ahead, use computer science (CS) terms, algorithm names, pattern names, math terms, etc.
Yeah, it’s a bit heretical, but you don’t want your developers having to run back and forth to the customer asking what every name means if they already know the concept by a different name.
We’re talking about code here, so you’re more likely to have your code maintained by a CS major or informed programmer than by a domain expert with no programming background. End users of a system very seldom read the code, but the maintainers have to.
Also Use Problem Domain Names
When there is no `programmer-ese’ for what you’re doing, use the name from the problem domain. At least the programmer who maintains your code can ask his boss what it means.
In analysis, of course, this is the superior rule to [Use Solution Domain Names], because the end-user is the target audience.
Avoid Mental Mapping
Readers shouldn’t have to mentally translate your names into other names they already know.
There are some unfortunate examples for this. One of them is Microsoft’s choice to call the things that walk through a list Enumerators instead of Iterators. This is sad because the term iterator is in common use in software circles and was completely appropriate to the domain (see Pick One ) and also because the term enumeration typically has a very different meaning (see Multiple Meanings ). Between the two, most developers have to translate enumerator to iterator mentally as the conversations about such things go on.
This problem generally arises from a choice to use neither problem domain terms nor solution domain terms.
Nothing is intuitive
Sadly, and in contradiction to the above, all names require some mental mapping, since this is the nature of language. If you use a term which might not be known to your audience, you must map it to the concept you’d like it to represent.
For this reason, most important names should be in a glossary or should be explained in comments at least. Even if they’re parameters or local variables. Even if they’re inside the static member of a class, unless the term is completely in harmony with all of these naming rules.
Avoid Disinformation
Avoid words which already mean something else. For example, "hp", "aix", and "sco" would be horrible variable names because they are the names of Unix platforms or variants. Even if you are coding a hypotenuse and "hp" looks like a good abbreviation, it violates too many rules and also is disinformative.
Likewise don’t refer to a grouping of accounts as an AccountList unless it’s actually a list. A list means something to CS people. It denotes a certain type of data structure. If the container isn’t a list, you’ve disinformed the programmer who has to maintain your code. AccountGroup or BunchOfAccounts would have been better.
The absolute worse example of this would be the use of lower-case L or uppercase o as variable names, especially in combination. The problem, of course is in code where such things as this occur:
int a = l; if ( O = l ) a = O1; else l = 0;
You think that I made this one up, right? Sorry. I’ve examined code this year (1997) where such things were abundant. It’s a great technique for shrouding your code.
When I complained, one author told me that I should use a different font so that the differences were more obvious. I think that the problem could be more easily and finally corrected by search-and-replace than by publishing a requirement that all future readers to choose Font X..
Names are only Meaningful in Context
There are few names which are meaningful in and of themselves. Most, however are not. Instead, you need to place names in context for your reader by enclosing them in classes, well-named functions, or comments.
The term `tree‘ needs some disambiguation, for example if the application is a forestry application. You may have syntax trees, red-black or b-trees, and also elms, oaks, and pines. The word `tree’ is a good word, and is not to be avoided, but it must be placed in context every place it is used.
If you review a program or enter into a conversation where the word "tree" could mean either, and you aren’t sure, then the author (speaker) will have to clarify.
Don’t add Artificial Context
In an imaginary application called "Gas Station Deluxe", it is a bad idea to prefix every class with `GSD‘ if there is a chance that the class might later be used in "Inventory Manager" (at which time the prefix becomes meaningless).
Likewise, say you invented a `Mailing Address’ class in GSD‘s accounting module, and you named it AccountAddress. Later, you need a mailing address for your customers. Do you use `AccountAddress‘?
In both these cases, the naming reveals an earlier short-sightedness regarding reuse. It shows that there was a failing at the design level to look for common classes across an application.
Sadly, this is the standard being used by many Java authors. Even in C++, this is becoming increasingly common. We need language support for this type of work. I’ve not had too much trouble with it in Python, but I’m watching out. You should also.
The names `accountAddress‘ and `customerAddress‘ are fine names for instances of the class.
No Disambiguation without Differentiation
This is a problem that usually arises from writing code solely for the compiler/interpreter. You can’t have the same name referring to two things in the same scope, so you change one of them. Well, that’s better than misspelling one (I’ve seen code that looks like this was intentional, and correcting the spelling prevented compiles due to symbol clashes), but there should be some fundamental change in name that make it clear that they are different.
Imagine that you have a Product class. If you have another called ProductInfo or ProductData, you have failed to make the names different. Info and Data are like "stuff": basically meaningless. Likewise, using the words Class or Object in an OO system is so much noise; can you imagine having CustomerObject and Customer as two different class names?
MoneyAmount is no better than `money‘. CustomerInfo is no better than Customer. The word `variable‘ should never appear in a variable name. The word `table‘ should never appear in a table name. How is NameString better than Name? Would a Name ever be a floating point number? Probably not. If so, it breaks an earlier rule about disinformation.
There is an application I know of where this is illustrated. I’ve changed the name of the thing we’re getting to protect the guilty, but the exact form of the error is:
getSomething(); getSomethings(); getSomethingInfo();
The second tells you there are many of these things. The first lets you know you’ll get one, but which? The third tells you nothing more than the first, but the compiler (and hopefully the author) can tell them apart. You are going to have to work harder.
Try to disambiguate in such a way that the reader knows what the different versions offer her, instead of merely that they’re different.
Final Words …
The hardest thing about choosing good names is that it requires good descriptive skills and a shared cultural background. This is a teaching issue, rather than a technical, business, or management issue. As a result many people in this field don’t do it very well.
Follow some of these rules, and see if you don’t improve the readability of your code. If you are maintaining someone else’s code, make changes to resolve these problems. It will pay off in the long run.
블록딜 이란?
https://nurias5.tistory.com/44
블록 딜(Block deal)
주식을 대량으로 보유한 기관 또는 개인이, 사전에 이 주식을 인수할 매수자를 구해, 장외 시간에 주식을 매도하는 거래를 의미 한다.
블록딜을 하는 이유?
대량 주식 매각을 효율적으로 하기 위해서 라고 한다. 장중 대량 매각 시장중 가격변화가 과도하게 나타날 수 있고, 그렇다면 원하는 시점과 가격에 팔 수 없기 때문. 결국 장외 시간 거래를 통해 시장에 영향을 미치지 않도록 하기 위함.
미치는 영향
지분을 상당부분 가지고 있는 주주가 주식을 대량으로 매각하는 것은 악재이다. 즉, 주가가 떨어질 가능성이 높아진다. 지분을 상당수준 가지고 있는 주주는 그 회사 내부 사정에 대해 더 잘 알고 있을 확률이 높기 때문에, 설사 다른 이유로 주식을 매각한다고 하더라도 시장에서는 부정적인 신호로 받아들이는게 일반적이다. 또한 5~10% 할인된 가격으로 거래가 체결되기 때문에 단기적으로나마 주가가 떨어질 가능성이 더 크다.
c++, map/unoredered map(hash map)
BVH
Bounding Volume Hierarchy
AABB(Axis Aligned Bound Box) 를 이진 트리 구조로 묶어 Intersection 검색을 빠르게 하기 위한 고조이다.
I’Think 01
나는 카카오톡 친구 목록을 자주 훑어보는 편이다. 프로필 사진을 보면 내 친구들의 근황을 볼 수 있어서 그렇다.
프로필 사진을 처음부터 끝까지 보다보면 내 전 여자친구의 프로필 사진이 보인다. 사진을 눌러 그녀가 무엇을 하는지 유심히 관찰 한다. 그녀가 어떻게 살고있는지 보고있자면 데이트 하던 옛 생각이 난다.
확실히 기억이 나지 않지만 헤어질 때 1년 후 다시 연락할거라고 했었던 기억이 난다. 하지만 난 그렇게 하지 않았다. 1년이 지나도 2년이 지나도 나도 그녀도 서로 연락하지 않았다. 둘다 자존심을 꺾지 못했다. 이제는 하고 싶어도 못할 것이다.
내가 기억하는 모습과 사진속 그녀의 모습을 보면 헤어진 때로부터 시간이 많이 지났음을 느낀다.
나는 지난 5년간 왜 연애를 하지 못 했을까? 주변에 이성이 없었나? 그건 아닌것 같다. 기회는 많지 않았지만 몇번 있었던 것 같다. 대학교에 복학 했을 때에도 취업을 했을 때에도 소개팅을 했을 때에도 기회는 늘 있었다. 스스로 생각하기에 나는 용기가 없었다. 과감히 다른 사람을 만날 용기, 다른 사람에게 내 모습을 보여줄 용기 또는 자신감.
문제는 나에게 있었다. 그동안 내 실패한 연애사를 포장하여 핑계로 삼고 있었던 것 같다. 보이지 않는가 내 전 여자친구는 다른 사람도 만나고 잘 지내고 있음을…
과거의 그녀가 나의 투정을 조금이라도 이해 했더라면, 그런일은 없었을 것이다 라고 탓을 해본다한들 위로가 되지 않는다. 답답한 마음만 더 생길 뿐.
돌이켜 보면 애초에 그 사람은 나와 안 맞았던 것 같다. 나는 과거의 연애에 있어서 내가 할 수 있는 모든 것을 했다고 생각했는데 그게 아니었나 의심이 든다. 나만의 착각인가?
애착을 가질 다른 사람이 나타나지 않아 이렇게 푸념이나 하고 있는 걸까? 연애는 할 수 있을까? 나는 좋은 사람과 결혼 할 수 있을까? 평생 혼자 일까? 언제쯤 이면 이런 구질구질한 생각을 하지 않고 살 수 있을까? 의문이 꼬리에 꼬리를 물고 나면 결국에는 나도 이제 새로운 사람을 만나고 싶다 라는 종착역에 도착한다.
나는 이제 마음에 드는 다른 사람을 찾기 시작했다. 하지만 여전히 이것저것 재면서 망설인다. 나도 모르겠다 내가 어떤 사람을 원하는지 예쁜 사람도 착한 사람도 모르겠다 판단이 서질 않는다.