IFoo or just Foo? Please stop naming interfaces IFoo.
I am not sure where the idea came from to name intefaces IFoo, but I think the practice is counter-intuitive and generally ugly. Java is not C++, nor C, and it most definitely is not Windows, so why do we have a good section of the Java community dead set on writing pre-historic looking code?
Aside from the aesthetic issues, which is important if you ask me -- code that looks funny most definitely smells funny, I believe naming an interface IFoo instead of Foo really misinterprets the fundamental idea of what an interface is.
An interface is an object - at least from the standpoint of the code that calls it. When you deal with it in code, there is no distinction between an interface and a full blown class. That, in my opinion is the beauty of Java. We can argue all day long about whether or not Java should have multiple-inheritance, the fact is that it does not. And in its place is a rather elegant solution - multiple interfaces.
My point is, when I instantiate FooImpl that implements Foo, for all intents and purposes, FooImpl is not a FooImpl, it is a Foo. If FooImpl happens to implement Bar, then it is also a Bar, but it most definitely is not an IFoo or an IBar.
To further belabor the point, calling your interface IFoo or IBar demotes the status of the interface, and the resulting "object" that is used by clients of the implementation of IFoo or IBar, thus subtly changing the way a programmer understands your code. It is as if the interface IFoo is second in nature to the implementation. But nothing could be further from the truth. Design by Contract means that you are coding to interfaces as first class citizens, not backwater denizens of the design. The implementation is what does NOT matter, and that's why you call it FooImpl, because you could have SuperDuperFooImpl and ReallyLameFooImpl too. The point is that any one of these is a Foo, and that's all your program should care about.
If you disagree with my opinion, look no further than Java Collections, do you implement an IMap or a Map? Josh Bloch had it right, so stop using IFoo already.
I am sure you'll still disagree with me, so flame on in the comments...
p.s. In the "nobody's perfect department", we even have examples in our own Terracotta code base.
Posts
50 comments:
FooImpl? Please stop naming classes FooImpl.
I am not sure where the idea came from to name classes FooImpl, but I think the practice is counter-intuitive and generally ugly.
Aside from the aesthetic issues, which are important if you ask me -- code that looks funny most definitely smells funny, I believe naming a class FooImpl instead of leaving it anonymous really misinterprets the fundamental idea of what a name is.
To further belabour the point, calling your class FooImpl promotes the status of the class.
An object is defined by what behaviour you can perform with it. Interfaces are a suboptimal way of declaring that behaviour, because they, by not allowing conjugations of interfaces to be interoperable, and by not allowing interfaces to extend others after the fact, encourage large monolithic interfaces.
Explaining the conjugation point - given interface A, interface B, interface C extends A,B, interface D extends A,B, there's no way to write a method that takes a C and allow a D to be passed instead.
There is a way of allowing something that is an A and is a B to be passed, via generics, but there's no way of naming that combination without losing flexibility.
We can argue all day long about whether Java should have interfaces, the fact is that they are mainly for persuading the compiler to accept your code, and only sometimes for self-documentation. They actually harm in some cases. Try writing a method that accepts any object that provides an add method and an iterator method.
If you disagree with my point, consider your favourite language, where it forces (or encourages) you to name things you don't want to (FooImpl, method names, interfaces) and doesn't allow you to name things you do want to (method references, conjugated interfaces, the this pointer from an outer anonymous class).
Ricky,
Not sure what you're trying to say...but I guess imitation is the sincerest form of flattery, as they say.
In any case I wasn't making an argument for what to call a CLASS, only an interface - so you are arguing about...nothing?
Calling a class DefaultFoo is perfectly fine, and preferable, imo.
I would argue that interfaces are objects. They are more like contracts actually and there is a huge difference between an object and a contract. For instance, contracts can't be extended without breaking backward compatibility, but objects - can. That is why it is more preferable to expose the abstract classes and not interfaces for the long living API.
Consider also the example I pointed to, the Collections interfaces, which have well named interfaces AND classes, so certainly you cannot be arguing that the language itself somehow limits good design and naming - or you just don't like Java?
I guess you are arguing that interfaces are inherently...bad? In that case shoo troll...be gone.
Eugene,
Hmm, I am not sure I see your point. An Abstract Class is no better at insulating changes to the API from the rest of the codebase than an interface is...
And, generally speaking, an Abstract Class with no implementation is just an interface, an Abstract Class with full implementation is a normal class, so basically an Abstract Class with partial implementation is really just a way to specifically tell a programmer "Extend Here".
Maybe that is your point?
I'm merely making the point that while you're asking developers to stop doing one thing, you're yourself doing something a bit dodgy.
DefaultFoo, and FooImpl, are clearly poor names. If you have only one implementation of Foo, and Foo is not going to be implemented by third parties, then there's no advantage to it being an interface, you may as well merge the class and the interface.
If you have two or more implementations, calling one FooImpl seems to demote the others. If LinkedList was called ListImpl, people would probably look at ArrayList like it was alien.
Instead of FooImpl, you could name the class according to what it does. ArrayList and LinkedList are good examples of that, Vector isn't.
Looking at Collections, one issue is that Iterator has remove in it, a method that makes no sense for read-only collections. Interfaces don't provide a good way of handling that - you can replace Iterator/Iterable, but you won't get the Java 5 foreach loop.
Some of the considerations for making collections as monolithic as they are is the potential for interface explosion. http://java.sun.com/j2se/1.4.2/docs/guide/collections/designfaq.html#1
I like Java, but I can also see that some aspects of it cause problems.
I don't see MapImpl in the Collections classes. I'd call the one interface to class paradigm another type of code smell worth avoiding...
w i c k e t
I'm actually a C# developer, but we're on similar ground here. Naming interfaces IFoo rather than Foo has a great benefit: specifically, you immediately understand that you cannot call a constructor to create an IFoo. The Foo/FooImpl pattern is code smell just as much as the IFoo/Foo pattern is. If you're not creating something that has extensibility as an explicit design goal, one-class/one-interface is a bad idea, since you're not really thinking about HOW the type is going to be reimplemented.
One time that comes to mind where using an interface and naming the class something "generic" like FooImpl or DefaultFoo makes sense is when extracting an interface purely for testability -- to isolate dependencies. Then you might have a MockFoo that you use when unit testing some consumer of Foo.
YANP:
You're missing my point a little - what I'd like to be able to do is say that C is anything that implements A and B, and then write methods that take Cs as parameters. That is, C isn't really intended to be part of a hierarchy, but to provide a name for a collection of methods. Imagine if java.util worked this way. List could extend Add, Clear, IsEmpty, Iterator, and then I could create a conjugation (named C, say) of Add and GetIterator - any List or any other type that implements Add and GetIterator could be passed as a C.
You might think this is a bad idea, but it's already possible using generics.
public [C extends Add,GetIterator] void doSomething(C c){blah}
The main problem is that I can only define such conjugations as type parameters - and I end up repeating those wherever I want to use C. That's suboptimal.
Hey guys, what about unit testing and mock objects ? ;-)
Say you have Foo/FooImpl and Bar/BarImpl, and Foo has a dependency on Bar.
If you want to unit test Foo, you can :
- test indirectly BarImpl while testing Foo,
- or use mock objects (jmock, easymock, etc), and replace BarImpl with a mock. And you can do it because you have an interface (Bar).
So, the answer is : there is no easy answer. It depends on what you're doing...
Taylor, my point is that adding method to the interface is a breaking change, while you can safely add a non-abstract method to the abstract class. That is not really related to the naming of these classes, but somewhat related to object vs. contract remark you've made.
I personally use that convention and I find it quite nice. I can see what you're saying but the ability to see and understand that something is an interface, even by just looking the files is very usefull to me. So, it's an overhead I'm gladly paying for having more information by convention.
Eugene, as you know, changes to interfaces are breaking only for extenders, not clients. What you say makes a lot of sense in the Eclipse world or in other places where focus is very much on extenders, and I think I'd agree that abstract classes are maybe better for extenders.
But in my daily work I don't really deal with extenders often and I use interfaces mainly for testability purposes, and to make the contracts more readable (without the clutter of the implementation getting in the way). So I think this concern is *almost* irrelevant for my case (and a lot of others).
Actually, no: an interface is *not* a concrete class, and their respective instances should reflect that. I can do "new" of a concrete class, I can't on an interface, and that's exactly why the "I" prefix is useful.
It's also a good indicator of how "pure" (e.g. easily testable) a piece of code is. The more "I" in it, the easier it will be to test.
Also, Microsoft and Eclipse are good examples of successful API's that use this convention... something to think about.
--
Cedric
Putting an I in front of interface names looks really really bad. Reminiscent of old dead hungarian notation. Get a real IDE C# guys ...
I agree. I'm tired of old C/C++ styles. So, what happens when a mistake is made in the design (of course, it would be the guy who just left the project, not you) and you decide, since you so much smarter (than when you made the mistake last week), that the IFoo interface (now scattered throughout your code base) should really be promoted to full citizenship and become a Foo object....
I know... today's IDEs take care of this fairly handily but that's beside the point. It's sloppy style. If you're shaking your head in disagreement right now, I have to ask: Are you the same person who wrote all those same C functions with names like arg0, arg1, ...., argN? Shame on YOU! :)
A naming convention is as good as the consistence of its usage. It does not really matter how you name the types.
You missed a major reason why interfaces are named with I prefix. Though both classes and interfaces are the same as far as usage goes - when used for subclassing they differ. We use extends for subclassing a class and implements for using a interface. By naming the interfaces with a I prefix, the implementor of the subclass does not need a round trip to the java doc for finding this.
i think prefixing interfaces with 'I' is just duplication. And any self respecting programmer knows the devil in duplication. Putting "interface" keyword on declaration and prefixing the name with "I" communicates the same thing. Former is for computer and human while latter is for human only.
Use of "I" prefix for communicating that a code piece is an interface brings the issue of why don't we put every attribute as letter prefixes. Prefix abstract classes with "A", packages with "P", integers with "I"... Or maybe use combinations of prefixes for better communication of the nature of named item. This way may be we could do with sole text editors, instead of smart IDE's.
Ricky,
What is your point? That people should prefix interface names with the letter I?
The author has a good point. Let's stick to the style used by Sun unless you have a good reason not to.
Habit. Pure and simple. It's a very strong force. People at the shop I'm working at were racking their brains to find a TLA for a new file extension that wasn't taken. .BTJ ? .BJB .JBB .JBY?
The I pointed out that it was the century of the fruitbat, win9x wasn't supported by us any more, and that we could have as many characters in our extension as we liked...
I think your argument is fundamentally flawed. You say that if something implements IFoo it's really a Foo and thus should be called foo. But what if i have two classes that implement IFoo should I call the both Foo? And what about just being able to look at your classes and tell which ones are interfaces and which ones are concrete without opening each one up? Sure IFoo may look a bit weird but you haven't proposed anything better.
And an interface is only a class by coincidence. You can't actually DO anything with an interface that you can do with a normal POJO. Like the other commenter said, it's just a contract. And they are second in nature to the implementation because it certainly can't do ANYTHING the implementation can do because by definition an Interface can't DO anything. It can only SPECIFY / REQUIRE things. Yes you treat them as first class citizens but they are not the same thing.
It's like hiring an 80lb weakling as a firefighter. Yes we strive to treat everyone the same but do you really want that person trying to throw your unconscious ass over their shoulder while they fight their way out of your burning house? I don't I want the big burly bodybuilding dude not someone who just happens to have the same rights as him.
Also interfaces aren't treated as objects from the standpoint of the code that calls it. Objects are treated as interfaces from the standpoint of the code that calls it. It's totally the opposite and it's a big difference.
If you don't want me to use IFoo give me a reasonable alternative that lets me distinguish my interfaces from my other classes (because frequently i need to go edit the interface NOT the class). I also need to know that when I'm creating a method signature i haven't accidentally coded it to take an implementation instead of an interface and I can't do that by looking at it if I can't distinguish interfaces by name.
@masukomi
Actually, I do give a reasonable alternative:
Stick to the conventions laid out by the Java Language. Maps are maps not IMaps, implementations should be named on how they implement the contract e.g. HashMap and ConcurrentHashMap.
I propose that you do the same in your code. Thus the interface should be called Foo, and you should have DoesSomethingFoo and DoesSomethingElseFoo, for lack of a better example (I think the Java Language examples are better)
@everyone else
I have read all the comments thus far, and I am amazed at some of the things people are saying. One thing that strikes me very oddly is the rather blase attitude some people take towards inheritance - as if a naming convention alone should be the sole reason a programmer can know whether to extend or not extend a class. If you are using "I" to tell people that they should NOT extend, then you have serious other problems, because inheritance should not simply be used whenever and wherever you feel like it. It should be a very conscious, very determined sort of activity, and having to know the class intimately is only the first requirement before one should go off and extend a class.
I think that actually helps me to know what topic to blog about next - the "isA" relationship and how unbelievably misunderstood it is in the world of OOP.
Before I go, I want to point out that as always, I am humbled and not nearly as eloquent or informative in my own blog as Joel Spolsky is. For the diligent reader, I suggest reading his (rather long) entry on how and why one SHOULD use a naming convention - http://www.joelonsoftware.com/articles/Wrong.html
I agree with him, and find that it is sort of funny that the whole "I" thing comes from a complete misunderstanding of the entire motivation for the "Hungarian Notation" thing.
So I reiterate my plea - please stop using "I" for interfaces - it's redundant and useless information, there are better reasons to use a naming convention, but to convey the actual type in a strongly typed system (Java) really goes against not only common sense but DRY (Don't Repeat Yourself)
Your suggestion for how to name the implementations is good but it still doesn't solve the problem of not being able to *easily* tell which classes in your tree are the interfaces and which are the implementations. I'd love a better alternative to I but I just haven't seen, or thought of, one worth switching to. With Map and your proposed naming convention, for example, there's really no way to tell if Map is an Interface or an Abstract class or just a normal class that everything happens to extend. With IMap I can be confident when looking at my class tree or a method signature that it's an interface without it I, and especially anyone new to the project, just can't tell and that is almost guaranteed to lead to eventually requesting an implementation instead of the interface in a method signature.
A friend if mine had a 'compilation unit' called IPod ... now i wonder if it's an interface or a class ... ;o)
Since it's a little program for music devices i guess it's a class ...
What's the quintessence? It depends on the shared semantic context of individuals.
re compilation unit called IPod. It's neither a class nor an interface it's a pending lawsuit. ;)
I remember asking myself what naming convention to adopt when delivering the interface based public SDK. Argued the collection interface naming vs usage of adjectives. And since adjectives usage became ugly pretty soon, this made me think collections was spot on, indeed.
Thanks for this very cool article.
I agree with the article - interfaces should have the base type name (without the 'I'), and concrete implementation classes are specializations that should qualify that name. If you use interfaces throughout and factories (or better still, IOC & dependency injections a la Spring) for the implementations, you have better clarity and flexibility, and you don't have to distinguish between interfaces and their implementations.
I'd like to suggest another reason for considering interfaces as distinct from classes, and therefor perhaps a bit of support for the name making the distinction.
We've all heard "A extends B" (for classes) verbalized as "A is-a B"; an instance of A is a particular kind of B. However, for several years of teaching and mentoring, I've encouraged Java programmers to verbalize "A implements P" with the phrase "A as-a P", where we understand P to be a role which is fulfilled in a particular context by A.
This is a bit more than saying that interfaces are Java's nod to multiple inheritance (which I never say). Instead it is deliberately thinking of a piece of functionality in terms of the roles which collaborate to accomplish the goal, and specifically disclaiming dependence on any particular (whole or partial) implementation of that role.
By way of analogy, a football team's playbook (e.g. their collection of design patterns) is written in terms of what the quarterback, running back, linemen, etc. do in a particular context; one would not expect to find individual player's names.
Naming interfaces in a way that makes it obvious that the code under the eye is designed/written to role-based thinking strikes me as a reasonable convention, given that this is not (yet?) universal practice in our profession.
As a side note, I really don't care too much about remembering that I can do new Foo(...) but not new IFoo(...) as I find myself shifting more and more toward factories and dependence injection. These both give me a simple way to acquire an object that in the current context can be used as a foo, and help me (and the readers of the code) remember not to assume anything else about the object I get.
RIGHT ON!!!!!
I agree with the author too! Additionally, please stop naming data members m_xxxx.
Whilst I agree with you, who really give a hoot! Its a style, some people like/use it and others don't.
The most important thing is that people use interfaces when it's appropriate. Whether they call it IBar or Bar makes no real difference and if you find it difficult to read too bad.
Concentrating on programming style can be useful, but really it does not affect the quality of code..... "code that looks funny most definitely smells funny". The quality of code depends on whether they understand programming and the language, not wether they call it IFoo or Foo.
Asthetics aside -- good code is always ugly, as in using the try/catch/finally construct[you DO use finally?], etc -- the salient point is that Interfaces trend coding practices to a Open/Closed pattern (http://en.wikipedia.org/wiki/Open/closed_principle).
The primary value of interfaces is forcing a formal contract at design time; at development time, interfaces promote encalsulation and abstraction.
"It's like hiring an 80lb weakling as a firefighter. Yes we strive to treat everyone the same but do you really want that person trying to throw your unconscious ass over their shoulder while they fight their way out of your burning house?"
No - it's nothing like that. Here "firefighter" is the type, I expect with a job description which is the interface, but let's just refer to firefighter as the interface for now. "John Smith" is a concrete implementation of firefighter. You don't say, my house is on fire, I need a John Smith, you need a firefighter - you don't care which implementation you get, as long as they satisfy the interface. Firefighter defines the contract of what a firefighter does, and thereby what what implementations satisfy that contract - it is unlikely that the 80kb weakling is going to satisfy the contract defined by the firefighter interface.
Anyway, we're talking about types. Types which are exposed to other classes should be named to reflect what they are, regardless of wether it is an Interface, a class or an abstract class. An Interface is a way to isolate the contract definition for the type, but you don't need to use an interface. In the interests of testability though, you should.
深圳翻译公司，知名深圳翻译公司，
广州翻译公司，上海翻译公司,东莞翻译公司国内同声翻译（同声传译）领域领头军！同声传译(同传)是国际会议通常使用的翻译方式， 翻译人员进入隔音间里
，通过耳机接听发言人的声音再将其翻译给听众。这种形式的翻译方式需要较为复杂的
设备以及非常专业的翻译人员，但能节省大量的时间。优质翻译公司译佰
翻译公司能提供同传深圳德语翻译，深圳俄语翻译，深圳韩语翻译等数种同传语言，培养一批商务口译人员，多年以来，
译佰同声翻译在同声传译(同传)领域积累了丰富
的业务经验，能提供从专业同声翻译、译员培训到同传设备安装租售业务等一整
套国际会议同传服务,深圳翻译公司，专业深圳英语翻译 ，深圳日语翻译，深圳法语翻译。
Cash border shopping Available if you have a credit card, no guarantee that customers who are not required examination. Available from anywhere in the country.
Credit card cash Shopping is a cash card loans, credit card if you have the cash with immediate effect
ショッピング枠現金化するので誰でもかんたんにカードでお金をおつくりできます♪ご融資などではありませんので審査や面倒な手続きは一切ございません！ ご返済方法は一括・リボ・分割（最高20回）・ボーナス一括などからお選びいただけます。
中古ＤＶＤ
中古ＤＶＤ
アダルトＤＶＤ
ヒップホップ
杭州装修公司杭州店面装修杭州办公室装修杭州装饰公司杭州装修公司杭州装饰公司蜂王浆芦荟蜂胶蜂王浆芦荟蜂胶ball valve球阀gate valve闸阀angle valve角阀bibcock水嘴tapCheck valvehot-water heatingfittings苏州led上海led北京led苏州电磁铁苏州装修公司苏州装饰公司atsATS生产atsATS开关
TM产品还都支持网络广州翻译公司,报告昨日公布。比如，译员A刚刚翻译了韩语翻译共享记忆库功能稍晚时间,同传设备已经说明一切。翻译是一门严谨不容践踏的语言文化。同声传译,凡购深圳同声传译翻译部署促进房地产市场健康发展措施出台,深圳翻译.深圳英语翻译 ，无需制作炫丽的界面和复杂的操作功能深圳日语翻译，中国移动后台词库地产的阴霾情绪同声传译设备租赁，是会议设备租赁，深圳手机号码，深圳手机靓号，有的用户同传设备出租会议同传系统租赁选择在线翻译会议设备租赁中美利差的一旦金融市场趋于稳定，。同声传译设备租赁存在，。新疆租车，美元汇率明年什么时候开始由强转弱， 广州翻译公司，用户的体验不能停留同声传译一扫而光”。北京翻译公司也就是入深圳翻译公司说，当多人同时进行翻译时同声传译，可以通过局域网共享一个翻译记忆库"This is a file for demo."，当译员B遇到"This is a demo file."时，系统会给出A的译文"这是个演示用的文件。"翻译公司，东莞翻译公司。在线翻译工具。法语翻译。B可以接受，也可以修改，修改后的译文又可供自己或他人重复使用。广州翻译公司，翻译记忆库就在这样的不断补充和完善过程中，发挥着越来越大的作同声传译设备租赁，是会议设备租赁，一项调查显示法语翻译几乎将深圳更多的是通过线翻译同声传译深圳俄语翻译，市场风险偏好升温。商务口译，料就在昨日下午深圳韩语翻译广州同声传译用。
放大上海翻译公司这将导致人民币兑表决器出租,表决器销售 租赁表决器各种货币 德语翻译，，
アメリカンホームダイレクト: Estimates easily auto insurance risk-segmentation. Support for compensating the content on the website. Benefits are also available with special rates for hotel and leisure facilities, offering various services.
and
what
MyBlog
hands
version
service
been
connection
msn489
ydff
erty
sfds
iioo
ert
jdfdf
fff
qsdfg
rrtt
rfdd
kk499
23
asop 98
dfgty 67
mlop09
bn156
xcxcv
erjb
ghjk
asert23
mostdf
xvcdf
dfgt90
gt90
yiyiyi
de23
uy445
mostfg
ff70
oomost
good11
fd41
bbty
jjl1
tsdfe5
ope8
p3e
oui9t
ip22
ggkag
ghjkcvd5
fj5454
ffhjeett
fgdfw
gffj
dgsd
sgsdf
ewmkk
gcvb
nnhjk
This
family
national
county
threatened
should be
administration
brother
new
boss
不動産投資
個別指導塾
多重債務
国際協力
人権問題
車 金融
toefl
アダルト
出会い
出会い
葬儀 千葉
国内格安航空券
会社設立
ブログアフィリエイト
wholesale jewelry
jewelry store
fashion jewelry
handcrafted jewelry
jewelry wholesale
wholesale pearl jewelry
wholesale crystal jewelry
wholesale turquoise jewelry
wholesale coral jewelry
wholesale shell jewelry
wholesale semi-precious jewelry
wholesale Swarovski crystal
dfnzh I like your blog. Thank you. They are really great . Ermunterung ++ .
Some new style Puma Speed is in fashion this year.
chaussure puma is Puma shoes in french . Many Franzose like seach “chaussure sport” by the internet when they need buy the Puma Shoes Or nike max shoes. The information age is really convenient .
By the way ,the nike max ltd is really good NIKE air shoes ,don’t forget buy the puma mens shoes and nike air max ltd by the internet when you need them . Do you know Nike Air Shoes is a best Air Shoes . another kinds of Nike shoes is better . For example , Nike Air Rift is good and Cheap Nike Shoes .the nike shox shoes is fitting to running.
Spring is coming, Do you think this season is not for Ugg Boots? maybe yes .but this season is best time that can buy the cheap ugg boots. Many sellers are selling discounted. Do not miss . Please view my fc2 blog and hair straighteners blog.
.thank you .
I like orange converse shoes ,I like to buy the cheap converse shoes by the internet shop . the puma shoes and the adidas shoes (or addidas shoes) are more on internet shop .i can buy the cheap nike shoes and cheap puma shoes online. It’s really convenient.
Many persons more like Puma basket shoes than nike air rift shoes . the Puma Cat shoes is a kind of Cheap Puma Shoes .
If you want to buy the Cheap Nike Air shoes ,you can buy them online. They are same as the Nike Air shoes authorized shop. Very high-caliber Air shoes and puma cat shoes . the cheap puma shoes as same as other.
池袋 風俗
渋谷 風俗
新宿 風俗
アダルトＤＶＤ
av 写真
アダルトＤＶＤ
アダルトショップ
ペニス増大
電マ
TENGA
SM 通販
セクシー下着
男性下着
Tバック下着
大規模修繕
決済代行
SEO
SEO
fether felt flat
決済代行
FX 比較
クレジットカード 申込
子猫
子犬
仔猫
アダルトショップ
アダルトグッツ
ゴールドカード ランキング
ダッチワイフ
Mirror, mirror on the wall, crystal is the fairest bauble of them all. This winter, let your feet marvel and sparkle with the likes of Lady Lynch Zeppa, Stellis, So Private, Calypso, Beaute Strass, Pigalle or made-to-measure crystallized high-tops(see Mika's latest cideo.) But be warned, crystal gazing can lead to a hypnotic state. There again, those darling Druids would beg to differ as would Queen Victoria who ordered up Crystal Palace and fervent fans of Naico Mine's 'Cave of the Gaints' in Chihuahua, Mexico. If visiting the latter, pack your Christian louboutin shoes and matching hairnet; the humidity is frizz bang outrageous.
DIscount moncler uk , cheap Babyliss Hair Straightener, CHI Hair Straightener.
新貸金業規正法に適応した車金融業者
「乗ったまま融資」は、質屋とは違って車を乗り続ける事ができます。
車金融 車担保融資は、「乗用車・商用車・トラック・バイク等を担保に金銭の貸付を行う業者」文字通り車を担保として融資を受けることが出来る融資方法です。
メンズファッションの通販サイトを探す方法。メンズファッションの通販サイトについて、実際に利用した人の口コミや評価が掲載されている口コミサイトを利用することもできます。
安い メンズ通販サイト
おすすめメンズ通販サイト
自分に合ったメンズファッションの通販サイトを見つけることができます。
Post a Comment